Agentic AI security curriculum · Security overview
Multi-Agent Trust Hierarchies and Orchestrator Security: Delegation, Result Integrity, and Blast Radius Isolation
Delegation, Result Integrity, and Blast Radius Isolation
Hello and welcome to Module 14!
Modules 1–13 have hardened single-agent security from supply chain all the way through runtime enforcement. Now we extend those controls to multi-agent pipelines and orchestrators.
A single agent with strong Panguard rules and sandboxing is a solved problem. A pipeline of agents where each node implicitly trusts the last one is not. Implicit trust creates new attack paths that single-agent defenses cannot see: injection at the orchestrator that fans out to every subagent, a compromised midpoint subagent that fabricates results, or lateral movement between pipeline nodes.
In this module we build verifiable identities, signed instructions, signed results, downward-only delegation, and pipeline-level cumulative risk scoring so that multi-agent systems are as auditable and blast-radius-bounded as single-agent deployments.
Why Single-Agent Security Controls Are Insufficient for Pipelines
Each node in a pipeline already has its own:
-
Panguard enforcement
-
ATR claims
-
Sandbox (Kata or gVisor)
But the edges between nodes have no controls by default. Orchestrators and subagents trust each other implicitly over NATS.
Three new attack paths unique to multi-agent systems emerge:
-
Inject at the orchestrator input → fans out to every subagent.
-
Compromise a midpoint subagent → fabricate results that downstream nodes treat as trusted.
-
Lateral movement between pipeline nodes.
Zero trust must apply between agents as strictly as it does between agents and external systems.
Verifiable Agent Identity in Pipelines
Every pipeline node receives a unique cryptographic identity from the cluster CA (Module 4).
The certificate SAN encodes the exact position in the pipeline:
clawql://pipeline/doc-analysis/node/2
How it works:
-
The gateway validates the presenting agent’s certificate against the declared pipeline topology.
-
An agent presenting a certificate for node/2 cannot publish to the node/3 subject namespace.
-
New pipeline nodes receive certificates through the same cert-manager flow used for service workloads.
If a node is compromised, its certificate is revoked immediately. All in-flight messages from that identity are rejected within one TTL cycle.
ATR Delegation: Scope Only Downward
Orchestrators hold the full ATR scope for the overall task and delegate the minimum subset needed for each step.
The subagent’s session JWT contains a delegated_scope field. The gateway enforces:
-
Only the intersection of the orchestrator’s claims and the delegated claims is allowed.
-
Attempting to delegate a claim the orchestrator does not hold returns 403 DELEGATION_VIOLATION.
Every delegation chain is recorded in the audit log entry for every tool call. The full authorization path is always reconstructable.
Authenticating Orchestrator Instructions at the Subagent
Instructions travel over NATS JetStream with two layers of protection:
-
mTLS (from the zero-trust mesh in Module 4)
-
Message-level signature
The orchestrator signs the full instruction payload with its private key before publishing. The subagent verifies:
-
Correct subject namespace
-
Valid orchestrator certificate
-
Signature over the message body
The instruction payload is also validated against a JSON Schema. Any out-of-schema content is rejected as potential injection. Panguard additionally flags any instruction containing known injection-pattern keywords.
Result Integrity: Subagents Cannot Fabricate
Subagents sign their result payload before publishing it back to the orchestrator.
The orchestrator verifies the signature before incorporating the result into its context. Panguard blocks context incorporation if signature verification fails.
Consequences of a failed verification:
-
Session is immediately quarantined
-
Alert is fired
-
The signing subagent’s certificate is queued for revocation
The fabricating subagent is identified by its certificate fingerprint in the message.
Blast Radius Isolation Between Pipeline Nodes
Each pipeline node runs in its own Kata Container with a dedicated NetworkPolicy. There is no direct pod-to-pod communication.
All messages route exclusively through the NATS broker. Subject-level ACLs enforce:
-
Each agent can publish only to its own subject namespace
-
Each agent can subscribe only to its declared inputs
Even with full code execution inside a node, the compromised node cannot reach a neighboring node.
Panguard also tracks cumulative session risk across the full pipeline (not just per node). If the combined behavior of all nodes crosses a threshold (>3 blocked calls, >5 sensitive data accesses, >10 MB external egress), the entire pipeline is halted.
Panguard Pipeline-Level Rules
Panguard supports a special rule scope: pipeline_session.
Example pipeline-level rules:
-
3 blocked calls across any nodes in the pipeline
-
5 sensitive data accesses across the pipeline
-
10 MB total external egress across the pipeline
When a threshold is crossed:
-
The entire pipeline halts
-
Audit trail is preserved
-
Alert is fired
This catches slow-moving attacks that stay under per-node limits by distributing suspicious actions across many nodes.
Key Takeaways (Memorize These!)
-
Implicit trust between agents is the fundamental architectural mistake — every edge in the pipeline graph requires explicit authentication.
-
ATR delegation must always scope downward — a subagent with broader claims than its orchestrator is a privilege escalation vulnerability.
-
Signed instructions and signed results make both instruction injection and result fabrication detectable at the moment they occur.
-
Pipeline-level cumulative risk scoring is the control that catches slow-moving attacks that evade per-node rate limits.
You now have a complete trust architecture for multi-agent pipelines. Orchestrators and subagents can no longer trust each other by default. Every instruction and every result is cryptographically verifiable, and the blast radius of any single node is strictly limited. This brings the same zero-trust discipline we built for single agents to the full multi-agent world.
