Because authentication only proves the caller has a valid token, not that the agent should be allowed to perform a specific action. MCP agents choose tools dynamically, so policy controls are needed to evaluate the tool, the target resource, the arguments, and the business context before execution.
Why authentication is not enough for MCP agents
An authenticated MCP agent has proven it holds a valid token, but that alone does not answer whether a specific tool call is safe, appropriate, or authorised in context. MCP clients can select tools dynamically, so the security decision has to happen at execution time, based on the tool, the target resource, the arguments, and the business purpose of the action.
That distinction matters because authentication is a caller check, while policy control is an action check. If you stop at token validation, you allow any authenticated agent to exercise every capability exposed to that token, which is too coarse for systems where one conversation, prompt, or workflow can branch into multiple tool paths.
For that reason, policy belongs alongside authentication in the control plane, not after the fact. The question is not simply “who are you?”, but “what may this agent do, against which resource, with which parameters, and under what conditions?”
What policy must evaluate before an MCP tool executes
Effective policy for MCP should evaluate the action context, not just the subject identity. That usually means checking the requested tool, the resource being touched, the scope of the arguments, the sensitivity of the operation, and whether the current task justifies the request.
That is why least privilege for AI agents is not only about limiting tokens, but about constraining per-action authority. A policy decision point can approve one tool call and deny the next, even if both come from the same authenticated agent session, because the risk is attached to the requested action, not to authentication alone. NHIMG’s AI Agent Authorisation Guide is useful here because it frames task-scoped access, per-action policy decisions, and human approval as the practical control pattern.
In MCP deployments, this also means policy should be able to distinguish read-only discovery from state-changing operations, and low-risk utility calls from high-impact actions such as data export, deletion, provisioning, or secret access. If the policy layer cannot make those distinctions, the agent is effectively trusted to self-authorise.
Why dynamic tool use increases the need for guardrails
MCP increases flexibility because tools are discovered and invoked at runtime, but that same flexibility widens the blast radius when the agent is tricked, over-scoped, or misdirected. The danger is not only malicious compromise, it is also benign-looking requests that become dangerous once they reach a powerful tool with broad permissions.
Policy controls are the mechanism that keep dynamic choice from becoming unconstrained execution. They reduce the chance that a valid token turns into unrestricted action, and they give defenders a place to enforce separation between the agent’s conversational intent and the organisation’s operational intent. NHIMG’s MCP Security Guide covers the OAuth-based authorisation model, token passthrough risks, and gateway patterns that help put that separation into practice.
This is also why a zero-trust posture is a better mental model than simple login trust. Verified identity is necessary, but continuous evaluation of the request is what prevents an authenticated agent from becoming a generic execution conduit. NHIMG’s Zero Trust for AI Agents shows how to verify the principal, remove standing privilege, and enforce policy per action.
Risk and Threat Considerations
The main risk is privilege inflation through valid credentials: once an agent is authenticated, every tool exposed to that session can become reachable unless policy narrows the decision. In MCP environments, that creates a realistic path from legitimate access to unauthorised data movement, destructive operations, or abuse of downstream systems.
Failure mechanism: The agent receives a valid token, selects a tool dynamically, and is allowed to execute without a separate policy check on the action, resource, or arguments. A prompt, workflow change, or compromised instruction can then redirect legitimate access into an unsafe operation.
Impact: Organisations can lose containment around what the agent may touch, making business-critical systems vulnerable to unintended modification, over-collection of data, or misuse of delegated access. The wider the tool surface, the faster a single authenticated session can turn into broad operational exposure.
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 agents need per-action controls because authenticated agents can overreach. |
| Recommendation — Enforce per-action authorisation to prevent authenticated agents from abusing privilege. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Policy controls must limit what an authenticated MCP agent may do after login. |
| IA-5 — Authenticator Management | Authentication proves the caller, but not the correctness of the action decision. | |
| AC-3 — Access Enforcement | Policy enforcement is the control that decides whether a tool call may proceed. | |
| Recommendation — Restrict MCP tool permissions to the minimum needed for each task. Manage tokens and authenticators securely, then apply separate authorisation checks. Enforce access decisions at the point of MCP tool execution. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Tool invocation needs function-level checks, not just a valid token. |
| Recommendation — Apply function-level authorisation to each MCP tool before execution. | ||
Practitioner Guidance
What to prioritise: Put a policy decision point in front of every MCP tool call that can change state, expose sensitive data, or cross a trust boundary. Authentication should open the door to evaluation, not be treated as approval by itself.
What to verify: Confirm that policy can inspect the tool name, target resource, argument content, and request context before execution. If the only gate is token validation or coarse role membership, the control is too weak for a dynamic agent workflow.
Common mistake: Treating MCP like a normal authenticated API session and assuming the agent will only make “reasonable” requests. In practice, the policy layer must assume the agent can be misled, over-scoped, or used outside the original intent of the session.
Practitioner takeaway: For MCP, authentication establishes who is calling, but policy determines whether that caller may perform this action right now, on this resource, for this purpose.