The Real Security Problem With MCP Isn’t the Protocol — It’s What Agents Can Access
Model Context Protocol security is often discussed as if MCP itself were the new vulnerability enterprises need to contain. That framing is too narrow.
MCP does create a new integration layer between AI applications and external tools, data, APIs, and services. And like any integration layer, it has security requirements of its own. But in a production AI agent, the more consequential question is usually not whether the protocol can establish a secure connection. It is what the agent is allowed to do after that connection succeeds.
An agent that can only search a public knowledge base presents a very different risk from one that can read internal documents, send email, modify source code, query production databases, or trigger cloud operations. The protocol may be identical in both cases. The blast radius is not.
That distinction is becoming more important as MCP moves from developer experimentation into enterprise agent architectures.
MCP Security Has Improved — but That Does Not Solve Agent Security
MCP is a standard for connecting AI applications to external capabilities. An MCP server can expose tools the model can call, resources it can read, and other contextual information that helps an agent interact with systems outside the model itself.
The protocol has also evolved quickly. The MCP 2026-07-28 specification, released in July 2026, introduced a stateless protocol core as well as several authorization hardening changes. The maintainers specifically added stronger issuer validation and continued tightening the authorization model around established OAuth and OpenID Connect practices. According to the MCP project, its Tier 1 SDKs were approaching half a billion downloads per month at the time of the release, although SDK downloads should not be interpreted as the number of production MCP deployments. MCP 2026-07-28 specification release
Those changes matter. A poorly designed authentication flow, stolen token, confused-deputy problem, or token intended for one resource being accepted by another can compromise a system before an AI agent even makes a useful decision.
The current MCP authorization work therefore emphasizes resource-bound tokens, audience validation, secure token handling, PKCE, and protections against token passthrough. The specification explicitly requires servers to verify that access tokens were issued for the server receiving them rather than blindly forwarding credentials between services.
But authentication answers who can connect. Authorization determines what that identity can do. Agent security adds another question: under what conditions should the AI actually exercise that permission?
That third question is where the problem becomes much harder.
Why Is Agent Access a Bigger Security Boundary?
A useful way to think about AI agent risk is:
Risk ≈ accessible capabilities × privilege level × autonomy × exposure to untrusted context
This is not an industry-standard formula. It is a practical way to reason about blast radius.
Consider two agents using the same MCP architecture.
The first can search a read-only product documentation repository. If an attacker manipulates its context, the agent might retrieve the wrong information or expose data that should have been segmented more carefully. That still matters, but its ability to change the environment is limited.
The second agent can read corporate email, post messages, create tickets, edit code, and invoke infrastructure tools. A manipulated decision can now become an action. If several tools are available simultaneously, one compromised instruction can potentially move through more than one system.
This is why least privilege becomes more important as agents become more autonomous.
OWASP’s MCP Security Cheat Sheet identifies excessive permissions and over-scoped tokens as a specific MCP risk. It recommends granting each server only the permissions it needs, using credentials scoped per server, requesting narrow OAuth scopes, and preferring short-lived credentials. OWASP MCP Security Cheat Sheet
The important point is that a secure MCP connection to an overprivileged system is still an overprivileged connection.
Prompt Injection Becomes More Dangerous When the Agent Can Act
Prompt injection is sometimes discussed as a model problem: trick the model into ignoring instructions and producing an unwanted answer.
With an agent, the consequences can extend beyond the answer.
Imagine an AI assistant reading a document that contains hidden or malicious instructions. If the assistant only summarizes the document, the attack surface is relatively contained. If the same assistant can also call an email tool, upload files, query an internal application, or execute a deployment workflow, the injected instruction may try to influence those actions.
MCP did not invent prompt injection. What MCP does is make external capabilities easier to expose through a common interface. That increases the importance of controlling what capabilities are available to the agent in the first place.
There is also a less obvious problem: malicious instructions do not have to come directly from the user.
OWASP warns about tool poisoning, where instructions can be embedded in tool descriptions, parameter schemas, or tool outputs. It also describes tool shadowing, where one malicious server can attempt to influence how an agent interacts with tools from another trusted server.
The MCP specification itself treats tools as a sensitive security boundary. Its security guidance says tool behavior descriptions should not automatically be trusted and that hosts should provide mechanisms for users to understand and authorize tool use. It also notes an important limitation: many of these principles ultimately depend on how the host and integration are implemented rather than something the protocol can enforce on its own.
That makes access design part of prompt-injection defense.
If an agent cannot access payroll records, an injected instruction cannot use that agent to retrieve payroll records. If it cannot send external email, an attacker cannot use that capability as an exfiltration channel. Reducing permissions does not eliminate prompt injection, but it can sharply reduce what a successful injection can accomplish.
Read Access and Write Access Should Not Be Treated the Same
One of the simplest mistakes in enterprise agent design is treating “connected to a service” as a single permission state.
In reality, access should be decomposed much further.
An agent may need to search an inbox without sending email. It may need to inspect a repository without merging code. It may need observability data without permission to restart infrastructure. A support agent may need to create a draft response but should not necessarily be able to issue a refund without a separate approval step.
This distinction already appears in commercial agent tooling. OpenAI’s MCP interfaces, for example, provide controls that can restrict the set of allowed tools and specify which tool calls require approval. Its API also distinguishes tools annotated as read-only when applying approval policies.
The broader architectural lesson is vendor-independent: access control should exist at the tool and action level, not only at the MCP server level.
Connecting an agent to a server containing twenty tools should not automatically mean the model needs all twenty. Nor should a tool that can both retrieve and modify records necessarily expose both operations under the same authorization policy.
This is familiar security engineering. What changes with agents is the actor making the selection. Instead of every API call being explicitly coded by a developer, an LLM may dynamically decide which tool to call based on conversation history, retrieved documents, tool descriptions, and external data.
That makes the permission boundary more consequential.
The Real Risk Is Capability Chaining
Individual tool permissions can also look harmless when reviewed separately.
A document-search tool reads files. A messaging tool sends a message. A web-fetching tool requests URLs. A code tool modifies a repository.
The risk changes when an agent can combine them.
For example, an agent could theoretically read information from one system, transform it, and send the result through another. A web-fetching tool influenced by malicious context could also be directed toward resources it was never intended to reach. OWASP specifically warns that tools accepting LLM-generated URLs can create server-side request forgery risks unless destinations are strictly validated.
This means security reviews should examine capability graphs, not just tool inventories.
The question is not simply:
“What can Tool A do?”
It is:
“What becomes possible when Tool A, Tool B, and Tool C are available to the same agent during the same workflow?”
This is close to a classic attack-path problem. A low-risk permission in isolation can become much more powerful when combined with another capability.
Enterprise agent platforms will therefore need controls that understand not only identity and individual tool permissions, but also which combinations of capabilities are allowed within a task.
OAuth Scopes Are Necessary, but They Are Not Enough
OAuth is an important part of MCP’s remote authorization model, and the current specification increasingly emphasizes established OAuth security controls. The draft authorization specification also explicitly recommends the principle of least privilege when selecting scopes.
But OAuth scopes are only one layer.
A token may correctly authorize an agent to call an API while the underlying service account still has excessive privileges. A single scope may also cover multiple operations with very different consequences. And even a correctly scoped tool may be inappropriate for a particular user, workflow, data classification, or stage of a business process.
Agent authorization therefore needs context.
Who initiated the task? What data is involved? Is the operation reversible? Is this a read, write, delete, execute, or external-send action? Does the action cross a trust boundary? Does policy require a human approval?
Traditional IAM remains necessary, but agent systems increasingly need an additional runtime policy layer between model intent and tool execution.
That layer can reject, narrow, or escalate an action even when the agent technically possesses valid credentials.
What Should Enterprises Control Around MCP?
Enterprises evaluating MCP should avoid treating “MCP security” as a single product checkbox. A more useful review starts with the authority delegated to the agent.
At minimum, teams should examine five areas:
- Tool exposure: Give each agent access only to tools required for its role rather than exposing an entire MCP server catalog by default.
- Permission scope: Separate read, write, execute, delete, administrative, and external-communication permissions wherever possible.
- Approval boundaries: Require human confirmation for destructive, financially significant, privileged, or externally visible actions.
- Credential isolation: Avoid sharing broad credentials across MCP servers, agents, or users, and favor short-lived, resource-specific credentials.
- Execution visibility: Log tool selection, parameters, authorization context, approvals, outputs, and resulting actions so incidents can be reconstructed.
There is another operational requirement that deserves equal attention: tool responses should be treated as untrusted input.
An agent may retrieve content from a webpage, ticket, source-code repository, document, database field, or another tool. Any of those sources could contain instructions that attempt to influence subsequent model behavior. OWASP consequently recommends validating tool inputs and outputs and treating returned content as potentially hostile before adding it back into the model context.
In an agentic architecture, data can become control input. Security architecture needs to reflect that.
Does This Mean MCP Is Unsafe?
No. MCP security and agent security should simply not be treated as the same thing.
A protocol can provide strong authentication, authorization primitives, secure transport, and token handling while an application still grants an agent excessive authority. Conversely, restricting an agent’s permissions does not excuse a weak MCP implementation.
Both layers matter.
The latest MCP specification is strengthening the protocol side of that equation, particularly around authorization. But enterprise deployments still need to make their own decisions about tool exposure, scopes, credential boundaries, approvals, sandboxing, monitoring, and the amount of autonomy an agent receives.
The more useful security question is therefore not:
“Is MCP secure?”
It is:
“If this agent is manipulated, compromised, or simply wrong, what can it actually reach and what can it change?”
That question reveals the real blast radius.
What Changes as AI Agents Gain More Autonomy?
The next security challenge is likely to be dynamic authorization.
Today’s access systems were largely built around people and applications. Agents occupy an uncomfortable space between the two. They act on behalf of users, make intermediate decisions independently, consume untrusted context, and may chain several tools before completing a task.
Static access control can struggle with that combination.
A mature agent security model may need to evaluate permissions continuously: allowing an agent to read one dataset for a particular task, permitting a specific write operation only after approval, preventing cross-system data movement, and revoking access when the workflow ends.
That moves AI security away from a simple “connect or block” model toward task-scoped, context-aware authorization.
MCP can carry the tool interactions. It cannot decide the organization’s risk tolerance for every action those tools make possible.
That remains an architecture and governance problem.
FAQ
What is the biggest MCP security risk?
There is no single MCP security risk, but excessive agent permissions can greatly increase the impact of other attacks. Prompt injection, compromised MCP servers, stolen credentials, or unsafe tool outputs become more serious when an agent has broad access to sensitive data or write-capable systems.
Is MCP itself vulnerable to prompt injection?
Prompt injection is primarily an AI application and trust-boundary problem rather than a vulnerability unique to MCP. However, MCP tools, tool descriptions, and tool outputs can provide additional channels through which malicious instructions reach an agent, so they should be treated as untrusted inputs.
How should companies secure MCP servers?
Companies should combine secure MCP authentication and token handling with least-privilege access, narrow OAuth scopes, tool-level authorization, credential isolation, validation of tool inputs and outputs, human approval for sensitive actions, and detailed execution logs.
Should AI agents have write access?
Some use cases require it, but write access should not be the default simply because a connected service supports it. Read, write, delete, execute, and administrative permissions should be separated, with higher-risk actions subject to tighter policies or explicit human approval.
Is OAuth enough to secure an MCP deployment?
No. OAuth can authenticate and authorize access to resources, but it does not decide whether an AI agent should perform a particular action in a particular business context. Enterprises also need tool-level permissions, runtime policy enforcement, approval controls, and monitoring.
