Model-level defenses aren’t enough for MCP auth

At a glance

What this is: This is an analysis of why MCP security depends on tool-level authorization and operational boundaries, not just model behavior, because prompt injection and context poisoning can still reach sensitive tools and data.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as an authorization design problem, because the model can only be made safe when tool scope, environment separation, and human approval boundaries are enforced outside the model.

Context

Model Context Protocol, or MCP, is a way for AI systems to connect to external tools and data sources without custom integrations for each app. The security problem is that once an AI context can invoke tools, traditional model-level guardrails no longer define the real boundary of access.

For identity and access teams, that means the control question shifts from what the model can understand to what it can invoke. Descope’s recap frames MCP as an emerging authorization problem for agentic systems, where tool permissions, environment separation, and approval gates matter more than prompt hygiene alone.

Key questions

Q: Why do model-level defenses fail as the main control for MCP?

A: Model-level defenses are unstable because they depend on how the model interprets language in a particular session. Prompt injection, context poisoning, and instruction drift can change behaviour without changing formal permissions. That is why the control boundary has to move to tool policy, environment separation, and approval gates.

Q: Why do MCP deployments need tool-level authorization instead of just model safeguards?

A: Because the model can only judge text, while tool-level authorization decides whether the session may read, write, or execute anything with operational impact. Without that extra boundary, a confused or manipulated model can turn ordinary input into privileged action.

Q: What breaks when AI assistants share the same permissions across dev and production?

A: The blast radius expands from experimentation into live systems. A tool that is acceptable for development can become a production incident if the same assistant can write state, query sensitive data, or bypass review in a higher-risk environment.

Q: How should security teams handle approval for high-risk MCP actions?

A: Approval should be reserved for actions that are irreversible, high impact, or likely to change access, data exposure, or production state. The goal is not to slow every task, but to stop the few actions that create real business risk if executed incorrectly. Approval should occur before the sensitive permission is granted or the action executes.

Technical breakdown

Why model-level defenses fail once MCP exposes tools

Model-level defenses operate inside the language model, but MCP moves the security problem to the interface between the model and external systems. Prompt injection can alter behaviour, context poisoning can corrupt the information the model treats as source material, and instruction drift can cause the session to lose its original purpose. None of those failure modes require the model to be malicious; they exploit the fact that the model cannot reliably distinguish trusted instructions from untrusted text once everything is presented as context.

Practical implication: Treat model safety as insufficient and place authorization controls on the tools and data sources themselves.

Tool-level authorization for AI contexts

Traditional authorization decides whether a user may access a resource. MCP adds a separate question: should the AI context be allowed to call the tool at all, and under what role, environment, and scope? That is closer to role-based access control extended to tool invocation, with stronger designs using attribute-based or relationship-based checks when workflow, environment, and data sensitivity differ. For production, read-only defaults and context-specific tool sets reduce blast radius far more reliably than model prompts do.

Practical implication: Define tool allowlists by workflow and environment before deployment, not after the model is connected.

Why environment separation and human approval still matter

MCP makes it easy for the same assistant to operate across development and production, but those environments should not share the same authorization posture. A database tool that is acceptable in a development context becomes a production incident if the model can write state without review. Human-in-the-loop checkpoints matter because high-risk operations need an external intent check, not just a role claim. In practice, the architecture has to assume the model will sometimes be misled and must still fail safely.

Practical implication: Separate production and development tool paths and require explicit approval for state-changing actions.

Threat narrative

Attacker objective: The objective is to turn ordinary AI context ingestion into unauthorized tool use, secret exposure, or unsafe database access.

1. Entry occurs when untrusted user input, such as a support ticket or document, reaches an MCP-enabled model with live tool access.
2. Credential or context abuse follows when the model accepts injected instructions or poisoned content as part of the working session.
3. Escalation occurs when the model is allowed to invoke tools or query data beyond the intended workflow boundary, including sensitive admin paths.
4. Impact is the disclosure of secrets, unintended data access, or unsafe state changes through a tool call the model was never meant to make.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Tool-level authorization is now the real MCP control plane: model quality can reduce some abuse, but it cannot define who or what may invoke a database tool, write to production, or cross environment boundaries. That means the identity boundary has moved from prompt handling to invocation governance. Practitioners should treat the model as a potentially untrusted caller and enforce authorization at the tool layer.

Blast-radius control is the governing design principle for MCP: the core question is not whether an AI can be trusted in the abstract, but how much damage a compromised or confused session can do. Read-only defaults, development-production separation, and workflow-specific tool sets are the practical expression of that principle. The narrower the tool scope, the less every prompt becomes a potential security event.

Model-level defenses assume the wrong failure domain: they presume the model itself can be made reliably resistant to malicious input. MCP shows that the security failure often happens one layer earlier, where untrusted text becomes session context and then becomes tool invocation. The implication is that identity governance for agentic systems must move from inference-time trust to issuance-time constraints.

Context poisoning creates an identity problem, not just a content problem: once the model treats ingested text as authoritative, the session can inherit false premises and act on them with real privileges. That is why tool access, data provenance, and approval boundaries must be designed together. In MCP deployments, provenance without authorization is incomplete, and authorization without provenance is brittle.

Agentic identity governance will converge on least-privilege tool access: the field is heading toward more fine-grained authorization models because static role assignment is too coarse for mixed workflows. The winner is not more model caution, but better separation between reading, reasoning, and acting. Organisations that continue to grant broad tool access to AI contexts will keep converting inference errors into operational risk.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Tool authorization is the MCP governance gap: sessions that can invoke tools need their own access policy, because model-level resistance does not stop a session from crossing into production data or write paths. The practical shift is from prompt controls to invocation controls, with environment separation as the first containment layer.

24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That scale shows why MCP should be treated as a secrets and authorization surface, not just an integration pattern.

A mature MCP programme needs to assume that untrusted content will eventually reach a session with real permissions. The right response is to reduce what any session can do, not to assume the model will always interpret context correctly.

For practitioners

• Define tool-level allowlists Map each MCP workflow to the smallest set of tools it actually needs, and deny tool invocation by default unless the session explicitly qualifies for that workflow.
• Separate production from development access Give AI contexts different tool permissions in non-production and production environments, especially where write access could change state or expose sensitive records.
• Require human approval for state-changing operations Insert an explicit approval step before any destructive, irreversible, or externally visible action, even when the role and token are valid.
• Treat untrusted content as hostile session input Assume tickets, documents, and retrieved context can carry instructions that affect tool use, and prevent those inputs from inheriting authority over the session.

Key takeaways

• MCP security fails when model-level trust is allowed to stand in for tool-level authorization, because the model can still be manipulated through context and injected instructions.
• The article highlights a real production problem: broad tool access turns AI context into a pathway to production data, write actions, and leaked secrets.
• The control that matters most is blast-radius reduction through environment separation, least-privilege tools, and human approval for high-risk actions.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
• Instruction drift: Instruction drift is the gradual change in how an agent ranks or interprets instructions after repeated interactions. It matters because the agent can begin to prefer conditioned context over original policy, creating a slow governance failure that is difficult to detect in a single review cycle.

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.