MCP Servers: The Insider You Cannot Attribute (2026)
By the Insider Risk Index Research Team, sponsored by Above Security.
About Above Security: Above Security (above.security) builds AI-native insider risk technology that detects intent and prevents data loss in real time. Benchmark your own program with the free Insider Risk Index assessment.
Every insider investigation rests on one question: who did this? Not what happened, not when, but which named human or system took the action, and what else they touched. Strip that away and you do not have a weaker investigation. You have no investigation at all.
The Model Context Protocol quietly removes it. MCP is the connective tissue of the agentic enterprise, the standard that lets AI assistants reach your CRM, your repositories, your cloud consoles and your databases. It works beautifully. It also introduces a participant that holds real credentials, acts inside your trust boundary, and leaves behind a log entry naming itself rather than the person who asked. That is a new kind of insider, and most organizations have no inventory of how many they are running.
What is an MCP server, and why is it an insider risk?
An MCP server is a credentialed bridge between an AI model and a real system, and it is an insider because it holds standing access inside your trust boundary and acts on it autonomously. When an assistant needs to read a Salesforce record or query a production database, an MCP server brokers that call. To do so it must hold something durable: an OAuth token, a database credential, a cloud role, an API key.
That is the same profile the Forscie Insider Threat Matrix uses to define an insider, an authorized entity operating inside the trust boundary whose legitimate access can be turned to harmful ends. The MCP server is not a tool sitting outside the perimeter. It is on the inside, holding keys, acting continuously, and in most environments nobody owns it.
Why does MCP break insider attribution?
Because an MCP server typically executes with its own credentials rather than the credentials of the person who made the request, so the audit trail records the server, not the human. This is the single most consequential property of MCP for insider risk, and it is a design characteristic rather than a bug.
Consider what that means in practice. An analyst asks an assistant a question. The assistant calls an MCP server. The server queries the database using the service credential it was provisioned with. The database log records that service account. Six weeks later you are investigating an unexplained export of customer records and the trail terminates at a credential that a dozen people could have driven, through an assistant, with no record of which one did.
Insider investigation is the discipline of reconstructing intent from behavior. You cannot reconstruct intent from an actor that has no identity. The Synthetic Insider Threat Matrix, which Above Security launched with Forscie in August 2026, names this failure mode directly in its Opacity category: the conditions that frustrate observation, explanation, attribution, or containment. MCP attribution collapse is Opacity in its purest form.
What are shadow MCP servers?
Shadow MCP servers are unapproved MCP deployments running outside security governance, and they are the 2026 successor to shadow IT and shadow AI. They are significant enough that the OWASP MCP Top 10 lists them as their own category, MCP09 Shadow MCP Servers, defined as "unapproved or unsupervised MCP deployments that operate outside formal security governance."
The pattern is familiar to anyone who lived through shadow SaaS. A developer spins one up to make a workflow faster. It works. It stays. According to OWASP's guidance these are "often left running with default logins and loose settings," creating a blind spot where teams have no central inventory. The recommended controls are continuous discovery and allowlist enforcement, which is to say: you cannot govern what you have never counted.
This is the same organizational failure we documented in shadow AI insider threats, with one escalation. A shadow AI tool leaks the data a person pastes into it. A shadow MCP server holds a credential and can reach the system directly.
How do MCP permissions drift into over-privilege?
Through scope creep: permissions granted provisionally during setup are rarely scoped down afterwards, so servers accumulate capability they never lose. OWASP tracks this as MCP02 Privilege Escalation via Scope Creep, noting that "temporary or loosely defined permissions inside MCP servers tend to expand over time" and that write-level scopes often never get revoked after initial configuration.
The mechanics are mundane, which is exactly why it happens. Read access is not enough for the prototype, so someone grants write. The prototype ships. The write scope stays. Multiply that across every integration in a growing agentic stack and you arrive at a population of non-human identities with broad, unreviewed, standing authority over production systems, each one a larger blast radius than any individual employee.
Combine that with MCP01 Token Mismanagement and Secret Exposure, where hardcoded keys and long-lived tokens are the main exposure, and the result is an insider with excessive permissions and durable credentials that nobody rotates.
Why can't you investigate an MCP incident?
Because MCP telemetry is typically thin or absent, which OWASP classifies as its own top-ten failure. MCP08 Lack of Audit and Telemetry states the problem bluntly: "Limited telemetry from MCP servers and agents makes investigation and incident response nearly impossible," and without logs, "token theft, injection, and exfiltration stay hidden."
Read that alongside the attribution problem and the picture is grim. You have an actor with standing credentials, frequently over-permissioned, often undiscovered, whose actions are recorded under its own name when they are recorded at all. Every property that makes an insider investigation possible has been removed.
This is not a hypothetical maturity gap. Between January and February 2026, security researchers filed more than 30 CVEs against MCP servers, clients and infrastructure, per Cycode's analysis. Pillar Security disclosed remote MCP servers that allowed unauthenticated callers to execute tools using the server's own credentials, which is the attribution problem and the authentication problem arriving together.
How does MCP insider risk map to the Insider Threat Matrix?
It maps cleanly, because an MCP server is a synthetic insider and the frameworks already exist to reason about it. In the Insider Threat Matrix the means is legitimate standing access, the mechanism is tool invocation through a credentialed broker, and the outcome is data exposure or destructive action. In the Synthetic Insider Threat Matrix the mapping is tighter still:
- Configuration is the MCP server's identity, token scope and tool access, which is where scope creep lives.
- Invocation is what triggers a call, whether a human prompt, a schedule, or another agent.
- Adverse Outcome is the exfiltration, fraud or destructive action the tool access makes reachable.
- Opacity is the attribution and logging collapse described above, and it is the category MCP fails hardest.
The useful consequence is that you do not need a new vocabulary. A team that can investigate a departing engineer can investigate an over-permissioned MCP server, provided the telemetry exists.
What should security teams do about MCP right now?
Inventory first, scope second, instrument third. In that order, because you cannot fix what you have not found. Mapped to the five Insider Risk Index pillars:
- Identity and access. Give every MCP server a unique, attributable identity with a named human owner. Where the protocol and your tooling allow it, propagate the calling user's identity rather than letting the server act purely as itself. Replace long-lived tokens with short-lived scoped ones, and run access reviews that actually revoke the write scopes from last quarter's prototype.
- Visibility. Run continuous discovery for unapproved servers and enforce an allowlist. Treat an undiscovered MCP server the way you would treat an unknown admin account.
- Investigation and evidence. Demand immutable audit trails that capture which server acted, which tool it invoked, and which human or agent initiated the chain. If your logs cannot answer the third question, you cannot run an insider investigation.
- Prevention and coaching. Require human confirmation for high-blast-radius tools. Default to read-only and make write access a deliberate, time-boxed exception.
- Behavioral detection of intent. The attribution gap is why signature and permission checks are not enough. Judging whether a sequence of tool calls is routine work or the beginning of an incident requires reading behavior and intent, which is the problem Above Security is built to solve.
Is MCP insider risk real in 2026, or theoretical?
The vulnerabilities are documented and the exposure is measurable, though the public record of insider-driven MCP incidents is still thin, and we say so rather than overstate it. What is firmly established: OWASP has published a dedicated MCP Top 10 including shadow servers and audit gaps as named categories, 30-plus CVEs landed in a two-month window in early 2026, and researchers have disclosed production servers executing tools for unauthenticated callers under their own credentials.
What is not yet established is a well-documented public breach attributing major data loss to an over-permissioned MCP server. That absence is unsurprising, and it is not reassuring: the whole argument of this piece is that MCP removes the attribution needed to identify such an incident as insider-driven in the first place. An invisible failure mode produces a quiet incident record.
The prudent move is the same one that worked for shadow SaaS a decade ago. Count what you are running, scope it down, and instrument it before the inventory grows another order of magnitude.
For related reading see agentic AI as an insider threat, insider data poisoning, and AI coding assistants and source code, benchmark your program with the free Insider Risk Index assessment, or browse the full research library.
