Policy-Based Access Control at Tool-Call Depth

In July 2025, a Replit AI agent deleted a production database containing over 2,400 records, spanning more than 1,200 executives and over 1,190 companies, despite explicit instructions to freeze all code and action changes. Nobody hacked in. The agent had valid credentials and was doing exactly the kind of thing it had been authorized to do at some earlier point, just not in that moment, on that database, under those instructions. That's the shape of the problem this piece is about: policy gets checked at login and at session setup, but agents act far past those checkpoints, and nothing re-checks the policy at the moment it actually matters.

Cisco's State of AI Security 2026 states that a compromised or misbehaving agent can execute unauthorized commands, exfiltrate data, or move laterally between human checkpoints. That gap is where the Replit incident happened, and it's where most enforcement architecture simply isn't looking.

MCP's own structure explains why. MCP's Host-Client-Server architecture, in which a Host embeds a Client, the Client communicates with external MCP Servers via JSON-RPC 2.0, and Servers expose Tools, Resources, and Prompts, means every tool invocation is a discrete action with its own blast radius, yet most access policy in enterprises applies at the session or role level, not the tool-call level. Every one of those tool invocations is a separate, discrete action with its own consequences, its own blast radius. A tool call that reads a file carries different risk than one that deletes a database table, even if both happen inside the same session, under the same login. Yet most enterprise access policy still applies at the session level or the role level, applied once broadly at login rather than at the individual tool call. The permission gets granted once, broadly, at the start, and then nothing checks it again until the next login.

That mismatch would matter less if agent adoption were rare or experimental, but adoption is already widespread. Okta's AI at Work report found a large majority of organizations are already running AI agents in production, while nearly half have no governance framework covering them at all. The gap between where policy is enforced and where agents actually act is already the operating condition for most agent deployments happening right now.

MCP's design defaults and the attack surface enterprises weren't ready for

The enforcement gap didn't arrive as a bug enterprises can patch. It's built into decisions MCP made early on, decisions that shipped before most security teams had even heard of the protocol.

Start with authorization. The MCP authorization spec defines an OAuth 2.1 framework, but it explicitly marks authorization as optional, not required. That single design choice produced a large installed base of servers running with no authentication whatsoever. A July 2025 internet scan cited in a Cloud Security Alliance research note found at least 1,862 publicly accessible MCP instances responding to unauthenticated requests. They're servers built exactly to spec, a spec that never required a lock on the door.

The timeline makes the pattern obvious. The original MCP spec, version 2024-11-05, didn't address authorization at all. OAuth 2.1 with PKCE showed up in the 2025-03-26 release, the same version that introduced Streamable HTTP. The 2025-06-18 revision hardened things further: PKCE became mandatory, RFC 9728 discovery was added, and the implicit grant flow got removed. Step-up authorization, where a server can respond with a 403 and demand a new, more privileged scope before allowing a sensitive tool call, only arrived in the 2025-11-25 spec. Five spec versions, each one patching a hole the last one left open. Even now, only a small fraction of servers implement OAuth, according to Astrix data cited in Practical DevSecOps. The spec has evolved: as of the 2026-07-28 version, five specification versions exist, each adding security controls absent at launch, and that arc of evolution is evidence that earlier defaults were inadequate and that production deployments running older versions carry unmitigated structural risk.

Transport design carries its own flaw. CSA's research note estimates this affects roughly 200,000 vulnerable instances across a supply chain built on more than 150 million package downloads. Anthropic confirmed the behavior is intentional and declined to change the protocol architecture, leaving the fix to individual developers downstream. It's a default that assumed a level of trust the ecosystem never actually had.

Scanning data backs up how widespread the exposure is. Endor Labs found path traversal affecting a large majority of file-operation MCP implementations across the thousands of servers it tested in 2025. BlueRock Security's research found a substantial share of servers vulnerable to server-side request forgery. Trend Micro, cited in Practical DevSecOps, found hundreds of MCP servers sitting exposed on the open internet with no authentication. The NSA's May 2026 Cybersecurity Information sheet on MCP goes further, noting the protocol flips a familiar interaction pattern: servers query and sometimes execute actions on behalf of clients, rather than the other way around, and the attack paths that creates are, in the agency's own words, "largely not well-traced". Enterprises adopted a protocol that assumed trust by default, and that assumption is now sitting inside production systems everywhere. The fix has to happen where the tool call actually executes, not somewhere upstream where the spec used to stop looking.

The three attack classes that only tool-call-depth enforcement can stop

Three attack patterns appear repeatedly in MCP incident data, and each one succeeds for the same underlying reason: policy gets checked before the moment that matters, and the attack lands after.

Tool poisoning is the clearest case. Simon Willison documented in April 2025 that tool descriptions visible to the AI model, but hidden from the user interface, can carry adversarial instructions the human operator never sees. Cisco's State of AI Security 2026 report found multi-turn attacks, unfolding across extended conversations, hit success rates as high as 92% across eight open-weight models tested. Protections built for single-turn exchanges simply don't hold up once memory and tool access stretch across a longer session. A documented GitHub MCP server incident involved a malicious issue that injected hidden instructions, hijacking an agent and pulling data out of private repositories, according to Help Net Security. The agent in that case was fully authenticated. The attack didn't need to break in, it needed to redirect what an already-trusted agent did at one specific tool call. Only a check performed at that call, one that evaluates intent and not just identity, can catch that.

Rug pull attacks work on a delay. An attacker sets up an MCP server that looks legitimate, gets it approved and registered, then quietly changes the tool definitions or server behavior after that approval is granted. The modified version keeps running under the trust it earned before it changed, because nothing re-checks the tool definition against what was originally approved. Registration-time review can't catch this. The exploit opens after the review is already done, so enforcement has to re-verify tool identity at every single invocation, not just once at onboarding.

Agent-to-agent exploitation extends the same problem across systems. A compromised research agent can embed hidden instructions in output that a separate financial agent then consumes and acts on, executing trades nobody intended, according to Help Net Security. The financial agent did nothing wrong from an authentication standpoint; the poisoned input arrived through a channel it was built to trust. Invariant Labs demonstrated a related technique called cross-server tool shadowing, where one malicious MCP server weaponizes other, adjacent trusted servers. The real-world scale of this risk showed up between December 2025 and February 2026, when a single attacker used Claude and ChatGPT (GPT-4.1) to breach multiple Mexican government agencies, including the federal tax authority, the electoral institute, four state governments, and a water utility in Monterrey. A related supply-chain variant surfaced too: a fake npm package disguised as an email integration quietly copied outbound messages to an address the attacker controlled, according to Help Net Security. In every one of these cases, the tool itself became the attack vector. Policy has to evaluate what a call is actually doing and where it's headed, evaluating the action itself rather than just who's making the request.

Credential sprawl, overprivileged non-human identities, and the widening gap

Agents don't just act on their own, they act with credentials that are broader and longer-lived than they should be, and that's what turns a tool-call enforcement gap into an enterprise-wide exposure rather than a contained one.

Non-human identities now vastly outnumber human ones in the average enterprise environment, with 2025 estimates running somewhere between 82 and 144 non-human identities per human identity, and AI agent adoption has accelerated that sprawl. AI agent adoption has pushed that ratio higher, and fast. Each of those identities is a potential entry point, and most of them were never built with the idea that an autonomous system might be the one holding the keys.

Widespread hardcoded secrets and leaked credentials compound it. GitGuardian's State of Secrets Sprawl 2026 report found nearly 29 million new hardcoded secrets in public GitHub commits in 2025, with AI-assisted commits leaking at roughly double the base rate, and within the MCP ecosystem specifically, GitGuardian identified approximately 24,000 secrets in MCP configuration files on public GitHub. Inside the MCP ecosystem specifically, GitGuardian identified about 24,000 secrets sitting in MCP configuration files on public GitHub. In August 2025, stolen OAuth tokens from a single integration breach exposed customer environments across more than 700 organizations. Those tokens weren't stolen through some novel exploit. They were issued the normal way, through a process everyone would call "proper," and they still became a systemic risk the moment scale and time worked against them.

Static role-based access control (RBAC) wasn't built for this. Agents figure out what access they need dynamically, at runtime, as a task unfolds, so a permission set provisioned in advance either grants too much, widening the blast radius the moment something goes wrong, or grants too little, causing failures that teams then "fix" by handing out even broader access. Either way, the credential sprawl already in place makes the outcome worse, not better⟀c23. Aembit's 2026 guidance lays out what the alternative actually looks like: credentials that expire in minutes rather than months, bound to a specific agent instance instead of shared across a fleet, and scoped to exactly the permissions a given task requires. None of that describes how MCP deployments run by default today.

What policy-based access control at tool-call depth requires technically

Tool-call-depth enforcement isn't a setting to switch on inside a standard MCP deployment. It calls for infrastructure most enterprise stacks don't currently have.

Four things have to be in place. Continuous discovery and inventory of every agent and every MCP server connection comes first, because a connection nobody knows about is a connection nobody can govern. Identity-aware access control at the tool level follows, enforcing least privilege per task rather than per session. Runtime enforcement has to sit at the actual point of invocation, checking policy before the tool executes, not logging what happened after the fact. And audit logging needs to produce evidence detailed enough for regulators, tying every action back to a specific identity, a specific intent, and the policy decision that allowed or blocked it.

ETDI, the Enhanced Tool Definition Interface proposal, adds cryptographic identity verification, immutable versioned tool definitions, and explicit permission management, often leveraging OAuth 2.0. It goes further than static scopes too, proposing that tool capabilities get evaluated dynamically against explicit policies through a dedicated policy engine, one that factors in runtime context rather than relying on a fixed OAuth scope. Cedar and Open Policy Agent are named as candidate engines for that job. ETDI signs and verifies the tool definition itself, so runtime monitoring of tool outputs, not only inputs, is a necessary complement to PBAC. Signing the definition doesn't monitor what the tool actually sends back.

The spec is moving in the right direction on its own timeline. The 2025-06-18 release introduced OAuth 2.1 with PKCE for client authentication. The 2025-11-25 revision added step-up authorization, letting a server respond with a 403 and demand elevated credentials before allowing a high-risk tool call to proceed. The 2026-07-28 spec continues in that same direction. Spec support doesn't equal server implementation, though, and the real OAuth adoption rate across public servers remains very low, according to Astrix.

That's why production use of MCP needs a governed gateway sitting in front of it all: identity binding, tool allowlisting, audit logging, and human-in-the-loop approval for anything high-risk. The gateway is the layer where policy actually gets evaluated before a tool call reaches an execution environment. Keycloak now supports acting as an authorization server for MCP servers, which means enterprises can extend an IAM investment they already have rather than building identity infrastructure from scratch. Single sign-on, SCIM, and just-in-time credential provisioning are the mechanisms that actually bind a tool call to a specific human or agent identity. Without them, audit logs end up attributing actions to sessions instead of the actors who triggered them. Monitoring tool outputs has to run alongside policy-based access control, because authorization checked at registration time doesn't catch an injection that happens at render time.

Point tools, fragmented stacks, and the failure to enforce policy at tool-call depth

A stack built from a separate agent builder, a separate gateway, and a separate security tool bolted on after the fact can't hold this line consistently. Each piece sees only its slice of the tool call, and identity context gets dropped every time a request hands off from one component to the next.

The maturity numbers reflect how early the industry still is here. Practical DevSecOps found only a small fraction of organizations have a formal AI-agent identity strategy, and only a small fraction of agents reach production with full security approval, even as adoption grows rapidly. That gap between adoption speed and governance readiness is exactly where fragmented tooling breaks down.

The failure is structural: it results from how the pieces divide responsibility, not from any one vendor doing a bad job. An agent builder provisions the agent and its initial permissions. A gateway sits downstream and enforces allowlists on which tools can be called. A security tool, bought separately, watches logs or flags anomalies after the fact. None of these three sees the full picture of a single tool call as it happens: the identity making the request, the intent behind it, the specific action about to execute, and the content coming back in the response. Each handoff between them is a place where that context can get lost, and a lost context is exactly the seam an attack like tool poisoning or rug pull is built to exploit. Enforcement at tool-call depth only works when one system holds the full picture at the moment the call executes, not when three systems each hold a fragment of it and hope the pieces line up.