AI Agent Delegation: Keeping the Chain of Authorization Intact

Last week I asked a simple question: for the last thing an agent did, how long would it take you to name who authorized it –  If Your Logs Can’t Tell a Person From an Agent, You Don’t Have Proof?

This week I want to make that question harder. Because in a lot of environments, the agent that did the thing isn’t the agent anyone authorized.

Here’s how it happens. An employee asks an agent to pull together a quarterly vendor report. Perfectly legitimate. The agent decides it needs help, so it calls a second agent to query the finance system and a third-party tool to enrich the vendor data. The second agent, in turn, calls a script that writes the results somewhere. By the time the report lands in the employee’s inbox, four or five components have touched systems the employee never thought about.

Now something goes wrong in step three. Who authorized that?

Trellix just surveyed 600 CISOs at companies with more than 1,000 employees. Among the 587 that reported an insider incident, AI or autonomous systems accounted for 28% of incidents on average. Help Net Security’s write-up describes the pattern well: agents “run tasks on delegated credentials and make decisions no human individually approved.” And 92% of those CISOs say their own accountability has grown.

Trellix sells security, so read it with that in mind. But the shape of the problem is right. Agents are acting for people. And increasingly, agents are acting for agents who are acting for people.

Delegating a task isn’t delegating your keys

Michael Scott, CISO at Immuta, said the thing I’d put at the top of every multi-agent design review. In a Help Net Security interview last week: “An agent shouldn’t be able to hand off all its permissions just because it’s handing off a task.”

That sentence separates two things most agent setups treat as one. Delegating a task means asking someone else to do part of the work. Delegating your permissions means giving them everything you’re allowed to do. In practice, when one agent calls another, the second one often runs with the same token, the same service account, or the same user context as the first. The task got split. The authority got copied.

Scott describes how fast that gets away from you: “An employee might ask an agent to do something perfectly legitimate. That agent could then bring in another agent or use an outside tool to help finish the job. By the time the work is done, the original employee may have no idea which systems were accessed along the way.”

And then the part that connects back to last week: “If all you have is a log showing that a service account accessed sensitive data, that doesn’t tell you who authorized it or why it was needed.”

If a sub-agent can do anything the agent that called it can do, you don’t have delegation. You have duplication.

Why this is getting urgent

Two things from the past week make me think this isn’t a someday problem.

The first is speed. In Booz Allen’s isolated OT lab, frontier AI models with no source code, no engineering documents, and no OT guidance achieved every objective across eight scenarios. In one test they went from a perimeter compromise to actions inside an industrial control network in just over 16 minutes. Existing defenses blocked or slowed some actions, but no single safeguard consistently stopped them.

That was an attack test, not a study of agent delegation, so I don’t want to stretch it. But the researchers’ recommendation is exactly the right one for multi-agent design: focus on “making their environments difficult to traverse, removing implicit trust,” and “limiting what an attacker can affect after gaining access.” Implicit trust is what most agent chains run on. Agent B assumes that if agent A asked, agent A was allowed to ask. At machine speed, every hop nobody checks is a step nobody has time to review.

The second is the supply chain of things agents call. Bitsight tracked 16 underground forums from February through August 2026. Mentions of AI agents, indirect prompt injection, and MCP rose 67%. It also described a campaign of roughly 7,600 fraudulent GitHub repositories, more than 800 of which posed as AI skills or MCP servers, including a lookalike “Docker MCP Gateway.” When an agent delegates to a tool, that tool is part of the chain of authority. If you didn’t verify where it came from, you’ve handed your permissions to a stranger.

We already know how to delegate

Here’s the encouraging part, and it’s the same point we’ve made all series. This isn’t new territory. We just need to check our basics.

Think about how delegation of authority works in finance. A director with a signing limit can delegate approvals to a manager. But the manager can’t approve above the director’s limit. And the manager usually can’t re-delegate without its own limits. Delegated authority narrows as it moves down. It never grows, and it never copies wholesale. Every audit committee understands that, and every ERP system enforces some version of it.

The identity world wrote the same idea down years ago. RFC 8693, the OAuth 2.0 Token Exchange standard, draws a line that maps almost perfectly onto the agent problem. It distinguishes impersonation from delegation:

• With impersonation, A “is given all the rights that B has within some defined rights context and is indistinguishable from B.”
• With delegation, “principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B. In a sense, A is an agent for B.”

The RFC literally uses the word agent.

Look at that distinction next to last week’s problem. When Eric Woodruff described his agent working under his own credentials, so the record pointed at him, that was impersonation. The agent was him, as far as the log knew. What we want is delegation: the agent keeps its own identity, acts for the person, and the record says so.

RFC 8693 goes one step further, which is the step multi-agent systems need. A chain of delegation can be expressed by nesting actor claims, where “the outermost act claim represents the current actor while nested act claims represent prior actors.” The RFC describes those nested claims as “a history trail that connects the initial request and subject through the various delegation steps undertaken before reaching the current actor.”

That’s Scott’s ask, already written into a standard: follow the chain of authorization all the way back to the original request.

One nuance worth knowing. The RFC says that for access control decisions, the receiving system should only consider the current actor; prior actors in the chain “are informational only.” That’s actually the right design. It means each hop has to carry its own narrowed scope. You can’t rely on the chain to limit what the current agent does. The chain is your evidence. The scope at each hop is your control.

If you run ITIL, you’ve seen this pattern too: a standard change is pre-authorized only within a defined scope, and anything outside it goes back for approval. Same idea, applied per hop.

You don’t need a whole new world view for this. You need one filter: look at how your organization already delegates authority between people, and ask whether your agents follow the same rules.

Messages aren’t authority

There’s one more piece that’s specific to agents, and it’s the one I see missed most often.

When a person delegates to another person, the instruction comes through a channel you recognize: a manager, a ticket, an approval. When agents work together, instructions arrive as text. A tool output. A web page. A message from another agent. And a lot of agent frameworks treat that text as if it carries the authority of whoever started the chain.

Microsoft’s draft Humanist AI Code of Conduct for its MAI models, which SecurityWeek covered in September, takes a clear position on this. Authority flows only through a “Chain of Command”: the code itself, then the operators deploying the model, then users. Tool outputs, file contents, webpages “and messages from other AI systems carry no authority on their own,” unless explicitly delegated through that chain. The draft also says models are barred from escalating their own access, and that sub-agents must honor stop-work or shutdown requests.

That’s a draft, for Microsoft’s own models, and the article notes the current MAI models haven’t been trained on it. But the principle is the one enterprise architects should adopt regardless of which models they run. A message from another agent is input. It isn’t permission.

Five rules for agent handoffs

If you’ve followed the Artificial Identity work [LINK: FuBAC and Artificial Identity], these will map to attributes you’ve already defined: Capabilities, Conditionals, Owner, Lifecycle, and Termination conditions. The difference this week is applying them at every hop, not just to the first agent.

1. Scope narrows at every hop. The next agent gets only what its piece of the task needs. Never more than the caller holds, and usually much less.
2. The original request travels with the work. Every downstream action should carry a reference to the person and request that started the chain. That’s the nested actor trail, in whatever form your platform supports.
3. A message from another agent isn’t authority. Treat it as input to be evaluated against policy, not as an instruction that inherits the caller’s rights.
4. Permissions end when the subtask ends. No standing access for a sub-agent just because the chain might need it again. This is the week 14 credential lesson, applied per hop.
5. Verify what you hand work to. Every tool, MCP server, and plugin in the chain needs a known source and a named owner. If you wouldn’t give a stranger your badge, don’t give one your token.

The platforms are starting to build for this

You won’t have to invent all of this, and the market is moving in the right direction.

ServiceNow announced AI Passport last week: a cryptographically signed credential that agents refer to at runtime to verify their authorized scope at every step of a multi-agent workflow. ServiceNow describes “scoped delegation that narrows at each step,” precision revocation, and a verifiable permissions record for third-party agents, rather than trusting what the agent says about itself. No availability date was given. The same announcement notes that LTM assigns each of its 1,500 agents an employee ID and a manager, which is the Owner attribute in plain operational terms.

I’m citing that as a signal, not a recommendation. The point is that a major platform vendor is building to the same rule: scope shrinks as work moves down the chain. Expect auditors to start asking whether yours does.

Where the real work is

In TechVision’s five-layer agent governance model, delegation stresses two layers at once. Discrete identity with defined scope has to hold for every agent in the chain, including the ones nobody provisioned directly. And runtime access enforcement has to evaluate each hop on its own, not wave it through because the first agent was approved.

What we see in advisory work is that the first agent usually gets real governance. It’s in the inventory, it has an owner, someone reviewed its scope. The sub-agents and tools it calls often don’t. They’re spun up by the framework, they run under the caller’s credentials, and they never appear in the access review. Everyone assumes the owner of the first agent is responsible for everything downstream, but that owner often doesn’t know what’s downstream. If that sounds familiar, the fastest win is usually an inventory question, not a tooling one: for each governed agent, list everything it can call, and check whether each of those has its own identity and scope.

Four steps to start

1. Map one chain end to end. Pick a production agent and trace every agent, tool, and service it can call. Most teams find at least one hop they didn’t know about.
2. Check what each hop inherits. Does the sub-agent run with its own identity and narrowed scope, or with the caller’s token or service account? If it’s the caller’s, that’s duplication.
3. Make the chain visible in the record. Whatever your platform supports, nested actor claims, a session ID bound to the originating user, or a request ID carried through every call, make sure downstream logs can be joined back to the original request.
4. Apply your delegation-of-authority policy to agents. Your organization already has rules for how people delegate signing and approval authority. Write the agent version, and make it say the same thing: authority narrows as it moves down.

The bottom line

Most organizations have started governing their agents. That’s real progress. But governance that stops at the first agent misses where the risk is going. The work gets passed along, and too often the full set of permissions goes with it.

We don’t need to invent anything here. Finance has run delegation of authority for decades. The OAuth Token Exchange standard has separated delegation from impersonation and described a chain of actors back to the original request, since 2020. The rule is the same in both: authority shrinks as it moves down the chain.

So here’s the question I’d bring to your next architecture review. Not “is this agent governed?” Ask instead: when this agent hands off work, what goes with it?