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.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Why Model-Level Defenses Aren’t Enough for MCP”.
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.
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.
Q: What breaks when AI assistants share the same permissions across dev and production?
A: The blast radius expands from experimentation into live systems.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/07/2026 9:59 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Model-level defenses aren’t enough for MCP auth