Delegation is the attack surface

Picture a claims team at an insurer. The manager, call her Dana, has just been given an AI agent to work the queue. She sets it up carefully. It can approve claims up to $25,000. Anything bigger, or anything that looks like fraud, comes back to her. She writes that down, her boss signs off, and the agent gets a login to the claims system. So far, this is the responsible version of the story.

By ten o'clock the queue is 400 claims deep, so the agent does what these systems are built to do. It brings in help. It starts three smaller agents: one reads documents, one checks for fraud, one works out payments. To let them into the claims system, it hands each of them the same login it was given.

At 10:40, the payments helper settles a $40,000 claim. Approved and paid.

Nothing broke. No alarm went off. Every login was valid. Dana's rule, the one her boss signed, never reached the helper, because there was nowhere for it to go. That handoff, from one agent to another, is the attack surface. This article is about why it happened, and what a safe handoff looks like.

Why it happened

Go back to the morning and look at where the $25,000 rule actually lived. There were three places it could have been, and it matters which ones enforced it.

The first place was Dana's document, the one her boss signed. It is a real control in the sense that a person is accountable for it. But no system reads it. The claims system does not know it exists.

The second place was the lead agent's instructions. When Dana set the agent up, she told it the limit, and the agent followed it. It is worth being precise about what that means. The limit was a line of text in the agent's instructions, and the agent, being a language model, read that text and behaved accordingly. That is guidance, not enforcement. It works until the agent is reading something else.

At ten o'clock the lead agent split the queue. It wrote a fresh set of instructions for each helper. The payments helper's instructions said, in effect, "settle these claims." The $25,000 limit was not in them. Why would it be? The limit had been given to the lead agent, about the lead agent. Nothing in the framework required it to be passed along, and the lead agent had no reason to think of its helpers as separate from itself. It was just getting the work done. The $40,000 claim was in the batch because the lead agent was splitting by volume, not by risk.

The third place was the claims system's own permission check. This is the only one of the three that is enforced by software, and it is the widest. The login the lead agent holds has the right to approve claims. That is what the claims system checks: does this login have the approve function, yes or no. Most business systems work this way. Permissions are switches on functions, not limits on amounts. The claims system has no field that says "up to $25,000," and even if it did, nobody would have set it, because the rule was written for the agent, not for the system.

Now put the three together. The rule lived in two places that nothing enforces, and was absent from the one place that does. When the lead agent started its helpers, it gave them the only thing it had that would get them into the claims system: its login. The login carried the approve right and nothing else. The payments helper read "settle these claims," saw a $40,000 claim, called the approve function, and the claims system checked the login and said yes. Every part of the system did exactly what it was built to do.

That is why this is not a bug that someone can patch. The helper did not break a rule. The rule was never in a form a helper could receive.

Handing off work is the whole point

It would be easy to read that story and conclude that agents should not be allowed to start other agents. That would be the wrong lesson. Handing off work is not a bug in these systems. It is the reason they are useful. A single agent that has to do everything itself is slow and clumsy. One that can split a job into pieces and give each piece to a specialist is how real work gets done, and it is how the frameworks from every major vendor are designed. Supervisors hand tasks to workers. Planners hand steps to doers. Increasingly, when an agent "uses a tool," the tool is another agent.

So the goal is not to stop the handoff. The goal is to make sure the right things travel with it.

What the helper actually gets

Think about what moves when a person delegates. When Dana's boss gave her the right to approve claims, three things came with it: a limit, the conditions, and a record of who granted it and when. If an auditor ever asks why Dana approved a particular claim, that record is the answer. Every regulated company runs on this. It is usually called a delegation of authority matrix, and it is boring precisely because it works.

Dana's helpers got none of those three things. They got a login, which answers one question: are you allowed in? The keys, and none of the rules.

To be fair to the identity world, there is a standard for passing a login from one service to another, and it has existed since 2020. It is called OAuth token exchange, and it does something useful: it records that service B is acting on behalf of service A. But the standard itself says that this chain of who is acting for whom is informational. Nothing is required to enforce it. A newer proposal, still an individual draft at the IETF with no working group behind it, would make that chain verifiable. Even that proposal is about who is acting. Nobody is yet working on carrying what each actor was allowed to decide.

That is the whole gap in one sentence. The login travels. The mandate does not.

1

What travels at the handoff

The login is copied to every agent in the chain. The rules stop at the first one.

Where it goes wrong

Once you see the gap, the failures are easy to predict. Here are three.

The first is the one Dana hit. The helper does something the lead agent was not allowed to do, using the lead agent's own login. In the security world this pattern has had a name since 1988: the confused deputy. A program with authority acts on behalf of something that should have had less. What is new is that agent frameworks now create confused deputies on purpose, dozens at a time, in the normal course of a morning.

The second is quieter. A planning agent writes out the steps for a job and hands each step to a worker. Each worker reads its step, decides what it means, and acts. By the third handoff, the original instruction has been reworded three times by three different models, none of which ever saw the limit Dana set. Nothing malicious happened. The rule just did not survive the translation, because there was no place for it to live.

The third happens after someone notices. Say Dana's team spots the $40,000 approval at noon and shuts the lead agent down. Good. But the three helpers were started an hour ago with their own copies of the login, and nothing ties them to the lead agent. They keep working until their logins expire. The parent is contained. The children finish the job. And because helpers like these can live for a few seconds or a few hours, a tool that scans for agents once an hour may never have seen them.

None of this is a secret. OWASP, the group that publishes the standard lists of software risks, put out its Top 10 for AI agent applications in December 2025. Agents inheriting or passing on credentials without proper limits is on it. So are insecure agent-to-agent communication and failures that cascade from one agent to the next. The risk is known. What is missing is the layer that does something about it at the moment of the handoff.

2

Where it goes wrong

Three ways. In each one, every login check passes.

The helper does what the lead could not

It holds the lead agent's login, so nothing stops it.

The rule does not survive the rewording

Each handoff restates the task. The limit fades out.

Shut down the lead, the helpers keep going

Nothing ties their logins to the one you revoked.

What should happen at the handoff

Here is what I think a safe handoff looks like. This is my position, not an industry standard, and I would rather be argued with than nodded at.

At the moment one agent tries to hand work to another, four questions have to be answered. Not afterward, in a log. Right then.

Is this agent allowed to hand off work at all? Being able to delegate is itself a right, and most agents should not have it. Dana's lead agent might. The document reader it started should not.

Who is it handing off to? The helper has to be something the system can name and hold to account, even if it only exists for eight seconds. And you have to be able to follow the chain back from the helper, to the lead agent, to Dana, to her boss. If the chain does not end at a person, nobody authorized it.

How much is it handing off? Never more than it holds. If the lead agent can approve up to $25,000, no helper can be given $25,001, and no combination of helpers can add up to more. This has to be enforced by the system, not written in a guideline. It also has to stay true: if Dana cuts the lead agent's limit at noon, every helper's limit drops with it.

Who signed off? Every handoff carries a record of who approved it, when, and with what limits. When an examiner asks how a helper came to hold the authority it used, the answer is a chain of those records that ends at a human being.

3

Four questions at the handoff

Asked the moment one agent tries to hand work to another. No list of every agent needed first.

One more thing: chains should have a maximum length. A handoff of a handoff of a handoff is something nobody can review. A sensible limit on how deep delegation can go is the difference between a chain a risk team can understand and one that grows until it breaks.

Notice what none of this requires: a list of every agent in the building before you start. The questions are asked about the handoff itself, at the moment it happens. That is the only place they can be asked, because the helper may not exist until the lead agent needs it, and may be gone a minute later.

4

A chain that holds

Each link fits inside the one above it. The chain starts at a person, and shutting one agent down reaches every agent under it.

Handing off work is the feature. The handoff is what you govern.Safer agents. Stronger business.

Why this is the weak spot

An attack surface is the set of places where something unauthorized can get in. Right now the attention goes to prompt injection, where a bad instruction gets into an agent. That matters. But a bad instruction only matters if the agent has the authority to act on it. Delegation is where that authority gets copied around without anyone checking. An injected instruction in an agent with a tight, enforced mandate produces a blocked action and a record. The same instruction in an agent whose helpers all carry its login produces a completed transaction and an investigation.

My prediction, and it is a prediction, is that 2027 will be the year companies learn this the hard way, one multi-agent incident at a time, and that the post-mortems will keep landing on the same sentence: the helper had access it should never have been given, and nobody gave it. I would be happy to be wrong. What would prove me wrong is agent frameworks shipping handoffs that are bounded, traceable to a person, and revocable by default, before the incidents arrive.

Start with one question

You do not need a new tool to start. Go find your most capable agent, the one that can approve, pay, change, or send. Ask whether it can start other agents. If it can, ask what they can do that it cannot, and who decided. If the answer is "whatever the framework does by default," you have found the surface. Dana did, at 10:40 on a Monday.

---

Sources. IETF RFC 8693, OAuth 2.0 Token Exchange, January 2020 (actor claim; prior actors treated as informational). IETF Internet-Draft draft-mw-oauth-actor-chain-01, Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange, June 15, 2026, individual submission, not adopted by a working group (it replaced draft-mw-spice-actor-chain, first published April 2026). OWASP Top 10 for Agentic Applications 2026, published December 2025 (ASI03 Identity and Privilege Abuse, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures). Norm Hardy, "The Confused Deputy," ACM SIGOPS Operating Systems Review, 1988. The four-question framework is my position. The 2027 forecast is my opinion.