Delegated Authorization in Multi-Agent AI Systems
Enterprises deploying thousands of AI agents have no way to control what they're authorized to do.
Enterprises are hiring AI agents faster than they can figure out who's actually in charge of them. Gartner projects that by 2028, large enterprises will run well over a hundred thousand agents apiece, up from a handful just a few years back. That growth curve outruns every existing system for deciding what an agent gets to do, on whose behalf, and for how long. The mechanism that's supposed to answer those questions is called delegated authorization, and right now it's the least solved piece of the entire agentic stack. Get delegation wrong, and every downstream promise about AI agents, speed, autonomy, scale, turns into an audit nightmare wearing a chat interface.
What delegated authorization actually means when agents are the principals
Delegation used to be simple. A user clicks "Allow" on an OAuth prompt, an app gets to read their calendar for as long as the token lasts, one human, one grant, one bounded scope. That model assumed a human sat at the top of every request. Fine assumption, until it wasn't.
Agents break it. The thing asking for access is now a piece of software invoked by another piece of software, which itself got invoked by a user who may have logged off an hour ago. There's no single delegator anymore, just a chain of principals passing authority down the line, one to the next, except some links in that chain are AI models improvising in real time about what to do with what they've been handed.
A few terms are worth pinning down, since the industry throws them around loosely and that looseness is half the problem. A principal is whoever's identity backs a request: human, service account, or agent. Delegation means handing part of that authority to someone or something else. A delegation chain is the ordered path authority travels, user to orchestrator to sub-agent to tool, and every link is a decision somebody has to answer for later. Attenuation is the rule meant to keep the whole thing from spiraling: delegated authority should never exceed what the delegator itself holds, and each hop narrows the scope instead of widening it.
Human-to-app delegation never had to plan for agents spinning up other agents mid-task, so the shape of the chain is often unknown before the workflow even starts. It never had to plan for actions happening at machine speed either, where one bad permission ripples across thousands of tool calls before anyone watching a dashboard notices. And it definitely never accounted for a delegate outliving the intent of whoever created it. An agent kicked off by a Tuesday afternoon request might still be running Thursday night, long after the user who triggered it moved on to something else entirely.
How OAuth 2.0 and token-passing approaches break down in multi-hop agent workflows
Ask most engineering teams how they handle agent-to-agent authorization today, and the honest answer is they pass the user's OAuth token down the chain and hope. It's the path of least resistance. It's also wrong, in ways that become obvious the moment more than two agents start talking to each other.
Start with ambient authority. A user's token carries everything that user can do, not the sliver relevant to the task at hand. Hand that token to a sub-agent that only needs to read one spreadsheet, and you've handed it the ability to do anything else the user could do. Compromise that one agent and you've compromised the user's entire permission set, not the narrow piece the job called for.
Then there's leakage. Every hop where a token gets passed is a place it can land in a log file, get scraped by an attacker, or get injected into a request it was never meant to authorize. Researchers have already documented agents wandering around with access far beyond what their job requires, simply because nobody built the plumbing to scope things down hop by hop.
Worse, a downstream service receiving that token sees the original user's identity and nothing else. No idea three agents relayed the request before it got there. Audit logs lose every intermediate actor, so when something breaks, and something eventually does, nobody can reconstruct which link failed. Layer scope explosion on top, where a sub-agent aggregating permissions from multiple upstream principals ends up with an effective access level none of those principals ever intended, and you've built an authorization surface nobody actually designed.
OAuth 2.0 was built for one hop: user to app. Stretching it across three or four agent layers takes extensions the protocol was never built to carry. The Model Context Protocol added OAuth 2.1 support to its spec, which helps some, but implementation varies from server to server. Protocol-level auth on paper doesn't mean a governed delegation chain in practice; a two-agent demo where one token gets passed around looks clean in a conference talk, but run that same pattern across thousands of concurrent workflows in production and the authorization surface becomes something no team can review by hand, ever.
The threat landscape that ungoverned delegation enables
Security researcher Johann Rehberger showed in 2025 how a compromised GitHub Copilot agent could write malicious instructions straight into another agent's configuration file, instructions that ran as attacker-controlled code the next time that second agent started up. Not a hypothetical. A delegation chain turned into a weapon against itself, one agent trusting another the way it would trust a human coworker.
Prompt injection is the more common version, and it's nastier because it needs no stolen credentials and no malware at all. A single sentence buried in a webpage, a retrieved document, or a code comment can redirect an agent's behavior mid-task. The agent keeps operating under whatever authority it was legitimately delegated; it just starts pointing that authority somewhere the attacker wants it pointed instead. Prompt injection sits at the top of the OWASP Top 10 for LLM Applications in the 2025 edition, so the security community isn't filing this under fringe concerns. CVE-2025-53773 made the stakes concrete: a hidden prompt injection buried in a pull request description let attackers reach remote code execution through GitHub Copilot, scoring 9.6 on the CVSS scale, about as bad as vulnerability scoring gets.
This keeps happening for a structural reason, not bad luck. Agents routinely carry far more access than the workflow needs, so even a lazy injection attempt can pay off big. The delegation boundary was never enforced in the first place, so nothing stands between "agent tricked into misbehaving" and "agent misbehaving with access to everything." Agents also move data at a volume and speed no human session comes close to, so one compromised agent under broad delegation turns into an exposure event that scales with every system it happened to touch.
Audit logs make the blind spot worse, not better. When tokens pass down the chain without a record, a compromised agent's actions show up under the original user's name. Incident response ends up staring at a log that says "Sarah from procurement did this," when Sarah had nothing to do with it and no way to prove otherwise. All of this sits on top of a shadow AI problem that's already out of hand: Reco's 2025 State of Shadow AI Report found 91% of AI tools running in enterprise environments operate outside IT's visibility, with organizations averaging 269 shadow AI tools apiece. That's a lot of ungoverned agents doing ungoverned delegation, invisible to the people whose job is catching exactly this.
What a principled delegation chain requires technically
The fix is easy to describe and hard to build. Every agent in a chain needs a credential that's verifiable and scoped, one that encodes who delegated what to whom, not a copy of the original user's permissions riding along for the trip.
In practice, that means each hop mints a new token instead of forwarding the old one. That new token should be narrower than its parent and carry the full delegation history baked in, so a service three hops downstream can look at it and reconstruct exactly how authority got there: user to orchestrator, orchestrator to sub-agent, sub-agent to tool call. Scopes narrow at every step, and an orchestrator can't hand out permissions it was never granted itself.
Agents also need real identities. Not a shared service account everyone borrows, not somebody's old user token recycled out of convenience, but a stable, non-human identity tied into the same identity provider governing everyone else: Okta, Entra ID, whatever SAML or OIDC setup the enterprise already runs. That's what lets existing role-based access control, lifecycle management, and access reviews apply to agents the same way they already apply to employees. Right now, only about a fifth of enterprises have anything resembling a formal agent identity strategy. That gap is not small.
Enforcement can't live inside the model itself. Authorization decisions need a deterministic control layer sitting outside the agent, checking every tool call against policy the moment it happens, not just at the moment the original delegation was granted. Tokens should be time-bound and task-bound, expiring or narrowing automatically once the triggering job finishes. And every step needs a log entry: who started the workflow, which agents got pulled in, what scopes moved where, which tools got called, what data got touched. That log is the difference between "we think something went wrong" and "here's exactly what happened and where it broke."
None of this works without attenuation as the rule underneath it, and that rule is non-negotiable: no agent acts on permissions its delegator didn't hold. Enforcing that mechanically, rather than trusting the model to police itself, separates governed delegation from the token-passing free-for-all most teams run today.
Where the MCP gateway fits in the delegation architecture
Enforcement has to live somewhere, and the logical spot is wherever agents meet tools. That's the MCP gateway. It sits between every agent and every tool call, which makes it the one point in the system where the entire delegation chain is visible at once and policy applies consistently instead of piecemeal.
A gateway earns its keep on every single request. It checks the calling agent's identity before anything gets routed. It confirms the agent's current token actually covers the scope of the tool being requested, rather than just checking that the original human had access somewhere upstream. It applies role-based policy at the moment of the tool call, not just when the connection first opened. It logs every call with full chain provenance, which agent, delegated by whom, on whose behalf, and it turns away connections from MCP servers nobody's approved, keeping shadow tools out of the picture.
Consider the math without this layer. Ten agents, each needing access to five tools, means fifty separate integration points, each one a place security has to be configured and watched on its own. A gateway collapses those fifty points into one governed entry, which is the only way this scales past a demo. There's a cost angle too, one people underrate: without gateway-level enforcement, nothing stops an agent from calling an expensive API endpoint in a loop with no ceiling in sight. Cost control and authorization control turn out to run through the same plumbing.
None of this has to cost you on performance, which is the objection everyone raises first. Bifrost's benchmarks show internal overhead of 11 microseconds at a sustained high request throughput, numbers that make the latency argument against gateway enforcement hard to sustain with a straight face. And as agent-to-agent protocols mature alongside MCP, the gateway needs to see both, not just one. Google's announcement of the Gemini Enterprise Agent Platform in April 2026 tells you the rest of the industry landed on the same answer: one enforcement layer that understands multiple agentic protocols, not a pile of point solutions bolted on after the fact.
How enterprise identity providers anchor the delegation model in practice
A delegation chain is only as trustworthy as the identity sitting at its root, which is why agent identity can't live in a separate system from human identity. It has to anchor to the same directory, full stop.
Okta, Entra ID, and SAML/OIDC-based identity providers already solve most of the hard problems for humans: one source of truth for roles and group membership, lifecycle management that pulls access the moment someone changes jobs or leaves, and audit trails that feed straight into whatever SIEM or compliance tooling already runs. What's left is extending that same infrastructure to represent agents as first-class, non-human principals, each with its own credentials, its own rotation schedule, and a clear link back to the human or system it acts for.
Once that extension exists, role-based policy at the delegation layer gets defined once, in the identity system, instead of copy-pasted into every agent's configuration separately. Which agents can delegate to which other agents, and what each role in that chain touches, becomes a directory-level decision instead of something buried in application code nobody remembers writing.
Shared service accounts are the opposite of this, and they need to go. The moment two agents share one identity, nobody can say which one did what. Revoking access means revoking it for everyone sharing that identity at once, or leaving the risk in place for all of them because pulling the plug feels too disruptive. Neither option holds up at scale. Tie agent activity to IdP-managed identities instead, and compliance stops being a special project: the same access-review process auditors already run for human accounts applies to agents, no parallel workflow required.
What governed delegation looks like end to end in a real agentic workflow
Picture a procurement workflow. A user kicks it off through an AI assistant, the orchestrator agent spins up a contract-analysis sub-agent and a separate vendor-data sub-agent, and each of those sub-agents needs to touch systems holding genuinely sensitive information.
The user authenticates through single sign-on, and the orchestrator gets issued a scoped token derived from that session, one that encodes the user's identity and only the roles relevant to this specific workflow, nothing more. When the orchestrator delegates to the contract-analysis sub-agent, it doesn't hand over a copy of its own token. It mints a new one, narrower, granting document-read access and nothing beyond what the orchestrator itself holds. That sub-agent calls a document tool through the MCP gateway, which checks the token, confirms the scope covers document-read, logs the call with the full chain attached, and only then routes the request through. The vendor-data sub-agent gets its own separate token, scoped strictly to read-only access on the vendor database; it has no path into contract storage, because nobody delegated that scope to it in the first place. Once the workflow wraps, both sub-agent tokens expire and the orchestrator's token gets revoked, nothing left lingering around waiting to be misused later.
The audit log at the end tells a complete story: user identity, orchestrator identity, both sub-agent identities, every tool call made, the scope asserted at each one, and exactly what data got touched. A full reconstruction of the workflow's authorization history, available on demand, not stitched together after the fact from partial logs and best guesses.
Now say the contract-analysis sub-agent pulls in a document with a hidden prompt injection trying to redirect it toward the vendor database. The gateway doesn't care what the agent got talked into wanting. It checks the token, sees the scope doesn't cover vendor-database access, and blocks the call. The injection succeeded at manipulating the model. It failed at going anywhere, because the enforcement never depended on the model's judgment to begin with.
