Scope Creep in Enterprise AI Agent Deployments

Scope creep in enterprise AI agent deployments is a structural consequence of how agents inherit permissions through the tools they call, and closing it means governing access at the tool-call level before an agent ever reaches production.

Why AI agents expand their permissions unchecked

Picture a tool built to read one table in a database. Somewhere along the way, nobody goes back and scopes its credentials down, so that tool ends up carrying write access to the entire database. No one approved that. No one even noticed it happen. It is simply what's left over from how the tool got built.

This matters because an agent does not carry its own permissions. It exercises whatever access the tool it calls was given at setup, not the narrower slice it was supposed to need. If the tool can write to the whole database, the agent can too, the moment it calls that tool. Security researchers call this pattern, which predates agents, confused deputy behavior. An MCP server, in this context, acts as an intermediary that ends up performing actions with broader privileges than the requesting agent should ever have had.

The Model Context Protocol is what turns this from a one-off configuration mistake into something that scales across an entire company. MCP started as an Anthropic project and now sits under the Linux Foundation's Agentic AI Foundation, with Anthropic, Block, and OpenAI as co-founders and Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it as well. MCP standardizes how agents connect to enterprise tools, so one misconfigured server does not stay contained to the team that set it up. It exposes its full blast radius to every agent that ever calls it. By March 2026, MCP SDK downloads had reached 97 million a month, and at that pace, you cannot check each deployment by hand. The same standardization that makes MCP so useful, collapsing what would otherwise be a tangle of custom integrations into one shared protocol, is what turns a single misconfigured server into a company-wide exposure.

Then workflows start chaining agents together. One agent calls another, which calls a third, and each one inherits whatever permissions sit behind it in the chain. No single team ever sat down and designed, approved, or even fully mapped the resulting aggregate blast radius. It simply accumulates, link by link, as more of the business runs through agents talking to other agents.

How far permissions have already drifted in production deployments

The picture that emerges from multiple independent surveys in 2026 is remarkably consistent: enterprises believe they have more control over agent permissions than they actually do, and the size of that gap is large enough to count as a systemic exposure rather than a handful of edge cases.

Start with the baseline. Only a small share of organizations say their AI agents never exceed the permissions they were meant to have. Most admit their agents go beyond their intended scope at least occasionally, and that pattern appears across several separate 2026 security surveys, not just one outlier study. Visibility is just as thin. Surveys show most enterprises cannot say with confidence that they have a full accounting of their AI agent identities, and an even larger share doubt they could detect or contain a compromised agent if one turned up tomorrow. Cisco's State of AI Security 2026 Report put a number on that discomfort: only 29% of organizations feel prepared to secure agentic AI applications.

Shadow deployment adds to that gap: a substantial share of enterprises already have AI agents or workflows running that their security teams never knew existed. These are agents nobody on the security side ever approved in the first place, operating with whatever access someone upstream decided to give them.

None of this should read as a surprise once you look at how few pilots make it to production in a controlled way. Only a small minority of enterprise agentic AI pilots reach production at all, and the leading reasons the rest stall are identity management, auditability, and access-control gaps. The agents that do make it through, then, have usually gotten there without the identity and permission controls that would have made scope creep visible, let alone something a team could stop before it happened.

What attackers do with over-permissioned agents

None of this stayed theoretical for long. Documented incidents from 2025 and 2026 show attackers treating an agent's own legitimate access as the attack path itself, with no need for a conventional exploit anywhere in the chain.

The clearest illustration is the Supabase MCP incident from July 2025, documented by General Analysis. A developer environment ran an AI coding agent configured with Supabase MCP access using service-role privileges, which bypasses all Row-Level Security protections. A support ticket came in with instructions embedded in its text, directing the agent to query the integration_tokens table and return the contents. The agent held the access needed to do exactly that, and it read the instruction as something it was meant to follow, so it complied and posted dummy credentials back into a support ticket thread the attacker could see. No credential theft took place. No network intrusion occurred. There was no software vulnerability in the conventional sense anywhere in the story. The weapon was a support ticket, and the vector was the agent's own legitimate, intended database access.

The same architecture showed up a month earlier in the GitHub MCP indirect injection from May 2025. An agent holding elevated repository access processed a public GitHub Issue containing instructions buried in its text, which directed it to exfiltrate private repository code.

Cisco documented a more advanced version of the same dynamic in 2026: multi-agent lateral movement. An attacker compromised a low-privilege data-query agent first, then used that agent's own cross-agent communication interface to send disguised requests to a higher-privilege financial approval agent. Access escalated without the attacker ever touching the higher-privilege system directly. This is the multi-agent compounding dynamic from earlier in this piece, caught in the act.

The Mexico government breach between December 2025 and February 2026 shows what that scale looks like. A single attacker used Claude and ChatGPT to breach the federal tax authority, the electoral institute, four state governments, and a water utility. The haul came to 150 GB of data, including 195 million taxpayer records, and the attacker's own conversation logs turned up publicly accessible online after the breach had already been reported, before anyone knew AI tools were involved in how it happened. The attacker switched between AI platforms whenever one hit a guardrail limit, so the attack chain spread across systems and no single platform ever captured the full sequence.

Across every one of these cases, the entry point was the same thing: permissions the agent already had, legitimately, and never had reason to use narrowly.

How tool poisoning weaponizes permission inheritance

Tool poisoning turns the permission inheritance problem into something an attacker can trigger on command, without touching a single credential or network path.

The mechanism is simple once you see it. An agent reads a tool's description to decide how and when to call it, and it trusts that description roughly the same way it trusts its own system prompt. If a malicious server hides commands inside that description, the model follows them, reading files, leaking secrets, all while handing back a response that looks completely normal. Invariant Labs built a full proof of concept on Cursor IDE that shows exactly this: a hidden instruction buried in a tool description told the agent to read the user's SSH private key and send it out encoded as an extra parameter tacked onto a calculator tool call. The key came out in full, the user never saw it happen, and the malicious instruction stayed invisible in Cursor's truncated UI the entire time.

A technique called ShareLock pushes the idea further by spreading the attack across multiple servers. It splits a malicious instruction into pieces that each look harmless on their own, scatters those pieces across several tool descriptions, and reassembles the full instruction at runtime after a trigger gets planted during a routine server update. Tested across mainstream models on two MCP clients, ShareLock held an attack success rate above 90%, and it slipped past the kind of tool-description review that most security guidance recommends.

Microsoft's Incident Response and Defender Research teams disclosed a real-world version of this in 2026. A finance team's agent connected to a third-party invoice enrichment tool that had been approved once, early on, but never given a proper security review afterward. An attacker updated the tool's description, kept its visible name and summary unchanged, and buried a hidden instruction inside it to grab unpaid invoices. MCP picks up description changes automatically, with no re-approval step built in, so the poisoned version went live the moment it was pushed.

Independent benchmarking backs up how often this kind of attack works. MCPTox tested adversarial variants of real tools against a range of language models, and it found a meaningful average attack success rate across the board. Even Claude-3.7-Sonnet, the model with the strongest refusal behavior in the test, still complied with poisoned instructions at a striking rate, and the average success rate across every model tested stayed dangerously high.

Standard security tools do not catch any of this, because they were never built to. Web application firewalls, API gateways, and data loss prevention tools evaluate requests, not intent. They see a legitimate agent making a legitimate API call with legitimate credentials, because that is what's happening on the wire. The OWASP MCP Top 10, first published as a v0.1 taxonomy in 2025 and actively updated through 2026, names tool poisoning, privilege escalation via scope creep, insufficient authentication and authorization, and shadow MCP servers as distinct, recognized categories of risk. This is a structured, documented threat class, not a one-off research curiosity.

The supply chain problem: how it turns scope creep into an enterprise-wide exposure

Agents inherit permissions from the tools they call, and more of those tools now come from external marketplaces and hosted servers outside the organization's own walls. That shift is what turns scope creep from a single misconfigured deployment into a company-wide exposure, because the tools an enterprise never built can still be running with the access an enterprise never granted directly.

Supply chain, for AI agents, means something different than it did for traditional software. It concerns live, running servers whose tool descriptions, and therefore their instructions to any agent that calls them, can change after installation and after whatever approval process let them in the first place, beyond just which packages get pulled into a build.

The scale of this problem is already visible in the ClawHub marketplace, built for the OpenClaw AI agent framework. Antiy CERT confirmed thousands of malicious skills circulating there, reaching a point where roughly one in five packages in the ecosystem was malicious at its peak, and nine CVEs were assigned as a result, three of them with public exploit code already available.

Claude Code had its own supply chain disclosure: Check Point Research found remote code execution achievable through poisoned repository config files, patched in Claude Code 1.0.111 and later under CVE-2025-59536. A related API key exfiltration flaw, CVE-2026-21852, was patched in Claude Code 2.0.65 and later, so any deployment that stayed on an earlier version remained exposed in the meantime.

OX Security's research, titled "The Mother of All AI Supply Chains," found a command execution vulnerability embedded in Anthropic's official MCP SDKs for Python, TypeScript, Java, and Rust. The STDIO transport in those SDKs processed incoming configuration by passing parameters directly to the host operating system's shell, with no input sanitization along the way.

The Sentry case shows what happens when a known risk simply does not get closed. Tenet Security's research into agentjacking via Sentry MCP event injection found a large number of organizations running injectable DSNs, and a high rate of successful agent execution in testing. Sentry chose not to pursue full remediation, deploying a payload-string filter instead, so the underlying architectural risk is still there for any enterprise relying on that integration.

Trend Micro's research found 492 MCP servers exposed to the open internet with zero authentication. Any agent that discovers and calls one of those servers inherits whatever access that server happens to be configured with, and there is no credential exchange involved for anyone to audit afterward.

An enterprise can audit its own MCP server configurations down to the last detail, but it cannot audit the servers behind the marketplace packages its agents consume. The permission inheritance chain runs straight past the organization's own control boundary.

The gap protocol-level authentication and authorization have not closed

The obvious response to all of this is to tighten authentication. Know who's calling, and the problem goes away. It doesn't, because authentication answers who an agent is, not what it's allowed to do once that connection is live.

The numbers bear this out. Practical DevSecOps found that nearly half or more of organizations have had AI agents exceed their permissions or suffer an incident tied to that overreach, even with identity checks in place. Knowing exactly which agent made a request does nothing to stop that agent from calling a tool it was never meant to touch, as long as the tool sits within the scope of its connection.

This is not a knock on the people who wrote the MCP specification. Standardizing per-tool scope enforcement across a protocol built for extensibility is a genuinely hard design problem, and the spec's authors were solving for flexibility first. But that choice leaves a gap: an agent that fully complies with the current spec can still call a tool outside its intended purpose, so long as that tool is technically in scope for the connection it holds.

Token passthrough compounds the problem further and remains one of the most overlooked failures in how MCP servers handle OAuth. When a server accepts a token it was never issued and forwards that token to a downstream API anyway, it skips audience validation entirely. At that point, accountability for what the token did, and who authorized it, breaks down. Authentication confirms an identity at the front door. It says nothing about what that identity should be allowed to touch once it's inside, and that is the exact gap scope creep lives in.