Model-level defenses aren’t enough for MCP auth

At a glance

What this is: This is an independent analysis of why MCP security needs more than model-level defenses, with emphasis on prompt injection, context poisoning, instruction drift, and tool-level authorization.

Why it matters: It matters because MCP changes how AI systems request tools and data, so IAM teams must govern not just access to information but access to actions across NHI, autonomous, and human-controlled workflows.

By the numbers:

• Prompt injection defenses in one study were defeated at above 90% success rates by adaptive attack methods.

👉 Read Descope’s analysis of why model-level defenses aren’t enough for MCP auth

Context

MCP security is the problem of controlling what an AI can do once it has access to tools, data, and context. The core weakness is that model behaviour is not a reliable security boundary, especially when untrusted input can be interpreted as instruction.

For IAM and NHI teams, the important shift is from data access alone to tool-level authorization, environment separation, and approval gates. That makes MCP a governance issue as much as a protocol issue, with direct implications for workload identity, least privilege, and human oversight.

Key questions

Q: How should security teams implement MCP authorization for AI agents?

A: Security teams should place authorization in front of tool execution, not only around data access. The model may suggest an action, but the platform should decide whether that tool can be called in the current role, environment, and workflow state. High-risk actions should require explicit approval before execution.

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: What breaks when AI tools are granted broad database access in MCP?

A: Broad database access turns a prompt compromise into an operational compromise. If the AI can query, modify, or retrieve sensitive records without a tighter tool policy, a malicious instruction can reach live systems directly. The safer pattern is limited tool scope with separate permissions for read and write activity.

Q: Who is accountable when an AI agent invokes the wrong MCP tool?

A: Accountability should sit with the organisation that defined the tool policy and approval boundary, because the failure is governance, not just model behaviour. Teams should document who can approve tool sets, who owns environment-specific permissions, and which controls prevent harmful execution before it occurs.

Technical breakdown

Why prompt injection defeats model-level trust

Prompt injection works because LLMs do not cleanly separate developer instructions from user-supplied content. In an MCP flow, the model can ingest a malicious ticket, document, or message and treat it as higher-order instruction even when the surrounding application assumes otherwise. Instruction drift and context poisoning widen the problem by letting malformed or adversarial context reshape the session over time. Security claims based only on model refusals are brittle because they test behaviour, not authorization boundaries.

Practical implication: treat the model as an untrusted interpreter and move enforcement to the tool, session, and policy layers.

Tool-level authorization changes the MCP security model

Traditional IAM answers whether a subject may read or modify a resource. MCP adds a different question: should this AI context be allowed to invoke the tool at all? That means authorization has to sit before tool execution, not after the model decides to act. RBAC can still matter, but it is often too coarse for production MCP deployments, so teams may need finer-grained combinations of RBAC, ABAC, and relationship-based policy to constrain action scope by environment, user role, and workflow.

Practical implication: separate data permission from tool invocation permission and review both during access design.

Why environment separation and human approval remain essential

MCP becomes dangerous when the same agentic workflow is allowed to operate across environments with different blast radii. Read-only access in production, write access in development, and explicit approval for high-risk operations are not optional extras. They are the boundary conditions that keep a compromised or misdirected AI from turning a local mistake into a broad operational event. OAuth 2.1, PKCE, and dynamic client registration help standardize the handshake, but they do not replace policy design.

Practical implication: enforce environment-specific tool sets and require human confirmation for state-changing actions.

NHI Mgmt Group analysis

Model-level defenses are not a security boundary for MCP. Landgraf’s examples show that the model can resist one prompt and fail on another, which means refusal behaviour is neither stable nor sufficient as a control. The security problem is not whether the model sounds cautious, but whether an attacker can shape the session into unsafe action. Practitioners should treat model behaviour as signal, not enforcement.

Tool-level authorization is the missing governance layer in MCP deployments. Access control that stops at the data layer leaves a gap where the model can still invoke destructive or sensitive actions on behalf of a user. MCP forces IAM teams to decide whether the AI can call the tool at all, in what environment, and under which conditions. That makes action authorization a first-class identity concern, not an implementation detail.

Blast radius is the decisive design variable for agentic integrations. Landgraf’s read-only default and environment separation advice reflect a broader truth: the safest MCP deployment is the one that makes harmful action hard to persist. The named concept here is tool-level blast radius, which is the maximum damage an AI can cause through the tools it is allowed to reach. Practitioners should judge every MCP path by the harm it can still create when input is malicious.

Progressive scoping matters more than model confidence. MCP and OAuth 2.1 can standardize how an agent connects, but they do not solve where it should be allowed to operate or what it may do after connection. That is why privilege must be narrowed by workflow stage, environment, and approval state. Security teams should stop asking whether the model is reliable enough and start asking whether each tool grant is reversible, isolated, and auditable.

Human-in-the-loop remains a control, not a comfort blanket. For high-risk operations, the key question is not whether the model can propose the action, but whether a human must still intend the action before it executes. That distinction matters because MCP compresses the distance between prompt and effect. IAM programmes should preserve human confirmation wherever state change, data exfiltration, or production impact is possible.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• That growth curve makes OWASP Agentic Applications Top 10 the right next step for teams deciding which agent and tool controls to prioritise first.

What this signals

Tool-level blast radius: MCP programmes should now be judged by the damage a compromised or misdirected agent can still cause after authentication succeeds. The governance question is no longer whether an AI can connect, but whether each tool grant remains isolated, reversible, and reviewable in production. That is where identity teams need to focus their design effort.

With 98% of companies planning to deploy more AI agents within the next 12 months, the operational problem is scaling faster than control maturity. The organisations that move first on environment separation, approval gates, and policy-bound tool invocation will have a materially smaller exposure surface than those waiting for model quality to improve.

The stronger architectural pattern is to combine least privilege with task-scoped tool access and explicit confirmation for state change. For practitioners, that means MCP onboarding should be treated like a privileged access design exercise, not a simple integration task, and it should be aligned with the OWASP Top 10 for Agentic Applications 2026 where autonomous tool misuse is a core risk.

For practitioners

• Separate tool authorization from data authorization Define explicit policy for whether an AI context may invoke each tool, not just whether the underlying user may read the data. Review the policy at the workflow and environment level, especially for production databases and write-capable actions.
• Default MCP sessions to read-only capabilities Start with the smallest useful tool set and expand only when a workflow truly requires mutation. Keep production write access out of general-purpose AI paths and use different entitlements for development and production.
• Require approval for state-changing operations Insert a human confirmation checkpoint before any action that alters records, triggers external side effects, or exposes credentials. The approval should sit after tool selection but before execution so the boundary is enforced even if the model is tricked.
• Segment environments and client registrations Use distinct client registrations, tokens, and permission sets for development, staging, and production MCP traffic. A compromised assistant in one environment should not inherit the ability to act in another.
• Test for prompt injection against live tool paths Validate the full chain from malicious input to tool invocation, not just the model response. Include context poisoning, instruction drift, and tool misuse in red-team exercises so controls are measured where harm actually occurs.

Key takeaways

• MCP security fails when teams treat model behaviour as the control boundary instead of tool authorization and approval policy.
• Prompt injection, context poisoning, and instruction drift make live tool paths the real attack surface for AI-assisted workflows.
• The practical defense is narrower scope, stronger environment separation, and human confirmation before high-risk execution.

Key terms

• Tool-level authorization: Tool-level authorization is the policy decision that determines whether an AI context may invoke a specific external action. In MCP environments, it sits above data access and below user intent, making it the control that prevents a model from turning a prompt into an unsafe operation.
• Prompt injection: Prompt injection is an attack that uses malicious input to steer an AI system into ignoring or overriding its intended instructions. In agentic and MCP workflows, the danger is not just a bad answer, but unauthorized tool use, data exposure, or state-changing actions triggered by untrusted text.
• Tool-level blast radius: Tool-level blast radius is the maximum harm an AI can cause through the tools it is permitted to reach. It is shaped by environment, write capability, approval requirements, and the sensitivity of the connected system, and it is the right lens for judging whether an MCP integration is safe enough to run.
• Context poisoning: Context poisoning is the introduction of false or misleading material into an AI system’s working context so that it treats the material as trusted reference. In practice, it can distort retrieval, reasoning, or downstream actions, especially when the model has access to live tools or operational data.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• A deeper breakdown of MCP auth flows, including OAuth 2.1, PKCE, dynamic client registration, and protected resource metadata.
• The session recap from Andre Landgraf with concrete examples of prompt injection behaviour against MCP-connected tools.
• Practical examples of read-only defaults, environment separation, and human-in-the-loop checkpoints for production deployments.
• The article's discussion of emerging MCP auth concepts such as client ID metadata documents and how they affect rollout readiness.

👉 Descope’s full post covers the attack patterns, authorization gaps, and production guardrails in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.