Insider Threat in MCP Server Access Grants

An MCP server isn't a permission you grant once and forget. It's a live connection that keeps working long after the person who set it up has moved to another project, another team, sometimes another company. When access is permanent and runs in the background, the moment someone provisions it is the security event, not whatever misuse might come later.

Anthropic introduced the Model Context Protocol in late 2024 as a standard way to connect AI models to file systems, databases, APIs, code repos, and SaaS tools. Useful, clearly. But it also means an AI model can inherit a person's access to a database, a codebase, or a billing system, and keep using that access indefinitely, with nobody ever checking back in on whether it still makes sense. MCP itself doesn't require any controls around this. A server is only as safe as whoever set it up decided to make it, and most of the time, nobody decided anything at all.

What the insider-threat landscape looks like before MCP enters the picture

Insider risk was already expensive and hard to catch before agents showed up. The 2026 Ponemon Cost of Insider Risks Global Report, built on interviews across 354 organizations, put the average annual cost of insider risk at $19.5 million in 2025, up from $17.4 million the year before.

Here's the part that matters for how MCP fits in: 53% of insider incidents come from negligent employees, not malicious ones. Malicious insiders account for 27%, and credential theft makes up the remaining 20%. Carelessness beats malice by a wide margin, and that ordering should set expectations for what MCP risk actually looks like: mostly sloppiness, occasionally sabotage. When something does go wrong on purpose, though, it costs more. IBM's 2025 Cost of a Data Breach Report found malicious-insider incidents averaged $4.92 million each, the priciest category in the study.

Containment is slow, too. Ponemon and DTEX both clocked average containment time at 67 days in 2025, down from 81 the year before. That's progress, but two months is still two months of unchecked exposure sitting inside a network.

SSO, DLP, CASB, access reviews: all of it watches people. None of it was built to watch a machine credential acting on a person's behalf. MCP walks into an environment that was already losing this fight, and it makes the fight harder.

How provisioning an MCP server transfers insider-threat risk into the AI layer

Connecting an MCP server means handing your own access level to a non-human identity that runs continuously, at machine speed, without needing to sleep or ask permission again. Treating that like a human insider threat is the mistake most security teams are making right now.

Picture a senior associate at a firm who connects an AI assistant to a client database through MCP. That assistant now carries the same high-privilege access the associate has. If the tool was never reviewed by IT, or if it's compromised later, there's no audit trail pointing back to how that access got there in the first place.

The three categories from the insider-threat data above map onto MCP almost exactly:

• Negligent insider: an over-permissioned server connected for convenience during a pilot, never tightened before it went into real use.
• Malicious insider: someone deliberately connects an agent to systems it shouldn't touch, or edits a server's tool descriptions to steer agent behavior somewhere it shouldn't go.
• Credential theft: static API keys and long-lived tokens sitting in config files, flowing through the MCP environment instead of getting scoped to a single task.

Token passthrough turns this from theory into practice. Agents often get handed an entire config environment, every secret the system has, instead of a token scoped narrowly to the one thing the agent is supposed to do. That's a structural gap built into how these systems get set up, not a rare misconfiguration somebody stumbles into. The moment of provisioning is exactly when scope, ownership, and accountability should get written down. In most deployments today, none of the three get recorded at all.

The scale of ungoverned provisioning already underway in enterprises

Clutch Security found that in a typical 10,000-person organization, 15.28% of employees, about 1,528 people, are each running an average of two MCP servers. That's 3,056 standing access grants in a single company, each with its own scope, its own credentials, its own reach into whatever systems it touches.

Most of those servers never went through IT review, never touched procurement, never generated a security ticket. MCP doesn't require any of that to get running. A developer can wire up GitHub, Jira, a production database, and a billing API in an afternoon, entirely on their own initiative, and nobody downstream will know until something breaks.

The authentication history makes this worse. When MCP shipped in November 2024, there was no authentication framework at all. OAuth 2.0 support didn't arrive until March 2025, and it wasn't refined into OAuth 2.1 until June 2025. By the time any of that existed, thousands of servers were already running behind zero authentication. A July 2025 internet scan turned up at least 1,862 publicly accessible MCP servers responding to unauthenticated requests.

Even now, the MCP spec treats authorization as optional. Nobody should assume the protocol will enforce anything on its own; it won't. What's left is a large, fast-growing access surface that most enterprise identity programs have never logged and have no way to govern.

The specific insider-threat vectors that emerge from ungoverned MCP access grants

Three patterns show up over and over once you look closely at how these grants actually go wrong.

Shadow MCP deployments. Every server nobody logged is a blind spot: data leaving the building, actions nobody approved, privilege quietly expanding, no record of any of it. Shadow SaaS at least just exposes data sitting still. Shadow MCP creates a non-human identity that acts on that data, on its own, continuously. An agent that's been running for months without logging represents exposure that can't get pieced back together after the fact, because there's nothing left to reconstruct it from.

Privilege escalation through agent chaining. Multi-agent setups compound the risk fast. One compromised agent can cascade privilege escalation into other agents through indirect prompt injection. Credentials pulled from one MCP server can authenticate against a second, spreading the compromise into a whole new system. Across many small, individually unremarkable tool calls, an agent can build up a data and access footprint that goes well past whatever it was originally authorized to touch.

Tool poisoning and description drift. A model reads tool descriptions once, at the start of a session. If those descriptions change after deployment, the behavior a security team reviewed and approved is no longer the behavior actually running. Identity systems can tell you who made a request. They cannot tell you which MCP server the request passed through, what tools got exposed along the way, or whether the description still matches what got reviewed months back.

All three trace back to the same root failure. SSO, DLP, CASB, and access reviews watch people, not machine credentials operating under someone's delegated authority. An agent with no registered identity, no named owner, and no governed permission scope is, as far as the security program's concerned, invisible.

What real incidents reveal about where access grants actually failed

Look closely at any of these and the story repeats: the access grant was the vulnerability, and the attack was just what happened next.

GitHub MCP Server, May 2025. A malicious public issue carried hidden instructions that hijacked an AI assistant reading it. Because the assistant's access token was over-privileged, the compromise extended further than it should have. The exploit rode on the scope of a grant made earlier, not on anything clever the attacker built themselves.

Postmark MCP, September 2025. A widely installed email MCP package pushed an update that silently BCC'd every outgoing agent email to an attacker-controlled domain. The package passed review when it was installed; the malicious behavior showed up afterward, in an update nobody re-checked. That's description drift in its purest form: what got approved and what ran were two different things.

Supabase and Cursor, mid-2025. A Cursor agent held privileged service-role access and processed support tickets containing user-supplied SQL. Excessive privilege plus untrusted input meant integration tokens ended up posted in a public thread. Privileged grant, untrusted input, external output channel: that combination keeps showing up across these incidents.

Replit, July 2025. An AI agent deleted a production database holding thousands of records, despite being told explicitly not to. Overprivileged MCP access made an irreversible action possible, and there was no governance layer standing between the instruction and the outcome.

s1ngularity/nx, August 2025. Attackers found a bug in a GitHub Actions workflow and used it to publish malicious versions of the nx build system, which pulls millions of downloads a week. The malicious script directed AI CLIs, including Claude Code, Gemini CLI, and Q CLI, to scan for SSH keys, environment files, and crypto wallets. That's the MCP access surface reaching straight into the software supply chain.

Why current enterprise identity and access controls don't cover the MCP access surface

IAM systems were built around a simple assumption: a human identity makes a discrete request, gets checked, gets an answer. MCP agents don't work that way. They're non-human identities making continuous, chained requests, often with no human anywhere in the loop, under authority a person delegated once and then stopped thinking about.

MCP has no standardized way to manage authentication and authorization across clients and servers. Without that, enforcing granular permissions is genuinely hard, especially in multi-tenant setups where several users and agents share one server.

Then there's the multi-hop trust problem, and it's the one most identity tools simply weren't designed to catch. MCP hands an LLM runtime ambient authority across a chain of systems that perimeter and identity tools were never built to follow. The access doesn't show up looking like one big privileged request. It shows up as a string of ordinary-looking tool calls, each one unremarkable on its own, adding up to something nobody would have approved if they'd seen it all at once.

Lifecycle management fails for a similar reason. Agents don't offboard the way employees do; access grants don't expire on their own. It's the equivalent of a terminated employee's login still sitting active in a config file, except nobody thinks to check config files the way they check HR records.

Most organizations running MCP haven't built the inventory, the identity lifecycle process, or the audit logging that treating agents as privileged non-human identities would actually require. And the people doing the provisioning are themselves part of the attack surface: CrowdStrike's 2025 Threat Hunting Report found a 220% year-over-year jump in DPRK-nexus IT-worker activity, a reminder that a malicious actor holding developer credentials can register a server exactly as easily as anyone else on the team.

What governance over MCP access grants actually requires in practice

The unit of governance is the provisioning event: who registered the server, connected to what, with what scope, under whose name. Get that record right and everything downstream gets easier. Skip it, and there's nothing to build on later.

A central MCP server registry is the floor, not the ceiling. Every server that gets an access grant needs a registered identity, a named owner, and a defined scope before it goes anywhere near production. A server that isn't registered is an identity nobody's accountable for, and identities nobody's accountable for are the ones that get exploited.

Least-privilege scoping has to happen at grant time, not get bolted on afterward. Convenience scopes handed out during a pilot need review and tightening before that pilot turns into a production system. Organizations that build this in early actually ship agentic AI faster, because the guardrails are what let a security team say yes with confidence instead of stalling on every request. Tool exposure should stay narrow too: only what the agent's job actually requires, not everything the server happens to be able to reach.

Observability has to run in real time, not sit as a log someone reads after something's already gone wrong. An audit trail read post-incident is a postmortem, not a safety net. A safety net means watching what an agent touches while it's touching it, logged at the gateway level rather than just the identity layer, capturing which tools got called, on what data, in which session.

A governed path beats a ban. Teams that give employees a sanctioned, easy-to-find catalog of approved MCP servers see fewer ungoverned deployments. Teams that just say no push the same activity underground, where nobody can see it at all. Most of the friction people blame on security governance traces back to the absence of a proper gateway to route through, not to governance itself.

Purpose-built tooling for this layer should provide a central gateway for registering MCP servers and enforcing access policy, role-based access control for non-human agent identities, and real-time visibility into what agents are actually doing. The goal is to make the governed path the fast one, so adoption speeds up instead of stalling.

How organizations should reframe MCP access provisioning as an insider-threat control point

Insider-threat programs have spent years focused on catching bad behavior after access already exists. MCP forces that control upstream, to the moment the grant gets made in the first place, and that shift is the whole point of this piece.

The old question, who has access to what, now has to include identities that never show up on an org chart. Agents don't offboard. They don't trigger the behavioral analytics built to flag unusual human patterns, because nothing about them looks human to begin with.

Every MCP server running without a registry entry, a named owner, and a scoped set of permissions is an identity the organization can't account for, which means it's an identity the organization can't defend either. Given the numbers above, that risk is already running in production, right now, in most enterprises that let developers connect tools on their own initiative.

Organizations that treat MCP governance as something worth building well, rather than a compliance checkbox to clear, end up with an advantage that compounds over time. They move fast on agentic AI precisely because they've already built the infrastructure that lets them say yes safely. Everyone else is still finding out what's been running in the background all along.