How should security teams control MCP tool calls after authentication succeeds?

Why This Matters for Security Teams

MCP tool access is not governed safely just because authentication succeeded. A login event proves an identity existed at one moment; it does not prove that every later tool invocation is appropriate for the current workflow, target system, or delegating agent. That gap is why runtime authorization has become the real control point for model-driven execution, especially when a tool can write, delete, or move data. Current guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same operational problem: autonomous systems chain actions faster than static policy assumptions can keep up.

This matters because MCP deployments often inherit coarse token scopes, then treat them as if they were sufficient for every downstream call. In practice, that creates a large blast radius when an agent is redirected, prompted, or simply behaves in an unexpected way. NHIMG’s review of MCP server security found that only 18% of deployments implement any form of access scoping for tool permissions, which shows how immature the control plane still is. In practice, many security teams discover over-permissioned tool calls only after the first unauthorized write has already occurred, rather than through intentional policy design.

How It Works in Practice

The correct control is a separate authorization decision at the moment of each call_tool request. That decision should evaluate the tool name, the requested action, the target resource, the workflow state, and the identity that delegated the action. Authentication establishes who or what is calling; authorization decides whether this specific tool invocation is acceptable right now. For agentic workflows, best practice is evolving toward intent-aware policy rather than static role checks, because the same authenticated agent may be safe to read a ticket but unsafe to approve a payment or update a production record.

Operationally, teams should combine short-lived workload identity with policy-as-code. Workload identity systems such as SPIFFE/SPIRE or OIDC-backed service identities let the platform prove what the agent is, while runtime policy engines such as OPA or Cedar decide what it may do. That policy should be evaluated at request time and should consider context such as user delegation, environment, tool sensitivity, and whether the call is read-only or mutating. This aligns with the direction described in the Ultimate Guide to NHIs — Standards and with implementation concerns discussed in Analysis of Claude Code Security.

• Issue ephemeral credentials per task, not shared long-lived secrets.
• Evaluate tool access separately for read, write, and admin actions.
• Bind approval to the delegating identity, not just the agent session.
• Revoke or narrow permissions immediately after the task completes.

This approach reduces blast radius, but it depends on the MCP server exposing enough context for policy evaluation and on downstream systems honoring the result. These controls tend to break down when vendors collapse authentication and authorization into one token check, because the policy engine never sees the actual tool intent.

Common Variations and Edge Cases

Tighter per-call authorization often increases latency and integration overhead, so organisations have to balance stronger blast-radius control against throughput and engineering complexity. There is no universal standard for this yet, especially across mixed MCP ecosystems where some tools are read-only, some are state-changing, and some proxy to external systems with their own permissions model. The policy should therefore be stricter for mutating tools and more permissive, but still context-aware, for low-risk retrieval actions.

One common edge case is delegated access. If an agent acts on behalf of a human, the policy needs to preserve that delegation chain so the tool server can distinguish direct agent authority from user-approved authority. Another is chained tool use, where one seemingly safe call can set up a later dangerous write. That is why current guidance suggests evaluating not just the requested tool, but the workflow step and the downstream effect. NHIMG’s AI Agents: The New Attack Surface report highlights how often agents exceed intended scope, which is exactly why static login success is not enough.

For high-risk environments, the practical rule is simple: if the call can change data, move credentials, or trigger side effects, it deserves a fresh decision. If the environment cannot supply that context, then the safer answer is to deny by default until the MCP integration is redesigned.

Related resources from NHI Mgmt Group

• How should security teams govern MCP agents that can switch between tool calls and generated code?
• How do organisations govern tool calls in MCP-enabled agent systems?
• What is MCP in the context of AI security?
• How should security teams govern machine identity credentials in agentic AI environments?