Three weeks after the Amsterdam team in Part 1 shipped their three-tier agent loop, a security partner firm walked through what they had built. Their orchestrator (Fable 5) planned the request, dispatched briefs to a fleet of Gemini-based workers, and consulted an advisor tier on commitment boundaries. The team was proud of the architecture — cost was down, latency was down, failure isolation was demonstrable. The security review took ninety minutes. It named three attack surfaces the team had not designed against.
The three-tier loop is a good architecture. It is also a wide attack surface, and the widening happens exactly at the tier boundaries the design creates. This piece covers the three surfaces — orchestrator hijack, worker-fleet poisoning, judgment-chain compromise — the principal-of-record discipline that keeps the audit chain intact across the boundaries, and the regulatory grounding under EU AI Act Article 14 and NIS2 that will decide whether the audit chain survives external inspection.
Key takeaways
- The orchestrator is the highest-value target. If the planner is prompt-injected through user input, every worker brief that follows is attacker-controlled. Instruction-versus-data separation at the orchestrator input is the load-bearing primitive.
- The worker fleet is stateless by design, which means each worker is blind to what the others are seeing. That is a coordination benefit and a detection weakness — a shared attacker signal split across worker briefs is invisible to any single worker.
- The advisor tier that critiques at commitment boundaries is the last line of defence and the highest-value late target. Compromising the advisor's reasoning chain turns every critique into a rubber stamp. Multi-model advisor consensus is the mitigation that fits the architecture.
- The principal-of-record chain — originating user → orchestrator → workers → advisor → committed action — has to survive every tier boundary. Without it, the audit says "the AI did it" and no external regulator or internal auditor can attribute the action to a principal.
- EU AI Act Article 14 requires human oversight for high-risk AI systems; NIS2 requires incident-response capability for essential and important entities using AI in operational contexts. Both regulators will ask which tier a specific action came from and who was accountable. The three-tier loop has to be able to answer.
The Orchestrator Hijack
The orchestrator is the highest-value target in a three-tier loop because it is upstream of every worker brief. If an attacker injects into the orchestrator's context — through user input, through a compromised retrieval source, through a poisoned prior conversation turn — every plan the orchestrator produces from that point on is attacker-controlled. Every worker brief that follows is attacker-controlled. Every downstream action is attacker-controlled. The advisor may catch the compromised deliverable at the ship boundary, or it may not; the fifty worker actions that ran in parallel before the advisor was consulted have already touched real systems.
The mitigation is instruction-and-data separation at the orchestrator input. User input is treated as data, always. System instructions are treated as instructions, always. The boundary is enforced at the input-parsing layer, not at the model's discretion. The specific technique — XML tags, structured input formats, dedicated user-input roles — is less important than the discipline of never letting user input become executable instructions. The least-privilege architecture applied to AI-assisted code review is the same pattern applied here: instructions are not a security boundary, so the boundary has to be at the runtime input layer, not in the prompt.
The audit-chain implication is that every orchestrator plan carries a signed record of the input that produced it. If the plan later turns out to have been attacker-influenced, the post-incident investigation can point at the specific input, the timestamp, the originating principal, and the propagation path across the worker briefs.
The Worker-Fleet Poisoning
Stateless parallel workers is a coordination benefit and a detection weakness. Each worker sees only its own brief; none of them see what the others are working on. If an attacker gets a signal into the shared context that all workers draw from — the retrieval corpus, a shared tool response, a common upstream cache — the same poisoned signal is delivered to every worker in parallel. No single worker has enough context to see the poison; the orchestrator sees the aggregated result and either catches it in verification or does not.
The mitigation runs on two layers. Shared-context signing — every artefact that reaches the worker fleet (retrieved documents, tool outputs, upstream cache entries) is signed at the source and verified at the worker. Poisoned content that lacks a valid signature fails ingestion. Cross-worker consistency checks at the orchestrator — the orchestrator explicitly looks for the same anomaly appearing across multiple worker outputs, which is a signal that the poison sits in the shared context rather than in any individual worker's reasoning. Neither mitigation is trivial. Both are cheaper than the incident that a fleet-wide poison event would produce.
The audit-chain implication is that the worker layer records not just the brief and the result, but the signed provenance of every input the worker consumed. A post-incident investigation can then trace the poison back to its source of the untrusted content, and the remediation targets the ingestion path rather than the model.
The Judgment-Chain Compromise
The advisor tier is the last line of defence before commitment. It is also the highest-value late target — if the advisor's critique is compromised, every deliverable that reaches ship gets rubber-stamped. Compromise can happen through the same input surface as the orchestrator (prompt injection in the context the advisor reviews), through the rubric the advisor grades against (if the orchestrator wrote the rubric and the orchestrator was already compromised, so is the rubric), or through corrupted reasoning references (the advisor consults a reasoning artefact — a prior decision, a policy document — that has been tampered with).
The mitigations compose. Independent advisor rubric — the advisor tier writes the acceptance criteria before dispatch, not the orchestrator; the criteria are grading against a target the planner did not construct. This is the fix for the self-blind-verification problem Part 1 surfaced, and it doubles as the security fix for the rubric-corruption path. Multi-model advisor consensus — high-consequence commitments require critique from two independent advisor models on different reasoning chains. A compromise on one is not enough; a compromise on both is meaningfully more expensive to mount. Signed reasoning references — policy documents, prior decisions, and any artefact the advisor consults are signed at source and verified at consumption. Reasoning against unsigned or tampered content fails safe.
The audit-chain implication is that every commitment carries the advisor's identity, the rubric identity, and the reasoning references consulted, all signed and verifiable.
Principal-of-Record Across the Tiers
Every action the loop commits has to be attributable to a principal. Not to the AI. The originating user, the orchestrator acting on their behalf, the workers acting on the orchestrator's delegation, the advisor consulted on the commitment — every hop carries the identity of the actor and the delegation chain that put them there. The IAM-for-AI-agents track covers the discipline in full; the three-tier loop is one specific shape of it.
The rule is straightforward. Every artefact produced by every tier — the plan, the brief, the worker result, the advisor critique, the committed action — carries the principal-of-record for the originating user, the identity of the tier that produced it, the delegation chain that led to this tier acting, and a trace ID that binds the entire chain across the multi-tier workflow. When the compliance officer asks who signed off on this refund, the audit log answers with a signed chain, not with a wall of LLM traces.
Without this discipline, the audit chain fails the same way it fails on every AI system without identity architecture — "the AI did it" is not an answer, and no external regulator or internal auditor will accept it.
Regulatory Grounding
Two regulatory regimes shape what the three-tier loop has to prove.
EU AI Act Article 14 requires human oversight for high-risk AI systems. The definition of high-risk includes many enterprise agentic workflows — credit decisions, HR filtering, safety-relevant industrial control, biometric identification. Article 14 requires that the human oversight is meaningful, not decorative. In a three-tier loop, the meaningful oversight lives at the advisor-consultation boundary or at the commitment boundary; the design work is making sure the human review is where the decision actually happens, not where the deliverable is already effectively committed. Advisor-consulted-twice satisfies the letter; advisor-consulted-at-every-commitment-boundary satisfies the spirit.
NIS2 requires incident-response capability for essential and important entities using AI in operational contexts. The audit-chain discipline above is what makes the incident response tractable — when the security team has to reconstruct what happened during an incident, the principal-of-record chain gives them the timeline, the actors, and the delegation path in a form the regulator will accept. Without it, the incident-response report reads as a set of LLM traces with no attribution, and the essential-entity classification carries a €10 million or 2% global revenue penalty for material non-compliance.
The two regimes do not name the three-tier loop specifically. They do name every property the three-tier loop has to demonstrate. The audit chain is what maps the architecture to the regulator's questions.
If the Amsterdam team's security review turns into a regulator's audit next quarter, which of the three surfaces above has the least evidence to show — the orchestrator input record, the worker-fleet provenance chain, or the advisor's signed rubric-and-references trail?
FAQs
Is multi-model advisor consensus worth the cost, or is one strong advisor enough?
For most workloads, one strong advisor with a signed rubric and signed reasoning references is enough. Reach for multi-model consensus when the commitment surface is high-consequence — financial actions above a threshold, safety-relevant industrial outputs, decisions that would land the organisation on the front page if wrong. The cost of a second advisor consultation is a fraction of the cost of one wrong commitment on those surfaces; the cost is disproportionate on lower-stakes surfaces. Tier the advisor architecture the same way the workload tiers the workers.
How do we prevent user input from reaching the orchestrator as instructions?
The practical patterns include wrapping user input in a dedicated user-role container that the orchestrator's system prompt treats as data only, structured input formats (JSON schemas with typed fields) that the model parses without executing, and dedicated instruction-versus-data tags that the runtime rejects if the tags cross. None of these is jailbreak-proof on its own; the discipline is stacking them so that circumventing all of them requires multiple independent failures. The stronger defence is that the orchestrator does not have tool authority to execute anything directly — it only produces briefs that pass through the policy layer before workers act.
What does "signed provenance" mean in practice for the worker fleet?
Every input to a worker — retrieved document, tool output, upstream cache entry — carries a signature from the source system. The retrieval tier signs the documents it returns. The tool wrappers sign the outputs they produce. The worker verifies the signatures before ingestion; unsigned or invalid content fails safely. In practice, this is HMAC signatures with per-source keys, rotated on the standard credential rotation schedule, and stored in the same secrets manager the rest of the platform uses. The engineering cost is modest; the audit-trail value is meaningful.
Does the audit chain need to be human-readable, or is machine-verifiable enough?
Machine-verifiable is sufficient for the technical audit; human-readable is sufficient for the regulatory interview. Most production systems store the chain in a structured format (JSON, protobuf) that is both — the technical audit tools ingest it directly, and the compliance team's review UI renders it as a human-readable timeline. Under EU AI Act Article 14, the regulator does not read the raw log; they ask specific questions and expect the compliance team to answer them from the log. Design the audit chain so that both audiences can extract what they need without translation work.
Companion content
- The Three-Tier Agent Loop: What's Right, What's Thin, and What's Missing — Part 1, the design and economics read
- IAM for AI Agents: Delegation and the Principal-of-Record Chain — the audit-chain discipline this piece reuses
- Instructions Are Not a Boundary: Least-Privilege for AI-Assisted Code Review — the verifier-independence pattern
- The AI Act Enforcement Cliff: The August 2026 Deadline — the regulatory reality Article 14 sits inside
How to engage
If your team's three-tier agent architecture has not had a security review at the tier boundaries yet, talk to us at creativeminds.dev/contact. The cmdev security diagnostic walks the three attack surfaces above against your specific orchestrator, worker fleet, and advisor tier, and produces a signed-provenance and principal-of-record remediation plan mapped to EU AI Act Article 14 and NIS2 evidence requirements.