Security · 2026-07-06

Trust Propagation When Your Agent Spawns Its Own Workers

By J. W. Bouckaert

The governance question nobody answered

Every serious agentic framework shipping in 2026 (LangGraph, Microsoft AutoGen, CrewAI, OpenAI's Agents SDK) now supports one pattern that identity architects have not caught up with: a primary agent that spawns its own sub-agents at runtime, hands them a slice of its authority, and expects them to spawn more. What began as "one agent calling one tool" has quietly become a directed acyclic graph of delegators, where the leaf worker executing a payment or a database write is three, four, sometimes six hops removed from the human who consented to any of it.

The industry has a name for that structure. It does not have a working answer for how trust propagates across it.

This article is that answer. We model capability attenuation across hops, we bound the blast radius when hop N is compromised, and we describe the mechanics PasskeyBridge uses to keep the trust chain cryptographically auditable when delegation depth exceeds three, which is where most non-trivial multi-agent deployments end up once their orchestration graphs stabilize.

Signed tokens fail past two hops

The naive answer is familiar: issue a signed token to the primary agent, let it mint downstream tokens for its children, and trust the signatures. This works for one hop. It survives, barely, at two. It falls apart at three, and here is exactly why.

At delegation depth D, an unattenuated system has D distinct signing surfaces the attacker can target. Each intermediate agent is both a verifier (of its parent's grant) and an issuer (of its children's grants). Compromise any single intermediate and every credential downstream of it inherits attacker-controlled scope, attacker-controlled TTL, and attacker-chosen sub-delegatees. The scope poisoning attack we documented earlier is the two-hop variant of this problem. The sub-agent problem is its recursive form.

The frameworks currently in production make this worse in three specific ways:

1. Mutable scope arrays. LangGraph state objects and AutoGen GroupChat messages carry scope as unsigned JSON. Any node in the graph can mutate the field before forwarding it.
2. Implicit re-delegation. A LangGraph subgraph invoked by a parent node inherits the parent's tool bindings by default. There is no explicit "narrow scope before spawning."
3. No cryptographic depth counter. Nothing in the payload forces monotonic hop counting, so a compromised intermediate can rewrite hop = 4 back to hop = 1 and reset any depth-based policy.

The frameworks are optimizing for developer ergonomics, and the criticism lands elsewhere: on pretending that framework ergonomics are equivalent to a trust model.

Capability attenuation, formally

We model each delegation edge as a strict subset operation on a capability set. Let C(a) denote the capability set held by agent a. For any delegation from a to b, the child's capability set must be a subset of the parent's, and the child's cardinality can never exceed the parent's:

C(b) ⊆ C(a)     and     |C(b)| ≤ |C(a)|

The invariant is monotone: no descendant can hold a capability its ancestor never had. Enforcement is mechanical rather than a matter of policy: scope-hash pinning at every hop, computed server-side, with the hash stored in a table the agent cannot write to.

But subset containment alone is not enough. A hostile intermediate that inherits ten scopes can still hand a leaf worker the exact ten it was given, propagating full authority to a machine with no incremental context. Real attenuation requires active narrowing, not merely non-expansion.

Three composable rules, applied in order at every delegation edge, produce the active-narrowing behavior we recommend:

The trust-attenuation factor α is the interesting one. Setting it below 1.0 means that no matter how clean the delegation chain looks, a leaf worker four hops removed from a human is treated as materially less trustworthy than the human's direct agent, and its Combined Trust Coefficient is capped accordingly. If trust(N) drops below the framework's operational threshold, the delegation edge simply does not form. The graph refuses to grow.

The depth-three cliff

Applying the attenuation rules above to a typical enterprise workload produces a characteristic risk curve. The table below models the outcome for a workload that starts at trust 0.94 at the root and applies α = 0.92 per hop, with scope-hash verification and cohort revocation enabled. It is an illustrative model rather than measured telemetry, but the shape holds under a wide range of realistic α and threshold choices:

Two structural observations follow directly from the model. First, the number of signing surfaces an attacker can target grows linearly with depth, but the number of ways a compromise can propagate to a leaf grows faster because each intermediate is both a verifier and an issuer. Second, once a leaf's modeled trust falls below common operational thresholds (0.70 is a reasonable default for high-impact scopes), the delegation edge should refuse to form at all, which is why depth-limiting is a defense in itself.

We call the transition between hop 2 and hop 3 the depth-three cliff. Before it, framework-native tooling can carry most workloads without cryptographic scope pinning and still avoid catastrophic failure. After it, it cannot, and the audit trail is the only remaining place the compromise surfaces. That is exactly why the append-only audit trail is a load-bearing component and not a compliance afterthought.

Blast-radius containment

Capability attenuation shrinks what a compromised sub-agent can do. Blast-radius containment shrinks how many other agents it can drag down with it when the compromise is detected.

The primitive here is what we call the containment cohort. Every delegation edge in PasskeyBridge is tagged with a cohort identifier drawn from the parent's cohort namespace. A single compromise event revokes the smallest cohort containing the poisoned edge, leaving the rest of the chain intact. This is analogous to how SPIFFE uses trust domains, but recursive: cohorts nest, and the parametric revocation cascade walks only the affected subtree.

Concretely, when the shield-agent-delegate function detects a scope-hash mismatch at hop N:

1. The offending delegate is suspended immediately.
2. The cascade fires against hop N's cohort and every cohort strictly below it.
3. Siblings of hop N whose cohorts are peers rather than descendants are left untouched.
4. The event is written to the append-only audit log with the full pre-mutation and post-mutation scope arrays.

A worked example. In a six-hop chain A → B → C → D → E → F, if D is compromised, PasskeyBridge revokes D, E, and F, tears down their BLAST tunnel sessions, and invalidates any A2A trust negotiations they participated in. A, B, and C continue to operate. If A had also delegated a peer branch to X → Y, that branch is not touched. The cascade runs inside the request that detected the compromise, on the same response path we apply to every hard signal.

Keeping the trust chain auditable past three hops

The last question, and the one every CISO asks before signing a check, is: can you actually prove what happened after the fact? In a six-hop chain, "the agent decided to do this" is not an acceptable answer.

PasskeyBridge's answer is a canonical delegation manifest written at every edge. Each manifest entry is a JSON object canonicalized with JCS (RFC 8785) and signed with the parent's key. The entry contains:

{
  "parent_delegate_id": "d_a2b1...",
  "child_delegate_id":  "d_c9d4...",
  "depth": 3,
  "cohort_id": "coh_x7...",
  "scopes": ["read:crm", "draft:email"],
  "scope_hash": "sha256:...",
  "ttl_seconds": 900,
  "trust_at_issue": 0.79,
  "issued_at_utc": "2026-07-06T14:22:03Z",
  "parent_signature": "es256:...",
  "parent_signature_pq": "ml-dsa-65:..."
}

The dual signature is deliberate. The classical ES256 signature validates today; the ML-DSA-65 signature satisfies the FIPS 204 post-quantum baseline so that a chain issued in 2026 remains verifiable when Q-day arrives. This is the same hybrid signature scheme PasskeyBridge applies to cached proofs and cross-reference attestations.

Manifest entries chain by including parent_delegate_id. Verification of a leaf action walks the chain up to the human root, verifying each signature and re-computing each scope_hash. A single link that fails to verify invalidates the entire chain. There is no "trust the intermediate hops" mode; verification is end-to-end or it is nothing.

Framework choice

We are frequently asked which framework "solves" the sub-agent problem. The honest answer: none of them do, because it is a trust-model problem, and it has to be enforced outside the framework, at the identity layer that mediates every delegation edge.

This is not a failing of the framework authors. Frameworks optimize for the developer experience of composing agents. Trust propagation is an operational concern that lives at a lower layer, next to authentication, authorization, and revocation. Placing it inside the framework would be a category error, and would break the abstraction that makes these frameworks useful in the first place.

What framework choice does determine is how easily you can wire in an external identity layer. LangGraph and AutoGen expose sufficient hooks in their tool-invocation paths to interpose scope-hash verification without patching the framework. CrewAI is harder, primarily because role config is fixed at graph-compile time and does not naturally accept runtime-attenuated capability sets.

Recommendations for teams deploying multi-tier agents

If you are running, or about to run, agent hierarchies deeper than two hops, five principles apply regardless of framework:

1. Measure your delegation depth in production. Vendor slides show hop-1 architectures. Your production p95 depth is almost certainly higher. Instrument it before you argue about it.

1. Enforce active attenuation, not just non-expansion. Subset containment is necessary. It is not sufficient. Trust must strictly decay with depth or you have no principled reason to treat a hop-6 worker as less than the human that authorized the chain.

1. Adopt cohort-based revocation. All-or-nothing revocation punishes clean branches for their siblings' compromise. Nested cohorts limit the blast radius to the actual affected subtree.

1. Sign every edge, verify end to end. Trusting intermediate signatures without walking the chain to the root is how compromised intermediates go undetected for weeks. Verification is a chain property, not a hop property.

1. Assume Q-day is inside your credential lifetime for long-lived manifests. Chains issued in 2026 with 90-day TTLs will still be under audit in 2030. Sign with a hybrid scheme now; you will not get a second chance.

The broader shift

The sub-agent problem is one arc of a broader shift: identity systems built for humans holding credentials are being asked to arbitrate machines holding credentials that delegate to machines that delegate to machines. The frameworks are ahead of the trust models. Some of the assumptions baked into OAuth 2.0 delegation flows do not survive contact with a six-hop graph.

PasskeyBridge treats delegation depth, cohort containment, and end-to-end signed manifests as first-class primitives. As agentic architectures deepen, and they will, the systems that survive are the ones that measured the problem before it became an incident. Identity, again, is an engineering discipline and never a configuration setting.

Design a delegation topology that holds past hop three →

Start free · Test the API