MCP server security needs policy control beyond user authentication

At a glance

What this is: This is an analysis of why MCP security cannot rely on user authentication alone, and its key finding is that tool execution needs policy checks and content inspection.

Why it matters: It matters because IAM teams now have to govern agent-mediated access to repositories, customer data, workflows, and even financial actions without assuming the user’s token answers every authorisation question.

👉 Read Highflame's analysis of MCP security beyond user authentication

Context

MCP turns AI agents into active requestors inside production systems, which means the security problem is no longer just authentication. The primary governance gap is that a valid user token does not tell you whether the agent should be allowed to select a given tool, pass a given argument, or execute a high-risk action at that moment. In other words, the control plane is still thinking in user terms while the workload is behaving like a non-human identity.

That mismatch is familiar to identity teams working on service accounts, API keys, and workload access, but MCP makes it easier to overlook because the request appears user-authenticated. The article’s main point is that safe deployment requires identity, policy, and inspection to work together. For readers exploring agent governance, the OWASP Agentic Applications Top 10 is a useful external reference point, while the OWASP NHI Top 10 remains relevant for the underlying non-human identity patterns.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why do authenticated agents still create security risk in MCP environments?

A: Authenticated agents still create risk because authentication only proves that a subject entered the system. It does not prove that the next tool call, data access, or transaction is still allowed under the original delegation. That gap becomes dangerous when agent behaviour changes across tools or sessions.

Q: What are the signs that MCP session controls are failing?

A: Warning signs include permissions carrying over between sessions, inconsistent approval behaviour, and tool calls appearing in an order that does not match the intended workflow. You should also watch for reuse of stale tokens, approvals that were granted once and silently reused, and activity that exceeds the user’s original scope without a fresh consent event.

Q: What should organisations do immediately when an MCP tool can modify data or infrastructure?

A: Organisations should require an explicit deny-by-default rule for high-risk tools and then add approval or step-up checks before any destructive or infrastructure-changing action can run. That should be paired with argument inspection and response filtering so a valid agent session cannot silently convert into a high-impact change operation.

Technical breakdown

Why user authentication is not enough for MCP tool execution

In MCP, a user may authenticate successfully while an agent chooses the actual tool and arguments at runtime. That creates a separation between subject identity and action intent. Authentication proves who initiated the session, but it does not determine whether the requested tool, resource, or timing fits organisational policy. This is why an agent can appear legitimate while still exceeding intended scope. The technical issue is not token validity. It is that the downstream service receives a request with enough identity context to pass transport checks, but not enough authorisation context to constrain autonomous tool choice.

Practical implication: introduce policy decisions at tool execution time, not just at session authentication time.

Policy evaluation for tool choice, arguments, and context

A secure MCP design needs a policy layer that evaluates principal type, tool name, resource scope, and contextual constraints before forwarding a request. This is closer to zero trust authorisation than to traditional API gateway allow-listing. The important shift is that the system must inspect not only whether a request is authenticated, but also whether the action is appropriate for that principal and that business context. This becomes especially important when agents can call tools that were never intended for autonomous execution, such as data export, fund transfer, or administrative changes.

Practical implication: define allow and deny rules for agent tool use, with explicit treatment for destructive or sensitive actions.

Inspection of tool arguments and responses

MCP also creates a content-risk problem because model output, retrieved text, and tool responses can all become security inputs. Prompt injection can appear inside a document or webpage and influence the agent to call a specific tool with a crafted payload. On the way back, sensitive data can leak into prompts, logs, or model context unless the response is inspected and filtered. This is why the article frames inspection as a separate control layer. Authentication tells you the request came from a valid session. Inspection tells you whether the payload itself is safe.

Practical implication: inspect both tool inputs and outputs for injection, exfiltration, and unsafe payload patterns before execution or reuse.

NHI Mgmt Group analysis

Identity authentication is the wrong control boundary for MCP. MCP requests can be user-authenticated and still be wrong, because the agent selects the tool and timing at runtime. That means the real boundary is tool authorisation, not session authentication, and the governance model has to move with the action surface. Practitioners should treat the authenticated user as only one input to the decision, not the decision itself.

Policy must describe the action, not just the principal. The article’s strongest technical point is that identity alone cannot express whether an agent may create a webhook, export data, or trigger a destructive workflow. That is a classic IAM problem, but MCP makes it visible at machine speed and with higher blast radius. The implication is that authorisation logic must understand principal type, action, resource, and context together.

Tool execution creates a new NHI governance surface. MCP tools behave like non-human identities with delegated authority, which means access scoping, tool-level denial, and argument inspection become first-class controls. This aligns with the OWASP NHI Top 10 and zero trust thinking because trust has to be continuously re-evaluated at the action layer. The practitioner takeaway is that agent access should be governed as a lifecycle, not a one-time integration.

Prompt injection and data leakage are part of the same control problem. The article correctly links tool input inspection with response redaction, because the attack path runs both directions through the same agent context. Once an agent can ingest untrusted content and emit tool calls or sensitive outputs, the security model has to cover both inbound manipulation and outbound disclosure. Teams should stop treating model context as a neutral transport layer.

Agentic MCP governance will converge on policy plus inspection. The pattern here mirrors cloud authorisation: authenticate first, then enforce context-aware policy, then inspect content before execution. That is the shape of durable governance for agent-mediated access. The field is moving toward action-scoped controls, and practitioners who keep treating MCP as a standard API integration will miss the actual risk surface.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which leaves most tool calls governed by authentication alone.
• For a broader control model, see OWASP Agentic Applications Top 10 for the agent-risk patterns that sit behind tool misuse and prompt injection.

What this signals

MCP governance is moving from integration security to action security. The critical change is not that agents can authenticate, but that they can now decide which tools to call inside real systems. That forces IAM, PAM, and NHI teams to treat tool execution as a governed event, not a passive API transaction. For a useful external control lens, compare your design against OWASP Top 10 for Agentic Applications 2026.

Tool permission scope is becoming the control that separates safe delegation from accidental privilege expansion. When an agent can choose among read, write, and administrative tools, the identity model has to follow the action path rather than the login path. This is where the NHI lifecycle starts to matter for agents as much as it does for service accounts. Teams should look at how agent approval, revocation, and logging would fit inside the same governance cadence they already use for the Ultimate Guide to NHIs.

Hard-coded secrets and weak scoping will remain the easiest failure mode. With 53% of MCP servers exposing credentials in configuration files and only 18% implementing tool permission scoping, the operational path is clear: secure identity, then constrain tools, then inspect content. That sequence is the minimum viable programme for any team building agent-mediated access at scale.

For practitioners

• Implement tool-level authorisation checks Evaluate every MCP call against principal type, tool name, target resource, and contextual rules before forwarding the request. Reserve high-risk actions such as transfers, exports, and administrative changes for explicit approval flows, not generic authenticated sessions.
• Separate user identity from agent authority Model the human user and the acting agent as distinct decision inputs so that delegated access can be narrowed without assuming the user token is sufficient. Apply different policies when the caller is an agent rather than a person.
• Inspect tool arguments before execution Scan payloads for prompt injection, SQL injection, shell commands, and other malicious patterns before backend systems receive them. Treat untrusted model output and external content as part of the attack surface, not as benign context.
• Redact sensitive data on the response path Filter tool outputs before they re-enter the model context or downstream logging systems so credentials, personal data, and internal documents do not leak through prompts or telemetry. This is especially important where agents handle customer records or repository content.

Key takeaways

• MCP security fails when authentication is treated as the authorisation decision for agent actions.
• Tool-level policy and payload inspection are now baseline controls for agent-mediated access to production systems.
• Teams that do not scope agent tools will inherit the same privilege problems NHI governance was created to prevent.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Agent-Mediated Access: Access to systems or data that is executed by an AI agent on behalf of a human user. The human may own the credentials, but the machine performs the actions, which creates delegated authority, audit complexity, and a need for identity controls that cover runtime behaviour as well as login events.

What's in the full article

Highflame's full analysis covers the operational detail this post intentionally leaves for the source:

• Examples of policy rules for tool execution, including principal type, action, and resource context.
• The inspection layer needed to catch prompt injection, malicious payloads, and unsafe tool responses.
• The practical distinction between user authentication and agent authorisation in MCP architectures.
• How teams can model destructive actions such as exports, admin changes, and transfers as governed workflows.

👉 Highflame's full article covers the policy model, inspection layer, and tool execution examples in more detail.

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.