Agent Sub-delegation Passes Full Credentials. You Approved a Scoped Action.

Most agent frameworks pass the parent agent's credentials to sub-agents without modification. The scope your user approved for the parent silently becomes the scope every downstream agent operates under.

This is not a theoretical risk. It is the default behavior.

When you build an orchestrator that spawns execution agents, those sub-agents are typically initialized in the same runtime, with the same environment variables, the same tool registry, the same API key. The spawning mechanism does not issue a scoped token for "task 3: read document X and return summary." It hands the sub-agent whatever the parent had.

The sub-agent for task 3 can write to the database. It can trigger webhooks. Nothing about the invocation restricted it to read. The scope was described in the prompt, not enforced in the credential.

Prompt-scoped authorization is not authorization. It is instruction. The distinction matters when something goes wrong — or when a regulator asks you to prove it could not.

What the EU AI Act requires

Article 9 of the EU AI Act requires high-risk AI systems to operate under a risk management system that identifies and controls risks "throughout its entire lifecycle." A delegation pattern that silently expands credential scope is a lifecycle risk. It must be identified, and the controls must be demonstrable — not asserted.

Article 17 requires documented technical measures ensuring the system functions as intended. If an agent is authorized to read a record and delegates that operation to a sub-agent carrying full read/write credentials, the technical measures have failed to constrain actual execution scope, regardless of whether the sub-agent chose to stay within bounds.

Neither article specifies the implementation. Both require that you can demonstrate the problem was solved — not that the system happened to behave correctly.

How the gap opens in practice

Consider a planning agent that decomposes a task and spawns execution agents for each subtask. The planning agent has read/write access to a file store, database write access, and credentials that can trigger outbound webhooks.

The execution agents each receive a task description. In most frameworks, initialization does not narrow the tool registry or issue a restricted token per-task. The executor for "summarize document" has the same available tools as the executor for "update customer record." Nothing in the spawning call established a boundary.

If the summarization executor makes an unexpected database write — due to a tool call gone wrong, a prompt injection in the document content, or a model hallucination — the log shows the write happened. It does not show whether the executor was supposed to have write access. Without a credential scope record at invocation time, you cannot reconstruct whether this was an authorized action or an overstep.

The log shows the call. It does not show the scope.

Most audit systems capture what was called and what was returned. They do not capture what credentials were available at the time of the call.

This creates a blind spot: if a sub-agent operates within scope, the log looks correct. If it operates outside scope, the log looks identical unless every tool call is recorded alongside the authorization context that was active during execution.

EU AI Act Article 13 requires that high-risk systems are interpretable and that their outputs can be explained. An audit trail that cannot distinguish between "sub-agent stayed within approved scope" and "sub-agent had full parent credentials and happened not to use them" is not interpretable for compliance purposes. It can confirm that a call was made. It cannot confirm that the call was within the authorized boundary.

What scoped sub-delegation requires

Proper credential scoping for sub-agents requires three capabilities that most teams are not building:

A token issuer at delegation time. When the planner spawns an executor, it should request a scoped token with exactly the permissions the executor needs — not forward its own. This means an authority that can issue tokens, a schema for declaring scope, and a binding between the token and the specific sub-agent invocation.

Scope captured in the execution record. The log entry for any action by a sub-agent must include the credential scope that was active at invocation time, not just the action itself. "Executor wrote to database" means nothing for compliance without "executor held credentials scoped to: read:document-123."

Cryptographic binding between scope and invocation. A sub-agent claiming in its own log that it only had read scope is not evidence. A token issued at invocation time, signed by the issuing authority, and embedded in the execution trace is evidence. The distinction is that the first is self-reported and mutable; the second exists independently of what the sub-agent reports about itself.

None of these requirements are satisfied by environment variable inheritance, shared API key pools, or describing scope constraints in the system prompt.

Where independent attestation fits

The binding problem — proving that a specific scope was issued and active at the moment a specific action ran — is exactly what signed execution records address. ArkForge's Trust Layer records delegation events as certified actions: not just "agent A called agent B," but "agent A delegated to agent B with declared scope S, at time T, under signing authority K." The receipt exists outside the agents' own logs.

When regulators or auditors ask for evidence that your system enforced least-privilege delegation, a signed delegation receipt from an independent attestation layer is the artifact. The sub-agent's own log is not, because it was produced by the sub-agent and cannot prove what that sub-agent was permitted to do.

This is the same principle behind signed commit chains in software supply chain security: you don't trust the binary's claim about where it came from. You trust the signed record that exists outside the binary.

Intermediate steps if you are building today

If Trust Layer integration is not in your current build cycle, there are visible steps that reduce the gap without closing it entirely:

Document every sub-agent spawn with an explicit scope assertion in a structured log field — not inside the prompt, not in the agent's context window, but in a record that exists outside the agent's own reporting chain.

Audit your tool registries at initialization time. When a sub-agent starts, does it inherit the parent's full tool set, or does initialization explicitly restrict available tools? If the answer is "inherits," you have implicit scope expansion as a default that must be treated as a risk, not an assumption.

Review your MCP server configuration. Per-session, per-agent scoping is possible in the MCP protocol and it requires explicit configuration. Most deployment guides skip this step. Most production deployments run with uniform permissions across all connected agents.

These steps make the scope expansion visible. Visibility is the precondition for control — but it is not control.

The compliance question is about proof, not behavior

The most common objection to this framing: your sub-agents are well-behaved. They do not use permissions they should not have.

This is probably true. It is not sufficient.

EU AI Act Article 9 requires that risks are controlled, not that they fail to materialize. An audit that can only show "nothing went wrong" cannot demonstrate that controls prevented something from going wrong. The difference is significant when certifying a high-risk system, and decisive when an incident occurs and you need to show the boundary was enforced before the fact — not that the sub-agent chose to stay within it after the fact.

Credential scope in sub-delegation is a control gap. It exists regardless of whether any sub-agent exploits it. Closing it — with scoped tokens, independent issuance, cryptographic binding to the invocation record — is what converts "our agents behaved correctly" into evidence that satisfies Article 9.

The behavior of your agents in production is not the certification artifact. The control structure at invocation time is.