Access Control Propagation Across Multi-Agent Pipelines

I've watched access control break in the same way for twenty years, and multi-agent pipelines are just the newest place it happens. Log in once, get trusted for the whole session: that was the old deal. That arrangement doesn't survive contact with a chain of agents, each one calling its own tools, data stores, and other agents, where one over-permissioned hop poisons everything downstream of it. I want to walk through how permission propagation is supposed to work, where it actually falls apart once real traffic hits it, and what infrastructure closes the gap.

Start with the distinction that trips people up constantly: authentication versus authorization. Authentication answers "who are you," while authorization answers "what are you allowed to do." OAuth, SSO, and identity providers settled the first question years ago. The second one, enforced at the level of a single tool call buried ten steps into an agent chain, is nowhere close to settled, and most teams building on this stuff right now find that out the hard way.

Model Context Protocol is where I've seen this play out most. Anthropic put MCP out as an open standard in November 2024; it now sits under Linux Foundation governance. People call it the "USB-C for AI," and for once a tech analogy actually holds up: one common way for agents to call tools and other agents, instead of a custom integration for every pairing. Monthly SDK downloads hit 97 million by early 2026, which means this isn't a pilot program anymore. Propagation failures aren't a risk sitting on some roadmap; they're happening right now, at volume, in production systems people are betting their companies on.

What faithful permission propagation actually requires at each agent hop

Propagation isn't handing off a token like a baton in a relay race. Done right, every downstream agent only acts inside the overlap between its own permissions and whatever the original requesting user was actually allowed to do. Three things have to travel with each hop: identity, meaning who kicked this off; scope, meaning what that person can actually touch; and context, meaning what's already been approved earlier in the same chain.

Underneath all of it sits one design principle: constrained delegation. A sub-agent runs on its own narrow credentials, scoped tight to the job in front of it. A parent agent's permissions should never just cascade downward by default. Systems that ignore this rule all converge on the same failure: the most privileged agent in the chain effectively sets the permission floor for every agent below it.

The MCP server is where this gets enforced, or quietly doesn't. Agents don't touch a company's CRM or document store directly; they ask the server to do it for them. That makes the server the real enforcement surface, whether anyone built it to act like one or not. If the underlying system already has role-based access, say a CRM where reps see their own accounts and managers see everyone's, the server should read those existing scopes rather than invent some parallel permission model of its own.

At minimum, a hop needs six things checked: OAuth 2.0 authentication with credentials kept out of the model's context window, role- and attribute-based authorization checked per operation, audit logs tied to a specific identity, path and scope restrictions, rate limiting, and a check against data sensitivity labels. None of this is exotic, since API security has needed this discipline for a decade. What's different here is duration and reach. An agent session runs long, touches a dozen tools in one pass, and carries access tokens with real privilege behind them. A leaked credential in a single REST call is bad, but a leaked credential sitting in an agent's context for the length of a multi-step pipeline is worse, by a wide margin.

The default behavior that enterprises are actually shipping

MCP itself takes no position on governance. The protocol runs the same whether the server behind it enforces tight scopes or none at all. Most implementations I've come across got built for developer convenience, full stop, not for anyone's security team to sleep well at night.

The out-of-the-box default: an MCP agent inherits the full permission scope of whatever application is orchestrating it. That sounds abstract until you watch it happen in front of you.

Give an agent read access to a project directory, and by default it can also read the config files sitting in the folder next door, the ones with API keys in them, because nobody scoped the read permission down to the files it was actually supposed to touch. A sub-agent spun up by an orchestrator inherits the orchestrator's full scope, no narrowing step in between. This is the confused deputy problem, textbook version: the server holds broad privilege, the user doesn't, and the server acts on its own privilege instead of checking what the user was actually cleared to authorize.

Credential handling makes it worse in the most boring possible ways, the kind that never show up in anyone's threat model until they do. Database connection strings get hardcoded straight into MCP server manifests. A single OAuth app registration gets shared across five different MCP servers, so compromising one means compromising all five. Nothing in the base protocol forces a parent agent to hand a sub-agent a narrower token at handoff. Someone has to build that narrowing on purpose, having actually thought it through in advance, and most teams shipping fast skip that step.

There's been real progress on part of this, to be fair. Enterprise-Managed Authorization, EMA, is stable now and adopted by Anthropic, Microsoft, and Okta. It moves the authorization decision into the company's identity provider instead of leaving it to whoever happened to configure the MCP server that week, which counts as genuine improvement. EMA is upfront, though, about what it doesn't cover: it never inspects MCP traffic after a token gets issued. It governs the front door, and what happens once an agent is inside is still on whoever implemented the rest.

Where propagation breaks and what attackers exploit when it does

Three failure modes keep showing up. Over-provisioned scope passes to a sub-agent with nobody narrowing it first. Tool poisoning happens when a manipulated tool description tricks the model into acting outside its intended lane. Prompt injection happens when adversarial content buried in retrieved data hijacks the agent mid-pipeline and redirects its next move.

The numbers here aren't abstract. Research using the MCPTox benchmark found tool poisoning attacks succeed 84.2% of the time when auto-approval is switched on, meaning the agent acts on a tool's instructions with no human checking first. A separate scan of public MCP servers found 43% carried command injection flaws, and 5.5% had active tool poisoning vulnerabilities sitting there live, waiting.

2025 handed us real incidents, not thought experiments. Asana's MCP server had a cross-tenant isolation flaw that exposed project data across roughly 1,000 organizations, a scope-bleed bug baked into the server itself, nothing any user did wrong. The official GitHub MCP server got hit with a prompt injection that pulled private repository contents out into the open, because the agent followed instructions buried in the data it was reading instead of the instructions its actual user gave it. A compromised npm package impersonating the Postmark email MCP server ran clean, identical to the real thing, for several releases, before it quietly started copying every outgoing email to an address the attacker controlled. That's a supply chain compromise, and it walked past every perimeter control because it never looked like an intrusion from the outside.

Not every failure even needs an attacker in the picture. Picture an agent told to migrate a project directory to a new location. It reads the config files sitting in that directory, including the ones holding production API keys, and copies everything over faithfully, then reports the job done. Nobody jailbroke it, and nothing got injected. It just did exactly what it was told, and in doing so, walked credentials straight past the boundary they were supposed to stay inside.

Gartner's numbers show where this is heading. By 2028, according to Gartner, roughly a quarter of enterprise generative AI applications are projected to see five or more minor security incidents a year, up from 9% in 2025. Separately, 15% are projected to have at least one major incident annually by 2029, up from 3% today. Over-provisioning isn't a theoretical surface. It's active, it's being exploited right now, and it's scaling right alongside MCP adoption itself.

How the authorization layer has evolved to address propagation, and where it still falls short

The protocol has matured. OAuth 2.1 became the required authorization baseline for remote MCP servers in the March 2025 update, and November 2025 tightened it further: stricter proof-of-possession checks, closed gaps in token handling, official support for asynchronous operations and server identity verification.

What OAuth 2.1 actually standardizes, though, is narrower than most people assume. It governs the handshake: how a model discovers a tool and calls it. It says nothing about how authorization logic gets implemented inside the server, or how scopes get enforced once a call actually comes through.

EMA fills part of that gap. It moves the authorization decision into the enterprise identity provider, so a single sign-on replaces a pile of repeated per-server consent prompts, a real fix for a real annoyance, and it centralizes who's allowed to connect to what. The spec is honest, though, about its own limits: EMA decides whether a user can connect a client to a server, and at what scope. It has nothing to say about individual actions once that connection already exists.

So here's where things actually stand. The protocol now gives enterprises a reasonable foundation at the connection level, but action-level authorization, what an agent is actually allowed to do once it's plugged in, is still the organization's job to build. That's where policy-as-code engines like Open Policy Agent or Cedar Policy earn their keep: evaluating each operation against a policy stored in a version-controlled repository, pushed out through the same GitOps pipeline the company already uses for application code. Pair that with short-lived, scoped tokens issued per MCP server registration, never shared across agents, and you've got the credential discipline that limits how far one compromised token can spread. The protocol grew up a lot in two years, but it still can't do the implementation work for you.

The registry and gateway as the two pieces of runtime governance infrastructure

Without something enforcing all this at runtime, governance is just a policy document nobody's system actually reads. Agents can discover tools fine, but nothing stops them from misusing what they find once they connect.

Two pieces of infrastructure handle two different jobs here, and I see people conflate them constantly. A registry handles discovery and cataloging: what MCP servers exist, what each one exposes, who owns it, which version is live. A gateway handles runtime enforcement: is this specific agent allowed to call this specific tool, under what scope, within what rate or cost limit.

You need both, and neither substitutes for the other. A registry with no gateway means agents can find every tool in the company, but nothing checks whether they should be calling it, so scope drift and shadow connections go completely unnoticed. A gateway with no registry means agents get governed access, but only to a fixed list someone had to hand-configure, which falls apart the moment the company adds its fiftieth integration.

A working registry tracks server identity, ownership, version history, which scopes each consuming team is cleared for, and how sensitive the data behind it actually is. A working gateway checks the calling agent's identity, checks that identity against what the registry says it's allowed to do, redacts personal data where required, applies rate limits, and writes a full record of the call. Skip this infrastructure and you get shadow AI: teams standing up their own MCP servers with nobody else knowing, integrations nobody's tracking, IT with zero visibility into what's actually wired to what. That's exactly the fragmentation that lets propagation paths multiply out of control.

The goal is a governed registry where approved skills are published company-wide, permissions inherit from the underlying source system, and MCP servers are scoped per team rather than shared indiscriminately — with discovery and enforcement treated as a unified concern, which is the part most homegrown setups get wrong.

Operationalizing least privilege across a live pipeline

Least privilege isn't a setting you configure once at launch and forget about. It's a decision made at every hop, which means it has to be designed into the pipeline from the start, not patched on after something goes wrong.

Each sub-agent in a chain needs its own credentials, scoped narrowly to what it actually does, never a copy of its parent's full token. When an orchestrator hands work to a sub-agent, that sub-agent's effective permissions should be the narrower of two things: what it's entitled to on its own, and what the original user is allowed to do. Never the broader of the two, and never an expansion.

Sensitivity labels need to work as an actual gate, not a metadata field nobody ever looks at. Before an agent pulls or forwards data, its classification should get checked against the requesting identity's clearance, with a block or a flag when the two don't line up. Audit logs need attribution: which agent made the call, on whose behalf, using which token, what came back, rather than a vague line saying a call happened somewhere. Policy changes deserve the same review discipline as application code: version-controlled, pushed through a pipeline, traceable to a named approver and a timestamp.

Auto-approval deserves its own callout, because it's a concrete switch to flip, with measurable consequences either way. MCPTox found an 84.2% tool poisoning success rate with auto-approval on; turning it off and requiring a human check for higher-risk actions is one of the cheapest controls you can flip today. Build the broader habit alongside it: treat every pipeline as an attack surface to model, not just a workflow to ship, and ask what the blast radius looks like if the single most privileged agent in the chain gets compromised, then design backward from that answer.

What governance at the organizational level, not just the pipeline level, requires

One well-built pipeline with tight access control doesn't add up to enterprise governance. You need the same enforcement showing up across every pipeline, every team, every model in use, not a patchwork where quality depends entirely on who happened to build which piece.

Without shared infrastructure, five different teams end up building five different versions of the same permission logic, none of them consistent with each other, none feeding a shared audit trail. That's not just wasted effort. It's exactly the kind of fragmentation that makes a security incident almost impossible to trace after the fact, once something has actually gone wrong.

Governance also has to survive a team switching models or bolting on a new AI interface. Permissions, business context, and guardrails should travel with the organization's data and identity systems, not get rebuilt from scratch every time someone picks a new vendor. Gartner has warned that more than 40% of agentic AI projects could get scrapped by 2027 over governance problems, and the pattern behind that number isn't complicated: the projects that skip governance early are the ones cancelled later, once the cost of retrofitting becomes obvious to everyone in the room.

Central IT shouldn't own every decision here, either. The teams closest to sensitive systems, finance, legal, HR, engineering, actually know what counts as sensitive and who should see it. Central IT's job is enforcing the framework consistently across all of them, not deciding what belongs in it. None of this counts as governance unless it's auditable, either. A company that can't reconstruct who approved a given agent action, under what authorization, and when, has a record of good intentions and little else.

Credal's approach, a company-wide registry with permissions inherited automatically from source systems and every skill version-controlled, is one shape this infrastructure can take, built so no single team has to solve it alone. The point holds no matter which vendor you use, though: decisions about how permissions propagate through a pipeline need to happen before that pipeline ships. Bolting access control onto a system that's already touched sensitive data is a far harder problem than designing it in on day one, and I haven't seen an exception yet.