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.
Why This Matters for Security Teams
MCP is attractive because it gives models a standard way to call tools, but that convenience can hide a control gap. If the main defense lives inside the model, the security boundary becomes whatever the model decides to follow in that session. Prompt injection, context poisoning, and instruction drift can all change tool use without any change to formal access permissions. That is why current guidance increasingly pushes control out of the prompt layer and into tool policy, environment separation, and approval gates, as reflected in the OWASP Agentic AI Top 10.
For practitioners, the core issue is not whether the model is “smart enough,” but whether it can be trusted to preserve intent under adversarial input. NHIMG research on the State of MCP Server Security 2025 shows how often MCP deployments still rely on weak configuration practices, including hard-coded secrets and limited tool scoping. That combination turns model-level defenses into a thin layer over a fragile operational base. In practice, many security teams encounter the failure only after a tool has already been invoked with the wrong context, rather than through intentional policy design.
How It Works in Practice
Model-level defenses are best treated as advisory, not authoritative. The model can help classify requests or suggest safe behavior, but the enforcement point should sit outside the model in a policy engine, gateway, or tool broker. That means an MCP server should not trust the model’s internal judgment about whether a request is safe. Instead, each tool call should be evaluated against explicit rules: who or what is calling, what tool is being requested, what data is in scope, and whether the current context matches an approved task.
Practically, this shifts teams toward layered control:
- Separate the model runtime from the tool execution environment so prompt content cannot directly alter privileged systems.
- Use allowlists for MCP tools and endpoints, then scope each tool to the minimum action needed.
- Require approval gates for sensitive actions, especially write operations, destructive changes, or access to secrets.
- Store secrets outside prompts and logs, and rotate them quickly if exposure is suspected.
- Monitor for anomalous tool chaining, because an agent can combine harmless actions into a harmful sequence.
That approach aligns with the risk patterns highlighted in NHIMG’s OWASP Agentic Applications Top 10 and is consistent with the OWASP Top 10 for Agentic Applications 2026, which both emphasise that agentic control must be enforced at the system boundary, not only in model behaviour. These controls tend to break down when multiple tools share the same broad credential set because one compromised path can unlock the rest of the environment.
Common Variations and Edge Cases
Tighter tool gating often increases operational friction, requiring organisations to balance safety against developer speed and automation depth. That tradeoff is especially visible in high-volume workflows where every extra approval step can slow delivery. Best practice is evolving here, and there is no universal standard for exactly how much context a model should be allowed to carry into a tool decision.
Edge cases usually appear in three places. First, read-only tools are not automatically safe if they can expose sensitive data that later influences another action. Second, “trusted” internal agents can still be abused through prompt injection if they process external content. Third, MCP environments that mix test, staging, and production systems often collapse their own separation because a single model session can reach across boundaries if permissions are too broad. NHIMG’s Analysis of Claude Code Security is a useful reminder that even advanced model tooling still depends on defensive architecture outside the model itself.
For teams building a control baseline, the practical question is not whether the model can detect misuse, but whether the surrounding system can stop it even when the model fails. That is the difference between a safety feature and a real security control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Addresses prompt injection and tool misuse in agentic workflows. | |
| CSA MAESTRO | Focuses on secure orchestration and control separation for AI agents. | |
| NIST AI RMF | Supports governance and risk management for AI system behavior. |
Place authorization in the orchestration layer, not the model prompt.
