Your AI agent booked a gathering, summarized a monetary report, and emailed the highlights to 3 stakeholders. To do that, it referred to as a calendar agent, a doc evaluation agent, and an electronic mail agent. Every accessed inner programs, made selections about what to incorporate, and acted in your behalf.

Right here’s the query your safety group can’t reply: Who approved the e-mail agent to learn that monetary report?

In most present architectures, the trustworthy reply is nobody explicitly. The logs might present {that a} service referred to as one other service. However they’ll’t present that the delegation itself was approved. The authorization didn’t fail loudly. It leaked silently by way of the chain.

That is the delegation drawback in multi-agent AI. As enterprises join brokers by way of protocols corresponding to MCP and A2A, they’re fixing the connectivity drawback quicker than they’re fixing the authority drawback. The result’s a brand new safety boundary that the majority enterprise architectures haven’t but modeled, exactly as a result of most organizations nonetheless deal with it as orchestration fairly than authorization.

Brokers are connecting quicker than authorization is adapting

The agent ecosystem has moved quick over the previous two years. Anthropic’s MCP gave model-powered purposes an ordinary method to hook up with instruments, information sources, and providers. Google’s A2A protocol gave brokers an ordinary technique to talk and coordinate throughout programs. Frameworks and SDKs corresponding to LangChain, CrewAI, and Google’s ADK made it simpler to construct multi-agent workflows the place one agent orchestrates a number of others.

What these protocols don’t but present, at the least not as a mature frequent layer, is a delegation-aware authorization mannequin.

MCP describes a protected server as an OAuth 2.1 useful resource server, with the MCP shopper performing as an OAuth shopper making requests on behalf of a useful resource proprietor. That’s a well-recognized and well-understood sample, however it was designed for a world the place a human clicks “Enable” and a single shopper will get a scoped token. It doesn’t deal with what occurs when Agent A receives that token, delegates a subtask to Agent B, and Agent B spawns Agent C to deal with a part of it. Every hop in that chain both reuses the unique token (overprivileged) or has no token in any respect (untracked).

A2A was constructed for interoperability: impartial, doubtlessly opaque agent programs speaking and coordinating actions throughout enterprise platforms. That’s the best drawback to resolve. However communication and delegation governance are completely different layers. A2A helps brokers uncover, describe, and talk with each other. That is essential infrastructure, however it isn’t the identical as delegated authority. It doesn’t let you know whether or not a selected downstream motion was legitimately derived from an upstream instruction.

Static API keys are even weaker for this drawback. A key grants entry to a service. It says nothing about who’s utilizing it, what they’re utilizing it for, or whether or not the entity presenting it’s the similar one it was issued to. Service accounts determine a workload, not an intent. When three brokers share a service account, each motion seems to be the identical in your logs.

None of those instruments are damaged. They clear up completely different issues. The hole is structural. Authentication solutions which agent is asking. Authorization defines what that agent might entry. The tougher query, and the one most enterprise architectures are usually not but designed to reply, is whether or not a selected downstream motion was legitimately derived from an upstream instruction, underneath narrowed constraints, with a verifiable chain again to a human determination. That’s the delegation query, and it sits in a layer that in the present day’s stack doesn’t actually have.

In a clear model of this image, privilege ought to sit solely with the agent that touches the surface world. If a payer (A) asks a bookkeeper agent (B) to make a fee, and the bookkeeper asks a banking agent (C) to execute the switch, solely the banking agent wants banking authority. The bookkeeper doesn’t want to maneuver cash. It solely must know the request got here from a licensed payer. The banking agent solely must know the request got here from a licensed bookkeeper. That is the precept of least privilege, an idea the safety neighborhood has lived with for many years, utilized to delegation chains. The issue is that in the present day’s agent stacks make it arduous to implement.

What breaks within the chain

Take into account a treasury reporting workflow in a regulated financial institution. A planning agent is allowed to learn liquidity projections and produce a each day abstract for senior finance customers. To finish the duty, it delegates chart era to a visualization agent and narrative overview to a communications agent. The visualization agent doesn’t want entry to uncooked account-level information. The communications agent doesn’t want entry to the underlying liquidity mannequin. But except the delegation layer attenuates permissions, each might obtain extra context than their activity requires. The consequence isn’t a dramatic breach, however it’s a quiet growth of entry that the access-control mannequin by no means explicitly authorised.

The danger isn’t restricted to internet-facing brokers. Many delegation failures occur completely contained in the enterprise boundary. An inner agent might name one other inner agent, which calls an inner device, which sends information to an authorised SaaS service. Each particular person step might look acceptable. The danger seems within the composition: The ultimate information motion or motion might exceed the intent of the unique authorization.

This sample creates three classes of failure that enterprises might have to clarify to regulators, auditors, or clients.

Ghost permissions. A finance analyst assistant has been given entry to a buyer transactions database to assist quarterly reporting. It calls a summarization agent: “summarize current transactions for these accounts.” The summarization agent now operates towards buyer information, regardless that no coverage engine granted it that entry. The analyst assistant’s privileges successfully traveled with the request. The permission is a ghost. It exists in apply however not in any authorization system.

Scope drift. Even when an agent begins with slender permissions, delegation tends to widen scope fairly than slender it. An agent approved to learn Q1 income information delegates to a charting agent, which calls an exterior rendering API, which now has the income figures. The information left the group by way of three hops of implicit belief. Every agent acted inside what it understood as its scope. The mixture consequence exceeded what any human would have authorised.

Damaged audit trails. Regulated industries require the power to reply “who did what and why” for any consequential motion. In a single-agent system, that is manageable. In a multi-agent chain, the audit path fragments throughout brokers, protocols, and providers. When a compliance group asks why a specific buyer communication was despatched, the reply may contain 4 brokers throughout two protocols, none of which logged the delegation chain. The motion is traceable to a system however to not a choice.

These aren’t edge circumstances. They’re a standard consequence when delegation isn’t modeled explicitly. The delegation drawback isn’t a bug in any specific framework. It’s a spot within the layer between them.

What a delegation-aware mannequin requires

A delegation-aware authorization mannequin has to resolve 4 issues directly, which is a part of why no present layer covers it cleanly.

The primary is identification. The downstream agent wants a cryptographic credential that the receiving system can confirm independently, not only a hostname or an API key. Hostnames lie. API keys journey. An actual identification is one the calling system can’t fabricate.

The second is attenuation. When an agent delegates a activity, the subagent ought to obtain strictly fewer permissions than the guardian—by no means the identical set, and positively by no means extra. That is the precept of least privilege utilized to delegation chains, and nearly no present tooling enforces it by default.

The third is function. “Learn this report back to summarize liquidity publicity for the CFO” is a distinct authorization from “learn this report and ship chosen figures to an exterior charting service.” It might be the identical information and the identical agent, however it’s two very completely different danger profiles. With out a function binding, the authorization layer has no technique to distinguish them.

The fourth is audit. The group ought to have the ability to reconstruct, after the very fact, who delegated what, underneath which constraints, and what proof every agent produced at completion. Not simply which programs had been referred to as however which selections had been made and on whose authority.

It’s attainable for brokers to authenticate efficiently even after they don’t have accountable authority. They will show who they’re and nonetheless execute actions that no human ever approved.

Rising approaches

A number of efforts deal with components of this drawback: workload identification requirements, agent metadata in tokens, OAuth-based MCP authorization, A2A authentication patterns, and agent identification frameworks. These are helpful constructing blocks, however identification is just not the identical as delegated authority. A signed agent card might help set up an agent’s declared identification and capabilities. An OAuth token can let you know what a shopper might entry. Neither, by itself, proves {that a} particular downstream motion was approved by a selected upstream determination underneath narrowed constraints.

One rising sample is delegation-bound functionality tokens: short-lived credentials that bind an invocation to an agent identification, a constrained permission set, and a provenance document. One instance is the Agent Id Protocol (AIP), which I’ve been engaged on as an Web-Draft and open supply implementation. AIP remains to be early, however it illustrates the form of 1 attainable reply: invocation-bound tokens that carry identification, attenuated permissions, and provenance by way of a delegation chain. The token chain itself turns into a part of the audit proof fairly than one thing reconstructed after the very fact from fragmented logs.

Complementary approaches are additionally rising. Behavioral credentials, the concept that brokers must be constantly reauthorized primarily based on runtime conduct fairly than simply preliminary permissions, deal with a associated however distinct drawback. Delegation tokens let you know who approved what. Behavioral monitoring tells you whether or not the agent remains to be performing inside its approved profile. A whole answer will possible want each.

None of those approaches have reached mainstream adoption. However the truth that they’re rising concurrently, from completely different corners of the business, alerts that the delegation hole is actual and acknowledged.

What enterprise groups ought to do now

You don’t want to attend for requirements to mature earlier than addressing the delegation drawback. There are concrete steps that safety, platform, and structure groups can take in the present day.

Map your delegation chains. Most groups deploying multi-agent workflows haven’t documented which brokers name which different brokers, with what permissions, by way of which protocols. Begin there. When you can’t draw the graph, you’ll be able to’t safe it.

Audit implicit permissions. For each agent-to-agent interplay, ask: Was this entry explicitly granted, or is the downstream agent inheriting permissions by proximity? If the reply is inheritance, you will have a ghost permission that wants a coverage determination.

Require scope attenuation. Set up an architectural rule: When an agent delegates a activity, the subagent should obtain fewer permissions than the guardian, by no means extra. Present tooling doesn’t implement this routinely, however you’ll be able to implement it in your orchestration layer.

Construct the audit path earlier than the auditor asks. In case your group is in a regulated business, the query “Who approved this agent motion?” will ultimately be requested. The time to instrument delegation logging is earlier than that query arrives, not after. Log the total chain: which agent initiated the duty, what permissions had been handed, which subagents had been invoked, and what each accessed.

Check with actual tooling. Delegation-aware approaches, together with capability-token designs, workload identification requirements, and agent identification frameworks, are early however practical. Operating one in a nonproduction setting will expose gaps in your present authorization mannequin that structure overview alone won’t floor.

Delegation is the safety boundary

The primary section of enterprise agent adoption was about connectivity: Can the agent attain the device, the API, the database, or the opposite agent? The subsequent section will probably be about accountable delegation: Ought to this agent be allowed to ask that agent to do that particular factor, with this information, underneath these constraints?

That query received’t be answered by immediate engineering. It belongs within the authorization layer, the platform layer, and the audit path.

Enterprises don’t want to resolve your complete requirements drawback in the present day. However they do must cease treating delegation as an implementation element. In multi-agent programs, delegation is the safety boundary.