Notifications
Clear all
Topic starter
06/07/2026 9:43 am
TL;DR: Model-level defenses, prompt injection testing, and tool-access controls are central to MCP security, according to Descope’s recap of Andre Landgraf’s talk and supporting OWASP research. The real gap is not model behaviour alone, but whether tool-level authorization, environment separation, and human approval boundaries are strong enough to contain damage.
NHIMG editorial — based on content published by Descope: Why Model-Level Defenses Aren’t Enough for MCP Auth
By the numbers:
- Prompt injection defenses in one study were defeated at above 90% success rates by adaptive attack methods.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Default MCP sessions to read-only capabilities Start with the smallest useful tool set and expand only when a workflow truly requires mutation.
- Require approval for state-changing operations Insert a human confirmation checkpoint before any action that alters records, triggers external side effects, or exposes credentials.
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.
👉 Read Descope’s analysis of why model-level defenses aren’t enough for MCP auth →
MCP auth and tool-level authorization: are your controls ready?
Explore further
06/07/2026 9:59 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Model-level defenses aren’t enough for MCP auth
