Because the model can describe intent without being the system that enforces it. The harness, server, and tool layer decide whether a request is actually executable, so identity, schema, and provenance checks have to live there. Otherwise the model’s output can still become an authorised external action.
Where MCP enforcement has to live
MCP-connected agents work through a chain of components, not through the model alone. The model can propose, but the harness, server and tool layer decide whether a request is valid, permitted and executable. That is why enforcement belongs where the action is actually mediated, especially when an external system can be changed, queried or instructed.
For practitioners, the important boundary is between language generation and enforceable authority. A model output is only advisory until the surrounding runtime checks identity, scope, request shape and policy. In practice, that means the enforcement point must understand the request as an executable transaction, not just as text.
That separation is also what keeps an agent from turning a plausible plan into an unintended side effect. If the tool layer does not independently evaluate the call, the system can end up treating a model suggestion as if it were an approved operation. The right design assumption is that the model may be smart, but it is not the policy engine.
Why model context is not enough for authority decisions
Model context is useful for reasoning, but it is not a trusted control plane. It can be incomplete, manipulated, or simply wrong about what the user or agent is allowed to do. Enforcement outside the context lets the runtime reject a request even when the model presents it confidently and the surrounding conversation makes it sound reasonable.
This matters because MCP workflows often combine ambient prompts, retrieved context and tool invocation in the same session. If policy is inferred from that context instead of checked externally, the system starts trusting language over authority. That is a fragile design, especially when the same request may carry different meaning depending on the target server, tenant, environment or action.
The practical rule is simple: the model may describe intent, but the runtime must decide whether intent maps to a permitted call. That is where schema validation, provenance checks and identity checks become real control points. It is also where the server can enforce tool-specific constraints that the model cannot reliably self-apply.
What has to be enforced at the tool boundary
Three checks usually matter most. First, identity: the system must know which principal, agent or delegated session is asking. Second, schema: the request must match the expected tool contract, not just a free-form instruction. Third, provenance: the runtime should be able to tell where the request came from and whether it was transformed or forwarded through another component. The MCP authorization specification is useful here because it anchors the server-side view of authorization rather than relying on model output.
That pattern aligns with broader agent security guidance. When an agent can reach tools, the meaningful control is not whether the model “knows” the policy, but whether the execution path enforces it on every call. NHIMG’s MCP Security Guide and AI Agent Authorisation Guide both reflect the same operational reality: access should be decided per action, not assumed from the conversation state.
In stronger deployments, the harness or gateway also becomes the place to enforce least privilege, temporary access and action-level approval. That is what prevents a useful assistant from becoming a general-purpose dispatcher with unchecked downstream reach. If the enforcement layer cannot explain why a request was allowed, it probably is not enforcing enough.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tool execution depends on agent authority and delegated access. |
| ASI02 — Tool Misuse | MCP tools can be invoked in unsafe ways when model output is trusted directly. | |
| Recommendation — Enforce per-action authorization and bound agent privilege at the tool boundary. Validate each tool call against policy before the action executes. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP servers must authorize which functions an agent may invoke. |
| Recommendation — Check function-level authorization on every MCP request, not in the prompt. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Agent and external caller identity must be established outside the model. |
| AC-6 — Least Privilege | MCP tool access should be constrained to the minimum needed actions. | |
| Recommendation — Authenticate the calling principal before any tool execution is allowed. Restrict each agent to the minimum tool privileges required for the task. | ||
Practitioner Guidance
What to verify: Verify that the MCP server or gateway independently authenticates the caller, validates the tool schema and rejects anything that is only implied by model context. If the model can influence the request but the runtime cannot audit the decision, the control is too weak to trust.
Decision rule: If a tool call can alter data, trigger an external action or reveal sensitive state, treat the model as untrusted input to the policy layer, not as the policy layer itself. Put the allow or deny decision at the boundary that actually executes the call.
What good looks like: Every executable request has a clear principal, a bounded scope and a traceable provenance chain. The model can still assist with intent formation, but it cannot silently upgrade itself into authority.
Practitioner takeaway: MCP is secure when the runtime enforces what the model only proposes, because authority must be checked at the point of execution, not inferred from text.
Related resources from NHI Mgmt Group
- Why do MCP-connected AI agents create higher risk when they can load workspace or tool context automatically?
- What is the Model Context Protocol (MCP) and why does it matter for security?
- How should organizations prioritize security in their MCP implementations?
- How does automated secret rotation change the operational model?