MCP security is an authorization problem, not an authentication one

At a glance

What this is: This is an analysis of why Model Context Protocol improves AI connectivity but does not solve security, with authorization left to implementers and breach evidence showing that gap is exploitable.

Why it matters: It matters because IAM teams now have to govern AI agents, tools, and data access as first-class identities and decisions, not treat MCP as a secure-by-default integration layer.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Authzed's analysis of MCP authorization gaps and AI security

Context

Model Context Protocol is a connectivity standard for AI agents, not a security control. It helps applications talk to tools, data sources, and APIs, but it does not decide what an authenticated actor should be allowed to do, which leaves authorization design squarely on the organisation.

That gap matters for MCP server security because the article ties real breach patterns to weak tool scoping, over-privileged tokens, and supply chain trust assumptions. For IAM and NHI teams, the issue is not authentication alone, but whether permission checks exist at the point of tool use and data access.

Key questions

Q: How should security teams govern MCP tool access in production?

A: Security teams should define tool-level authorization rules, not just authenticate the caller. Each MCP server should have explicit scope boundaries, execution-time checks, and monitoring for context that can influence a tool call. If a tool can access sensitive data or communicate externally, it needs a separate permission decision, not a generic session grant.

Q: Why do MCP deployments increase the risk of data exfiltration?

A: MCP can place sensitive data, untrusted content, and outbound communication in the same workflow. That combination gives attackers a route to steer an agent into leaking data through legitimate tools. The risk is structural, because the model processes context holistically, so containment depends on strict input and egress controls.

Q: What do security teams get wrong about MCP authorization?

A: Teams often assume authentication and token scopes are enough. In practice, scopes rarely describe the exact tool action, the data class, or the timing of the decision. Without deterministic authorization at the point of use, an authenticated session can still be granted far more capability than intended.

Q: How can organisations reduce prompt-injection risk in MCP workflows?

A: They should reduce the amount of sensitive content that can enter the context window, constrain which tools can act on that content, and block unnecessary outbound communication. Prompt injection becomes far less effective when the model cannot both see valuable data and exfiltrate it through a permitted channel.

Technical breakdown

MCP authentication versus authorization boundaries

MCP borrows familiar identity mechanics such as OAuth 2.1, token validation, and OpenID Connect discovery, but those mechanisms only prove identity and carry scopes. They do not define whether a user or agent should be allowed to call a specific tool, access a specific resource, or combine multiple tools into a risky workflow. In MCP, the server is effectively a resource server, which means implementation quality determines whether scopes are narrow, meaningful, and enforced at execution time. That separation is the core design tension: the protocol standardises connection, not decision-making.

Practical implication: treat MCP integration as an authorization architecture decision, not a simple authentication enablement task.

Why the lethal trifecta turns MCP into a data-exfiltration path

The article applies the lethal trifecta pattern to MCP: private data, untrusted content, and external communication together create a predictable exfiltration path. If an AI agent can read sensitive content, ingest attacker-controlled text, and send information outward, prompt injection or tool poisoning can convert a normal workflow into a disclosure event. This is not a model flaw alone. It is a systems-design failure caused by combining capabilities without tightly constraining context and egress. Once sensitive data enters the LLM context window, security shifts from prevention to containment, which is a far weaker position.

Practical implication: break the trifecta by restricting what enters context and what leaves through tool calls and outbound channels.

Execution-time permission checks are the control that MCP needs

The article’s central technical point is that session-start approvals are too weak for dynamic AI workflows. MCP environments change quickly, tools can be added or reconfigured, and agents may chain actions in ways that were not known when the session began. That is why the permission decision has to happen when the tool call is made, not only when the connection is established. Deterministic authorization is also important because AI-based policy checks remain probabilistic, which is useful for detection but not for allowing or denying access. The architecture therefore needs low-latency, runtime enforcement.

Practical implication: enforce permissions at tool execution time and reserve AI for detection, not final authorization.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI integration into a data disclosure channel that can leak private repository content, documents, or tokens.

1. Entry occurs when a legitimate MCP connection exposes a private data source, an untrusted content source, and an external communication path in the same workflow.
2. Escalation follows when prompt injection or tool poisoning causes the agent to invoke an allowed tool in a way that leaks sensitive content or broadens scope.
3. Impact is data exfiltration through a trusted AI workflow, often without malware, stolen credentials, or obvious system compromise.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is an authorization design problem disguised as an integration problem. The protocol’s identity mechanics are real, but they stop at proving who connected and which scopes were requested. That leaves the hard decision of what a tool call is allowed to do inside the application and its policy layer. Practitioners should stop treating MCP as a secure transport and start treating it as a permissions architecture that must be deliberately governed.

The lethal trifecta is the named failure mode that explains most MCP risk. Private data, untrusted content, and external communication are not independent features when they coexist in the same agent workflow. They create an identity blast radius that conventional user-centric IAM does not model well, because the subject is not a person making one request but an agent chaining decisions across context, tools, and egress. The implication is that control design has to account for compound behaviour, not isolated actions.

Execution-time authorization is the baseline control that MCP deployments keep underestimating. Session-level trust assumptions were designed for static workflows where privilege state changes slowly enough to review. That assumption fails when the agent can decide, at runtime, which tool to invoke and when to do it. The implication is that governance must move from provisioning-time review to request-time enforcement, because the old review cadence cannot see the decision that creates the risk.

Context-window governance: the real control surface is what data is allowed into the model before any tool call occurs. Once untrusted text and sensitive records share the same prompt context, the model can be steered into policy-breaking behaviour even when authentication is correct. This changes NHI governance from identity-only thinking to combined identity plus data-flow control. Practitioners should treat prompt ingress as part of authorization scope, not as a separate AI problem.

AI-ready authorization will become a core identity programme requirement, not a niche AI add-on. The article’s velocity argument is sound: AI use cases shift fast enough that hardcoded policy logic will age out quickly. That is especially true where agents, tools, and services all need permissions as first-class subjects. Security teams should expect MCP governance to pull IAM, NHI, and data-access policy into one operating model rather than three separate conversations.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• For broader AI agent governance context, see AI Agents: The New Attack Surface report, which shows how agent behaviour can outgrow current policy models.

What this signals

Context-window governance: MCP adoption is pushing identity teams to think beyond authentication and into data-flow control, because the real risk emerges when trusted context and tool execution are allowed to co-exist unchecked. That is why AI agent governance now sits at the intersection of IAM, NHI, and DLP rather than any single control domain.

With only 18% of MCP server deployments implementing access scoping for tool permissions, according to The State of MCP Server Security 2025, most organisations are still treating tool access as an implementation detail. That is a programme-level blind spot, not a tuning issue.

Teams should prepare for MCP to force policy convergence across identity, application, and data layers. The practical signal is simple: if you cannot explain who can call which tool, with which data, at what moment, the control model is not ready for production AI.

For practitioners

• Map every MCP tool to an explicit permission decision Inventory which tools, resources, and data classes each server can reach, then define a deterministic allow or deny rule for every call path. Do not rely on broad session scopes to cover all future tool use.
• Separate context ingestion from tool execution rights Limit what data can enter the model context window and independently control which tools the agent may call. A request can be authenticated and still be unsafe if sensitive context and outbound communication are both present.
• Move authorization checks to execution time Validate permissions at the moment the tool is invoked, not only at login or session creation. This prevents stale approval from covering a later action that was not visible when the session began.
• Treat MCP servers as first-class access boundaries Apply isolation, scoping, and monitoring to each server as if it were a privileged integration tier. That includes reviewing whether any server can reach private repositories, email, or external APIs without tighter constraints.

Key takeaways

• MCP does not secure AI applications by itself, because the protocol stops at connection mechanics and leaves authorization to implementers.
• The main breach pattern is structural rather than exotic, combining weak tool scoping, untrusted content, and outbound communication into a usable exfiltration path.
• Security teams need deterministic, execution-time authorization for MCP, plus tighter control over context ingestion and tool-level privilege.

Key terms

• Model Context Protocol: A protocol that standardises how AI agents connect to tools, data sources, and APIs. It does not define whether a connected actor should be allowed to use those resources, so security depends on the implementer’s authorization model and enforcement quality.
• Tool-level authorization: A permission model that decides whether a specific action, such as calling a tool or reading a resource, is allowed at the moment it is requested. In MCP environments, this is more important than simple session authentication because the workflow can change after login.
• Lethal trifecta: A risk pattern in which an AI system can access private data, ingest untrusted content, and communicate externally. When all three are present together, prompt injection or tool poisoning can convert a normal workflow into a data-exfiltration path.
• Context window: The working memory available to an AI model during a session. Anything placed inside it can influence the model’s next action, which means sensitive data entering the context window becomes part of the security boundary and must be controlled carefully.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.

This post draws on content published by Authzed: MCP security is an authorization problem, not an authentication one. Read the original.