MCP gateway security is an identity problem, not routing

At a glance

What this is: This is an analysis of why MCP gateway security fails when treated as a transport problem, with the key finding that effective control depends on identity resolution, intent evaluation, and tool sensitivity at call time.

Why it matters: It matters because IAM, NHI, and PAM teams need policy enforcement that can govern AI agent tool calls without relying on human-style sessions or standing trust assumptions.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Linx Security's analysis of MCP gateway identity and access control

Context

MCP gateway security is the control problem that appears when AI agents can call tools across systems without a stable human session behind every request. The article argues that the missing layer is not routing but identity, intent, and tool sensitivity enforced at call time across the existing IAM model.

For IAM and NHI programmes, the gap is familiar: when a tool call carries no durable principal, no native intent signal, and no sensitivity context, policy decisions become guesswork. That makes MCP a governance issue as much as an integration problem, especially once privileged tools enter the flow.

Key questions

Q: How should security teams govern AI agent tool calls in MCP environments?

A: Security teams should treat MCP tool calls as identity decisions, not transport events. Enforce principal-chain resolution, intent checks, and tool sensitivity at runtime, then evaluate each request against existing IAM and NHI policy rather than a separate proxy rule set. That keeps privileged actions accountable and auditable across the same governance model.

Q: Why do MCP gateways create new access control risks for IAM teams?

A: MCP gateways create risk because the protocol does not natively carry stable identity, explicit intent, or tool sensitivity. Traditional IAM assumes a session-bound principal at the front door, but agent tool calls often arrive without that structure, which makes authorisation decisions incomplete unless the gateway adds context.

Q: What breaks when AI agents can call privileged tools without context checks?

A: What breaks is the assumption that authentication is enough. A privileged tool call without identity resolution, intent validation, and sensitivity-aware policy can trigger writes, policy changes, or secret access that the control plane never meaningfully evaluated. The result is authorised transport with unauthorised business impact.

Q: How do organisations decide whether MCP belongs in IAM, PAM, or NHI governance?

A: MCP belongs across all three because it touches machine identity, privilege enforcement, and lifecycle controls at the same time. IAM provides the principal model, PAM governs high-risk tool actions, and NHI controls the credentials and service identities the gateway may inject. The right approach is integrated policy, not separate ownership silos.

Technical breakdown

Identity resolution for MCP tool calls

An MCP gateway cannot rely on the client connection alone. It has to resolve the full principal chain behind the call, including the initiating human, service account, or upstream agent, and then map that chain to entitlements already governed in the identity graph. Without that step, the gateway sees an action but not an accountable identity. In practice, this is where human IAM assumptions break down first, because the protocol exposes a tool request without the session semantics that traditional access control expects.

Practical implication: enforce principal-chain resolution before any tool invocation reaches a privileged backend.

Intent evaluation and tool sensitivity

The article’s key technical point is that access control for MCP must evaluate why a call is being made, not only whether the caller is authenticated. Intent can be inferred from the prompt, the agent mission, and the action requested, while tool sensitivity classifies whether a call is read-only, policy-changing, or credential-accessing. That combination turns tool use into a policy decision rather than a simple proxy event. The important shift is that the same tool can be acceptable in one context and high-risk in another.

Practical implication: bind every tool to a sensitivity tier and compare it against declared mission context at runtime.

Gateway-mediated credential injection and JIT access

The credential layer is where many MCP deployments quietly fail. If secrets are hardcoded into tool definitions or injected directly by the agent, the gateway loses control over who used the credential, when it was used, and whether it should still exist after the call. Gateway-mediated credential injection preserves that control by fetching credentials under the caller’s entitlements and issuing time-bound access at invocation time. That is JIT access applied to machine-to-machine and agent-mediated flows, not a separate AI pattern.

Practical implication: move secrets retrieval into the gateway so credentials are never exposed to the agent layer.

NHI Mgmt Group analysis

Authentication theater is what happens when teams secure the MCP transport but not the identity decision. The article is correct that proxying and logging a tool call do not create real control if the gateway cannot resolve the actor, interpret intent, and judge tool sensitivity. In NHI terms, the security boundary moved, but the policy model did not. The practitioner conclusion is straightforward: if the gateway cannot make the access decision, it is only forwarding risk.

Tool-level authorisation must extend the existing identity graph, not sit beside it. The article’s strongest architectural point is that a tool is not a static resource, but an action whose risk changes with context. That means permissions models built for people and service identities need to evaluate the invocation path, not just the destination system. The practitioner conclusion is that MCP governance has to inherit existing IAM and NHI policy logic rather than create a parallel control plane.

Gateway-mediated credential injection is the difference between governed invocation and invisible credential use. Hardcoded or agent-injected credentials remove the enforcement point from the gateway and turn the call path into a blind spot. This is where the named concept matters: identity blast radius expands whenever the credential outlives the invocation that needed it. The practitioner conclusion is to treat credential visibility as part of the control surface, not an implementation detail.

JIT access becomes meaningful only when it is invocation-scoped and context-aware. The article shows why standing credentials for tools create persistence that agentic workflows do not need. That persistence is a governance assumption from human-paced systems, and it fails when the call itself is the unit of work. The practitioner conclusion is that access duration, not just access scope, must be part of the policy model.

MCP security is converging with NHI governance rather than replacing it. The same problems show up here that already define machine identity risk: visibility gaps, entitlement drift, secret handling, and auditability. The difference is that AI agents make those weaknesses operationally immediate because tools can be called at runtime without human review. The practitioner conclusion is to fold MCP into existing NHI governance rather than isolate it as a new domain.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that remediation windows stay wide even after exposure is known.
• That is why the governance lens extends beyond MCP, as 52 NHI Breaches Analysis shows how exposed credentials and missing offboarding repeatedly turn access into persistence.

What this signals

Identity blast radius: the useful concept here is not just whether a tool can be called, but how far a compromised identity can reach once the gateway starts injecting credentials on its behalf. That makes tool sensitivity, entitlement scope, and invocation context part of the same control surface, which is exactly how modern NHI programmes should model machine access.

With only 5.7% of organisations able to see all service accounts, per the Ultimate Guide to NHIs, MCP governance will fail in any environment that cannot already inventory non-human principals cleanly. The next control gap will not be the protocol itself, but the inability to prove which identity was allowed to act.

MCP will push identity teams toward runtime policy, but it will also expose where current IAM programmes still assume static users and long-lived credentials. Expect more pressure to unify secrets, PAM, and workload identity controls around the same enforcement point rather than keep them as separate operational towers.

For practitioners

• Resolve the full principal chain at every tool call Map the initiating human, service account, and agent context before authorising execution. If the gateway cannot explain who is behind the request, deny the call and log the unresolved chain as a governance exception.
• Classify tools by sensitivity before exposing them to agents Assign read, write, policy, and credential-access tiers to every tool, then require stronger justification for higher tiers. Keep the classification in the policy layer so privileged tools cannot be called on equal footing with low-risk lookups.
• Move credential retrieval into the gateway Pull secrets only at invocation time under the caller’s entitlements, and inject them without exposing the credential to the agent layer. This preserves auditability and prevents persistent downstream reuse.
• Bind intent checks to the declared mission of the agent Compare the originating prompt and mission statement with the requested action, and flag calls that drift outside the declared purpose. Use that mismatch as a policy signal, not just a monitoring event.
• Reuse the existing identity graph for MCP enforcement Evaluate agent tool calls against the same permissions model used for human and non-human identities rather than building a separate access silo. That keeps policy consistent and reduces gaps between ordinary app access and tool execution.

Key takeaways

• MCP security fails when teams stop at routing and ignore identity, intent, and tool sensitivity.
• Gateway-mediated credential injection and JIT access are practical only when the gateway remains the enforcement point.
• Existing IAM and NHI policy layers can govern MCP, but only if they evaluate the principal chain and invocation context at call time.

Key terms

• MCP Gateway: An MCP gateway is an enforcement point that mediates AI agent tool calls across systems. In practice, it should do more than proxy traffic: it should resolve identity, check intent, classify tool sensitivity, and decide whether the invocation is allowed under existing access policy.
• Tool Sensitivity: Tool sensitivity is the risk level assigned to an action a tool can perform, such as read-only access, policy changes, or credential access. It helps identity teams treat not all MCP calls as equal and apply stricter controls where the business impact is higher.
• Gateway-Mediated Credential Injection: Gateway-mediated credential injection means the enforcement layer retrieves and inserts the needed credential at call time under the caller’s entitlements. It keeps secrets out of the agent layer, preserves auditability, and makes the credential’s use visible to governance controls.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream capability exposed when one identity is misused. For MCP and AI agents, the concept is driven by invocation scope, credential lifetime, and the sensitivity of the tools the gateway allows.

What's in the full article

Linx Security's full blog post covers the operational detail this post intentionally leaves for the source:

• A practical account of how the gateway resolves identity, intent, and tool sensitivity before execution.
• Details on credential injection patterns for privileged tools and how the enforcement point is kept in the gateway.
• The decision logic used to evaluate tool calls against existing permissions instead of a separate policy silo.
• The logging fields used to make every allow or deny decision auditable in downstream reviews.

👉 Linx Security's full post covers the principal-chain model, runtime policy checks, and gateway credential handling.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.