Agent Governance Foundation

The Delegation Problem: When Agents Spawn Other Agents

Agent Governance Foundation
delegationmulti-agentauthorizationarchitecture

Multi-agent systems are the next frontier of AI deployment. Rather than a single agent handling a complex task end-to-end, an orchestrator delegates to specialist agents: one for research, one for code, one for communication, one for data access. Each does what it's best at. The orchestrator coordinates.

The architecture is compelling. The governance problem it creates is underappreciated.

The medieval parallel

Delegation is not a new problem. Medieval scholars called it the agent problem — the difficulty of ensuring that an agent (a representative) acts in accordance with the principal's (the delegating party's) actual intent, not their interpreted or embellished version of it.

A king delegates authority to a duke. The duke delegates to a sheriff. The sheriff delegates to a bailiff. By the time authority reaches the person doing the actual work, how much of the original intent survives? How do you prevent scope creep — the bailiff doing things the king never sanctioned because it served the sheriff's interests?

Five hundred years later, corporate law invented the fiduciary duty and the corporate chain of command to solve this problem. Agency law built an entire body of doctrine around principal-agent relationships.

AI agents haven't solved this problem — they've imported it.

How it manifests in multi-agent systems

Consider a concrete example:

An orchestrator agent (agt_root) is authorized to access customer data and write summaries to an internal wiki. It delegates a research subtask to agt_research, which has read access to customer data. agt_research delegates a data retrieval step to agt_fetch, which actually calls the database API.

When agt_fetch calls the database, what is it actually authorized to do?

In most current multi-agent implementations, the answer is: whatever the authorization system of the database API allows for the credential it was handed. That credential was probably generated at startup, applies to a service account, and has no relationship to the delegation chain that got us here.

agt_root was authorized to access customer data. Does that mean agt_fetch is authorized to access all customer data? Any customer data? Only the data relevant to the task? What if agt_fetch decides to read something adjacent while it's in there?

These are not edge cases. They're the normal operation of a multi-agent system without delegation governance.

The right model: constrained delegation

The principle that should govern multi-agent authority transfer is the same one that governs human delegation in well-run organizations: a delegate cannot have more authority than their principal, and should usually have less.

Formally:

  • An agent can only delegate capabilities it actually possesses
  • A delegated credential should be narrower in scope than the parent's credential
  • Every delegation step should be logged and traceable back to the original authorization
  • Delegation should be time-bound — a delegated credential shouldn't outlive the task it was created for
  • Either party in a delegation chain should be independently revocable

This model is familiar from OAuth 2.0's token delegation flow and IETF RFC 8693 (Token Exchange). Those weren't designed with AI agents in mind, but the underlying logic applies.

Delegation chains in practice

The AGF authorization model represents a delegation chain as a list of agent identifiers, ordered from orchestrator to current actor:

POST /v1/decide
{
  "chain": [
    "did:agf:agt_root",
    "did:agf:agt_research",
    "did:agf:agt_fetch"
  ],
  "action": { "type": "read:data", "resource": "customers" },
  "audience": "database.internal"
}

The PDP evaluates the entire chain — not just the calling agent. It checks:

  • Is agt_root authorized to access customer data? (Yes)
  • Is agt_root permitted to delegate? (Check its policy)
  • Is agt_research authorized to receive this delegation?
  • Is agt_fetch authorized to execute it?
  • Does the delegation narrow appropriately at each hop?

The policy for agt_root might say: "may delegate read:data to child agents with depth ≤ 2." The policy for agt_fetch might say: "may only read:data when chain depth ≥ 2 (i.e., must be a delegated call, not a direct call)."

Every decision in this chain is logged, with the full chain captured in the audit artifact:

{
  "artifact_id": "art_3nXpQz",
  "chain": ["did:agf:agt_root", "did:agf:agt_research", "did:agf:agt_fetch"],
  "chain_depth": 3,
  "action": { "type": "read:data", "resource": "customers" },
  "decision": "ALLOW",
  "trust_score": 74,
  "policy_version": "v7"
}

Branch-cut revocation

The other side of the delegation problem is termination. If an orchestrator agent is compromised or misbehaving, how quickly can you stop the entire tree it's spawned?

Without explicit delegation tracking, the answer is: slowly. You find all the child agents, revoke each one, hope you didn't miss any, and deal with the window where compromised agents were still active.

With branch-cut revocation, a single call suspends the entire subtree atomically:

POST /v1/revoke
{
  "agent_id": "did:agf:agt_root",
  "cascade": true,
  "reason": "orchestrator_compromised"
}

Response:

{
  "revoked": [
    "did:agf:agt_root",
    "did:agf:agt_research",
    "did:agf:agt_fetch",
    "did:agf:agt_writer"
  ],
  "count": 4,
  "artifact_id": "art_rEvk4Zp"
}

Four agents suspended in one operation, at the database level, with an audit record. No windows, no partial states.

The trust score dimension

Delegation also creates an interesting problem for trust scoring. How should a child agent's trust score relate to its parent's?

One approach: the child's effective trust score is min(parent_score, own_score). This enforces the constraint that the delegation can't launder distrust — a high-trust child can't operate with more trust than its low-trust parent.

The AGF trust model implements this through the delegation chain: when evaluating trust for an action by agt_fetch, the scoring function considers the trust scores of every agent in its chain, not just its own.

What to do now

If you're building multi-agent systems today, the practical steps are:

  1. Register every agent — each agent definition needs a stable identity, not a shared service account
  2. Pass delegation chains — include the full chain in every authorization call, not just the immediate caller
  3. Scope delegated credentials — when an orchestrator creates a sub-agent, its authorization should be a subset of the orchestrator's, not a copy
  4. Wire branch-cut revocation — know exactly which agents are running under which orchestrator, so you can terminate the tree when needed
  5. Audit the chain — every authorization decision should capture the full delegation chain, not just the terminal actor

The AGF Authorization Service handles delegation chain evaluation, trust propagation, and branch-cut revocation out of the box. See the architecture →

All posts