By NHI Mgmt Group Editorial TeamBased on Highflame: “Traditional Authentication Isn’t Enough for Agent & MCP Security” (March 10, 2026)

TL;DR: MCP and agent adoption are exposing a gap in traditional IAM: authenticating the user behind an agent does not control which tools the agent can call, what arguments it can pass, or what data can flow back, according to Highflame. The real requirement is policy and inspection at the tool layer, because authentication alone cannot govern agent behaviour.

At a glance

What this is: This is an analysis of why MCP security cannot stop at user authentication and token handling, with the key finding that tool-level policy and inspection are required to govern what agents can actually do.

Why it matters: IAM and IGA teams need to treat MCP as an authorisation and data-flow problem, because authenticated requests can still drive privileged tool use, boundary violations, and unintended data movement.

Context

MCP security is the problem space here, not simple user login. As agents gain the ability to call tools that read repositories, query customer records, trigger workflows, or modify infrastructure, the control question shifts from who authenticated to what the tool call is allowed to do.

Traditional IAM models answer identity proofing and token validity, but they do not govern agent behaviour at the action level. That leaves a gap between successful authentication and permitted execution, which is where policy control, argument inspection, and response filtering have to come in.

The article's core point is that AI systems are no longer passive consumers of data. They are execution paths inside production systems, so the governance model must cover tool invocation, context, and data egress, not only credential hygiene.

Key questions

Q: What breaks when MCP servers do not require authentication?

A: When MCP servers do not require authentication, the access boundary disappears. Attackers and scanners can enumerate tools directly, invoke exposed functions, and abuse those surfaces as if they were intended users. That turns an integration protocol into a public attack surface and makes later authorisation checks largely irrelevant.

Q: Why do authenticated AI agents still need policy controls in MCP?

A: 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.

Q: What are the warning signs that MCP access is not properly controlled?

A: Warning signs include hard-coded credentials in server files, broad tool permissions, no per-tool ownership, and logs that cannot show which agent made a call. If teams cannot trace a tool action back to an identity, policy, and purpose, the access model is too loose to trust.

Q: Should security teams treat MCP tool calls like ordinary API requests?

A: No. Ordinary API auth often assumes a fixed client and a narrowly defined action, while MCP introduces delegated, agent-driven execution with changing intent and broader context. Tool calls need explicit authorisation and inspection because the risk is not just access, but how an agent uses that access.

Technical breakdown

Why authentication is not tool authorisation in MCP

In MCP, an authenticated user token only proves that a request came from a valid identity. It does not prove that the specific tool call, arguments, or downstream effect are appropriate for that identity. That distinction matters because agents can dynamically choose tools while solving a task, which makes the runtime action set broader than the user explicitly intended. A secure model needs to evaluate principal, action, resource, and context together before forwarding the call. This is closer to policy enforcement than classic session validation.

Practical implication: treat authenticated MCP requests as untrusted until the tool, arguments, and resource context have all been authorised.

Why agent-selected tools create privilege drift

Traditional applications expose a predictable path from user action to system action. Agents do not. They can decide at runtime to use a tool that exists but was never meant to be part of the effective permission scope for that task. In practice, a read-only user can end up with agent-driven access to webhook creation, record deletion, or bulk export simply because the tool is available. That is privilege drift at the tool layer: the user's identity stays the same while the reachable action space expands beyond intent.

Practical implication: define tool-specific authorisation boundaries so the presence of a tool does not equal permission to use it.

Why inspection must cover arguments and responses

MCP risks do not stop at tool selection. Tool arguments can carry prompt injection, malicious payloads, or cross-tenant identifiers that bypass ordinary identity checks. Tool responses can bring sensitive data, credentials, or internal documents back into model context, where they may leak through prompts, logs, or subsequent outputs. That means the security boundary has to inspect both inbound request content and outbound response content. Without that inspection layer, authentication only confirms the caller while ignoring the content-driven attack surface.

Practical implication: inspect MCP arguments before execution and redact or block sensitive response content before it reaches model context.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool-layer authorisation is now the control plane for MCP security: user authentication answers identity, but it does not answer whether an agent should execute a specific tool call. The article is describing a real control gap between valid login and valid action, and that gap is where policy engines now matter most. For practitioners, the decisive question is no longer whether the token is correct but whether the request is allowed in context.

Dynamic tool choice breaks static permission assumptions: MCP agents can select tools at runtime, which means least privilege cannot be inferred from a user's ordinary application role. A repository reader, for example, may still be able to invoke creation, deletion, or export tools if those functions are exposed. The governance problem is not authentication failure, it is effective privilege expansion through tool availability. Practitioners should treat tool exposure as part of the access model, not as a neutral integration detail.

Policy and inspection are now inseparable in agent security: the same request path that authorises a tool call must also examine its arguments and responses for prompt injection, exfiltration, and unsafe payloads. That creates a named concept worth tracking: tool-layer policy gap. It is the space where identity has been proven but behaviour has not been controlled, and it will define how MCP governance matures.

Identity alone cannot express business-boundary rules: organisations already rely on contextual constraints such as tenant boundaries, operating windows, and destructive-action approvals. MCP exposes the limits of treating authentication as the end state, because agent calls can be syntactically valid while still violating business intent. The field should view this as a shift from login-centric control to request-centric governance, with direct implications for IAM, PAM, and application security.

Current MCP deployments are exposing an authorisation model mismatch: the protocol makes tool invocation feel like ordinary API traffic, but the security consequence is closer to delegated execution. That means existing IAM patterns need to be evaluated for whether they govern action, context, and data flow rather than only session establishment. Practitioners should expect this mismatch to drive new policy layers at the MCP gateway and inside downstream services.

From our research library:

What this signals

Tool-layer policy gap: MCP exposes a governance boundary that many IAM programmes do not yet model. The request is authenticated, but the action is still ungoverned unless teams evaluate tool choice, arguments, and response content together. That shifts the practical control point from login to authorised execution.

MCP also reveals how quickly delegated execution can outrun conventional access assumptions. If an agent can reach a repository tool, a customer lookup, or an operational workflow simply because the session is valid, then the programme is already governing identity at the wrong layer. Teams need policy enforcement that understands context, not just principal.

MCP tool calls sit close to the boundary where IAM, PAM, and application security converge. The right programme response is to treat tool invocation as a governed event, with explicit checks for action scope, tenant scope, and data egress before the call is forwarded.

For practitioners

  • Define tool-specific policy boundaries Map every exposed MCP tool to explicit allow and deny rules based on role, resource, action, and operating context. Do not rely on the user's authenticated session as proof that the agent should be able to invoke the tool.
  • Constrain destructive and cross-boundary actions Block or require explicit approval for tools that transfer funds, export data, revoke access, or cross tenant boundaries, even when the caller is authenticated. Treat those actions as separate governance events, not normal tool calls.
  • Inspect tool arguments before execution Scan tool inputs for prompt injection, malicious payloads, unexpected identifiers, and unsafe commands before forwarding them to backend systems. Use content inspection as a control point, not just logging after the fact.
  • Filter sensitive tool responses Redact or block credentials, personal data, and internal documents before tool output reaches model context or logs. Response-path inspection reduces the chance that sensitive material is re-emitted by the agent or reused in later prompts.

Key takeaways

  • MCP shifts the security question from who authenticated to what the agent is allowed to do with that authentication.
  • Without tool-level policy, a valid token can still drive overbroad tool use, cross-boundary data access, and destructive operations.
  • The control model has to include authorisation and content inspection at the tool layer, not just user login and credential hygiene.

Key terms

  • MCP Tool-Level Authorisation: MCP tool-level authorisation is the ability to permit or deny individual methods inside an MCP server instead of granting access to the whole service. This matters because different tools can carry very different risk, and agentic systems often need fine-grained boundaries that traditional API controls do not provide.
  • Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
  • Tool-layer Policy: Rules that evaluate an agent's requested action before the action is forwarded to a backend service. In MCP environments, tool-layer policy is the missing bridge between identity proofing and safe execution because it can apply context, resource scope, and action sensitivity.
  • Response-path Inspection: The process of examining data coming back from a tool before it enters model context, logs, or downstream outputs. This matters in MCP because responses can contain sensitive information that is otherwise invisible to identity controls and can be re-emitted by the agent later.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on September 2, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org