Governing MCP Tool Permissions at the Server Level

MCP solves a math problem that has annoyed enterprise engineering teams for years. Connect M AI applications to N different systems the old way, and you get M×N custom integrations, each one hand-built, each one a maintenance burden. MCP flattens that to M+N: one protocol, and every app and every system just has to speak it once. That's the entire pitch, and it's a good one. It's also why adoption accelerated rapidly after launch, and why the ecosystem now counts thousands of servers and 300-plus clients, with production deployments at Block, Bloomberg, Amazon, and across the Fortune 500. By early 2025, a significant and growing share of Fortune 500 companies had MCP servers running in production.

Here's the part nobody put on the slide deck: the same standard that collapses M×N integrations into M+N connections also collapses the attack surface into something just as unified. Every system that exposes an MCP interface is now reachable by every MCP-capable agent that can talk to it. One protocol, multiplied productivity, multiplied exposure, at the same time, on the same wire. Across the industry, enterprises have been deploying AI agents far faster than they have been putting governance structures in place to oversee them. That gap, between what's deployed and what's controlled, is the whole story. Whether to adopt MCP was never the question. It's whether governance can move at the speed adoption already has.

What the MCP spec does and doesn't give you on security

Give the spec its due. The March 2025 update made OAuth 2.1 the baseline authorization framework for remote MCP servers, and the November 2025 revision tightened it further: stricter proof-of-possession checks, closed gaps in token handling, and official support for asynchronous operations, statelessness, and server identity. That's real progress, and it wasn't free.

But read the spec for what it's actually trying to do, and the boundary shows up fast. MCP standardizes how a model discovers a tool and calls it. It does not tell you how to authenticate that model, how to authorize what it's allowed to touch, or how to secure the transport in between. Those choices sit with whoever builds and runs each host, client, and server. There's no centralized login system baked in, no audit trail, no policy engine. That's not a bug in the design; it's a boundary the designers drew on purpose, and it's a reasonable one for a protocol meant to work everywhere. The trouble is what happens when thousands of teams build to that boundary without filling in what's missing on the other side of it.

A community audit of nearly 2,000 scanned MCP servers, run by Obot AI in June 2026, found close to zero authentication across the sample. Not weak authentication. Close to none. That's not a protocol failure; the spec never promised authentication out of the box. It's a deployment failure, repeated thousands of times, because the spec sets a floor and nobody built the rest of the building on top of it. Locking the door was always going to be the responsibility of whoever installs the door, and right now most of them are leaving it open.

The attack patterns that ungoverned MCP tool access enables

Start with the tool description field, because it's the easiest door to walk through. It's plain text, unsanitized, and agents read it as trustworthy help text rather than as untrusted input. A malicious or compromised server can bury instructions inside that field, and the agent will follow them without the user ever seeing it happen. Security research from April 2025 confirmed multiple live prompt injection and poisoned-tool paths that let attackers pull data out through connected tools, using nothing more exotic than a tool's own self-description.

Then there's the rug pull. MCP tools can change their own definitions after a user has already approved them, which means a tool that looked harmless on installation day can quietly start rerouting API keys a week later. Check Point Research disclosed exactly this in August 2025, cataloged as CVE-2025-54136 and nicknamed MCPoison. It targeted Cursor teams working off shared repository configs, and it worked because the trust model bound approval to a server's name rather than to its contents. Change the config file after approval, and the system just... trusted it. No new prompt, no second look. Naming something once and trusting it forever is a strategy that works great for pets and terribly for software.

The Supabase and Cursor incident from mid-2025 shows what happens when this kind of gap meets real privilege. Supabase's Cursor agent ran with privileged service-role access and treated support-ticket text as executable input. Attackers embedded SQL inside a ticket, the agent ran it, and integration tokens ended up exfiltrated into a public thread. Three ingredients did the damage: privileged access, untrusted input, and an open channel out. Remove any one of the three and the exploit doesn't work.

September 2025 gave the ecosystem a supply-chain lesson wearing a Postmark costume. A poisoned npm package impersonated the legitimate Postmark MCP server and behaved identically, feature for feature, for fifteen releases. Then it added one line: quietly copy every outgoing email to an attacker-controlled address. Password resets, invoices, internal correspondence, all mirrored out, undetected for over a week. Fifteen clean releases is a long con for a piece of software, and that's precisely why it worked; nobody audits release sixteen with the same suspicion they'd apply to release one.

Layer IDE auto-execution on top of all this and the blast radius grows again. Disclosures between mid-2025 and June 2026, tracked by the Cloud Security Alliance's AI Safety Initiative, found that Cursor, Claude Code, Gemini CLI, GitHub Copilot, and Amazon Q all auto-execute project-defined MCP servers with developer-level OS privileges and no process isolation. And when an agent has multiple servers connected at once, a malicious one can shadow a trusted one, intercepting or overriding calls meant for somewhere else entirely.

Different mechanisms, same root cause. Every one of these exploits works because nothing at the server checks scope, applies policy, or inspects behavior at runtime. Fix that single gap and every pattern above stops working, more or less simultaneously.

How secrets and credentials leak through MCP configuration

Set MCP aside for a second, because the backdrop is already bad on its own. GitGuardian's State of Secrets Sprawl 2026 report found 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% jump year over year and the largest single-year increase on record.

Now put MCP back in the frame. GitGuardian identified 24,008 unique secrets sitting in MCP-related configuration files on public GitHub, of which 2,117 were unique and still valid. Google API keys made up close to 20% of what leaked; PostgreSQL connection strings accounted for another 14%; search and retrieval service credentials filled out most of the rest. This isn't a mystery. Popular MCP setup guides routinely tell people to drop API keys straight into config files, command-line arguments, or connection strings, and quickstarts that model insecure handling get insecure handling copied at scale.

AI-assisted coding makes the leak rate worse, not better. Commits assisted by AI tools showed a 3.2% secret-leak rate against a 1.5% baseline across all public GitHub commits, roughly double. Commits assisted specifically by Claude Code peaked at 31 leaked secrets per 1,000 commits in August 2025, about 2.4 times the human baseline for that stretch.

And once a secret leaks, it doesn't politely expire. Snyk found that 64% of secrets leaked back in 2022 were still active in 2026. Industry research has consistently found that enterprise remediation of leaked secrets takes weeks to months. Security researchers have documented threat actors harvesting exposed credentials from public repositories within minutes of exposure, not days. Do the math on those two numbers together: attackers move in minutes, enterprises respond in months. AI service credentials are the fastest-growing category in the leak data, up to 1,275,105 exposed secrets in 2025, an 81% jump year over year. Hygiene campaigns and rotation reminders were never going to close a gap that wide. Closing it has to be structural, enforced at the server, not left to whoever remembers to check.

Why shadow AI makes server-level MCP governance harder and more necessary

Ask any IT leader how many AI tools run inside their company and watch the confidence drain from their face. It's not that they're lying; they genuinely don't know. Studies put weekly AI use among employees at 86%, with 58% admitting they use tools their IT department never approved. More than 70% of enterprise AI usage runs with no real oversight attached to it. The average enterprise has 14 distinct AI tools active at any given time, and IT is aware of maybe 4 or 5 of them. One analysis found the average organization has 1,550 distinct GenAI SaaS applications running somewhere inside it. That's not shadow IT anymore. That's a whole second company operating in the dark, using the same badge to get into the building.

MCP servers make this worse because they're so easy to stand up. A developer can spin up a local server connecting to internal APIs or sensitive data stores in minutes, and unless there's a governed distribution layer in place, IT has no way of knowing it exists. IBM's 2025 Cost of a Data Breach Report found shadow AI breaches cost an average of $670,000 more than standard incidents, which is an expensive way to find out someone on the backend team was experimenting.

Banning the tools doesn't work either; 46% of employees say they'd keep using AI tools even after their company explicitly banned them, which tells you prohibition is a policy for people who've never met their own workforce. Okta's "AI at Work 2025" research found 80% of organizations reporting unintended agent behavior and 23% reporting actual credential exposure. Lockdown was never going to be the fix. Governed access has to be, because shadow MCP servers walk straight past any control sitting at the client or the network perimeter. The only place left to enforce policy, for sanctioned and unsanctioned servers alike, is the server itself.

What server-level permission governance actually means in practice

The principle is simple even if the plumbing isn't: permission controls that live inside the server apply no matter which agent, IDE, or orchestrator is calling it. Controls that live on the client only work when the client is well-behaved, which, per the last section, you cannot assume.

Three things need to happen at that layer. First, scoped tool access: a server exposes only the tools a given identity or role is cleared to use, not a flat menu of everything it's capable of. Second, role-based controls: what a caller can touch depends on who they are, checked before any tool runs, not after. Third, runtime policy enforcement: allowlists, blocklists, rate limits, PII checks, and injection detection, all applied before a request goes any further downstream.

Picture a finance MCP server that hands analysts a read-only balance tool while reserving the write tool for a service account carrying a specific role claim in its token. Or a CRM server that strips personal data out of responses sent to a general-purpose assistant, but returns full records to a verified sales-ops agent that's earned the trust. Or a developer tools server that checks incoming prompt context for secret patterns and simply refuses to execute if it finds one. None of this is exotic engineering; it's the same access-control logic enterprises have applied to human users for years, just moved down a layer to cover machine callers too.

The gap between client-side and server-side enforcement is the whole ballgame here. A client-side allowlist only governs what a well-behaved client chooses to ask for; a compromised or unmanaged client simply ignores it, because nothing's forcing compliance. Server-side enforcement holds even when the client turns hostile, because the check happens on the side that actually executes the tool. Trace that back to the rug-pull problem from earlier: immutable policy at the server means a mutated tool definition still can't execute with elevated permissions, even if the client has already decided to trust the new version. The server, not the client's opinion of the server, becomes the actual line of defense.

Tying server-level controls to enterprise identity infrastructure

Enterprises spent roughly a decade weaning humans off shared passwords, building single sign-on, multi-factor authentication, and role hierarchies to make sure the right person had the right access and nothing more. Then AI agents showed up and a lot of that discipline evaporated. Agents routinely run as superusers with static, hardcoded tokens sitting in environment variables. The system can tell a token was used, but it has no idea why, or which human action triggered the agent that used it. No delegation context, no audit lineage, just a timestamp and a shrug.

It gets murkier as calls hop through an orchestration chain, from an orchestrator into a sub-agent into an MCP server. By the time the request lands, identity has flattened into a generic machine principal. The database log shows a service account, but it doesn't show the human operator who kicked things off or the specific sub-agent that actually ran the query. That's not a logging inconvenience; it's the difference between knowing what happened and reconstructing it from guesswork after the fact.

Fixing this means the caller's identity has to arrive cryptographically asserted and properly scoped, a token that carries delegation lineage rather than just a bare credential. Okta for AI Agents, generally available April 30, 2026, treats MCP servers as governed resources and secures agent access to them through the same identity infrastructure already managing human logins. It works with identity providers beyond Okta too, including Microsoft Entra ID and Ping, so enterprises don't have to rip out existing human identity systems to bring agents under the same roof. It also brings automated access reviews, structured approval workflows, and, notably, a kill switch for an agent that's gone rogue.

Role-based access control at the server only works if the token actually carries the role, and the server can read that claim and adjust tool scope accordingly. Existing enterprise SSO, via SAML or OIDC, can federate into an agent's credential chain so server-side RBAC mirrors the same organizational hierarchy already governing human access. No rip-and-replace of the identity stack required.

Runtime enforcement: what the server must inspect and block in real time

Identity and roles establish who's allowed to ask. Runtime enforcement is what actually stops the bad request the moment it shows up, and it needs to happen at three points.

Prompt injection detection comes first, because the tool description field is unsanitized by design and any server can weaponize it. The server has to inspect both inbound prompt context and tool metadata for injection patterns before anything executes, and it has to do this regardless of which client sent the request, sanctioned or not. That last part matters: server-side detection is the only version of this check that still works against a client the enterprise never approved in the first place.

PII detection runs on the way out. Before a response reaches the calling agent, the server checks it for sensitive data and scrubs what shouldn't leave. This can flex by tool and by caller: an HR server might strip identifying details from anything routed to a general assistant, while handing full records to a governed HR workflow agent that's earned that level of trust.

Then there's secret and credential scanning, on both sides of the request. Inbound, the server checks for embedded API keys, connection strings, and credentials before forwarding anything downstream, which directly counters the pattern where AI-assisted commits leak secrets at roughly double the ordinary rate. Outbound, the same scanning catches cases where a tool's response accidentally hands back a credential nobody meant to expose.

None of these three checks is complicated on its own. Together, applied consistently at the point where the tool actually runs, they're what turns MCP from a protocol enterprises are exposed to into one they've actually got a handle on.