TL;DR: MCP gateways that stop at routing and authentication leave blind spots around identity, intent, and tool sensitivity, according to Linx Security. The central issue is that existing IAM models assume stable principals and visible sessions, while agent tool calls often lack both, making access control theater.
At a glance
What this is: This is an analysis of why MCP gateway security fails when it is treated as a transport problem instead of an identity and authorisation problem.
Why it matters: It matters because IAM, PAM, and NHI teams need to govern tool calls by principal context, intent, and tool sensitivity, not just by whether a request can authenticate.
Context
MCP gives AI agents a standard way to invoke tools, but it does not natively solve who is behind a call, why it is being made, or how sensitive the target tool is. That creates an identity governance gap at tool-call time, where existing RBAC and session-based controls were not designed to reason about agent-driven actions.
In this model, the gateway becomes an enforcement point for non-human identity rather than a simple proxy. The article argues that the real security question is whether the organisation can evaluate the full identity context, the call intent, and the tool's risk at the moment of execution.
Key questions
Q: What fails when an MCP gateway only checks routing and authentication?
A: It leaves the organisation unable to evaluate who is really behind the tool call, why the call is happening, and how sensitive the target tool is. That creates a gap where technically valid requests can still trigger privileged actions without meaningful authorisation context. The result is control that looks present but cannot govern agent behaviour.
Q: Why do privileged MCP tool calls create more risk than normal API requests?
A: Because the protocol path can hide the human, service, or agent context that normally supports authorisation decisions. If the gateway cannot resolve the full principal chain and the intent behind the call, it cannot distinguish legitimate delegation from dangerous scope drift. That raises the risk of sensitive writes, secret access, and policy abuse.
Q: What signs show that an MCP access model is failing in practice?
A: The main signs are hardcoded tool secrets, runtime credential injection that bypasses secrets management, and tool calls that are allowed even when the prompt or mission does not fit the action taken. Those patterns show the gateway is proxying traffic rather than enforcing contextual authorisation. Governance is then happening after the fact, if at all.
Q: How should teams govern MCP at scale without overexposing tools?
A: Teams should govern MCP as a capability-based control plane, with explicit approval for server provenance, granular scoping for each tool, and monitoring that covers every request and response. The goal is to keep discoverability useful while preventing shared interfaces from becoming shared privilege.
Technical breakdown
Why MCP tool calls break front-door IAM assumptions
Traditional IAM assumes a stable principal, an established session, and a token that can be traced back to a person or service. MCP tool calls can arrive without a durable identity context, without a native intent field, and without built-in sensitivity metadata on the tool itself. That means the gateway cannot rely on the same access decision inputs that human-facing systems use. The architectural shift is from authenticating a caller to evaluating a delegated action in context, which is a different control problem entirely.
Practical implication: treat MCP as an enforcement layer for delegated actions, not as another authentication endpoint.
Gateway-mediated credential injection and JIT access
When credentials are hardcoded into tool definitions or injected directly by the agent, the secret either escapes governance or bypasses the visibility that secrets management depends on. Gateway-mediated credential injection changes the path: the gateway resolves the needed credential, checks the calling identity's entitlements, injects the secret at call time, and keeps it out of the agent layer. JIT access is what makes this operationally useful because the credential exists only for the specific invocation context, not as standing access attached to the tool.
Practical implication: bind credential issuance to the gateway and scope it to each invocation rather than maintaining persistent tool secrets.
Tool sensitivity must be evaluated alongside identity and intent
A read-only lookup and a privileged write to a secrets store are not the same risk, even when they use the same protocol path. The control failure appears when a gateway checks the caller but ignores whether the requested tool can modify policy, touch credentials, or access sensitive datasets. Linx Security's model ties tool sensitivity to identity resolution and intent evaluation so the policy engine can distinguish routine agent activity from scope drift. Without that third signal, the control layer can authorise technically valid but operationally dangerous tool calls.
Practical implication: maintain a tool sensitivity model and evaluate it before forwarding any privileged MCP action.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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
Identity context, not routing, is the core control plane for MCP. The article describes a delegated-action problem that existing IAM models were not built to solve: the system may know a client connected, but not who truly stands behind the tool call. That matters because the enforcement point has to reason about principal chains, not just sessions. Practitioners should treat MCP as a governance boundary where identity resolution becomes the first control.
Gateway-mediated credential injection is the only model that keeps secrets governable at tool-call time. Hardcoded credentials and direct agent injection both break the visibility that secrets governance depends on. Once the gateway owns issuance, the organisation can evaluate entitlements before exposing a credential and avoid persistent secret possession inside the agent path. The practical conclusion is that tool access must be mediated, not embedded.
Tool sensitivity creates the missing authorisation dimension for agentic workflows. The article correctly separates authentication from authorisation by showing that not every tool deserves the same policy treatment. A gateway that cannot distinguish a harmless lookup from a privileged write will authorise actions it cannot explain. The implication for IAM and PAM teams is that tool risk must be classified as a first-class control input.
Access review assumptions collapse when tool calls are transient and context-bound. Access review processes were designed for privileges that persist long enough to be observed, recertified, and removed. MCP-mediated calls can be narrow, contextual, and ephemeral, so the review artefact may never exist in a meaningful standalone form. That changes what governance can inspect, and it forces practitioners to move scrutiny toward issuance-time policy rather than retrospective certification.
Contextual policy enforcement is the point where NHI governance meets agentic access control. The article shows that NHI, IAM, and PAM are no longer separate conversations when AI agents invoke real tools. The same control layer must understand identity, intent, and tool sensitivity together or it will fragment into disconnected checks. Practitioners should treat MCP as a convergence point for non-human identity governance, not as a sidecar feature.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Tool-call governance now sits inside the identity plane. MCP gateways that only proxy traffic will not give IAM or PAM teams enough evidence to govern delegated actions. The operating model has to move toward call-time authorisation, where identity context and tool sensitivity are both evaluated before any credential is exposed.
Contextual credential issuance becomes the control that changes the blast radius. When a gateway issues time-bound credentials only for the approved invocation, the agent no longer carries reusable access into unrelated systems. That changes how practitioners should think about session scope, because the enforcement point is now the tool call itself, not the surrounding transport layer.
Identity blast radius: The useful concept here is the amount of downstream privilege a single agent action can activate if identity, intent, and tool sensitivity are not jointly governed. Once teams start measuring MCP access this way, they can see why routing-only designs create far more operational risk than their logs suggest.
For practitioners
- Define MCP gateway policy around identity, intent, and sensitivity Require every tool call to resolve the full principal chain, validate why the call is being made, and classify the tool before execution is allowed.
- Move credential delivery into the gateway path Replace hardcoded tool secrets and direct agent injection with gateway-mediated credential retrieval from the secrets store under the caller's entitlements.
- Scope access with just-in-time issuance Issue time-bound credentials for specific invocations so an agent session does not retain persistent access to downstream systems.
- Create a sensitivity model for MCP tools Rank tools by the actions they can perform, then require stronger contextual justification for privileged writes, policy changes, and secret access.
- Audit denied and allowed tool calls with full context Log the originating prompt, resolved identity, policy decision, and sensitivity tier so governance teams can explain why a call was blocked or allowed.
Key takeaways
- MCP security breaks down when organisations authenticate the client but fail to govern the delegated action behind the call.
- Gateway-mediated credential injection and time-bound issuance are the controls that keep tool access inside a visible governance boundary.
- Tool sensitivity, intent, and principal context have to be evaluated together or privileged agent actions will outpace existing IAM and PAM assumptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on MCP calls that lack a stable identity context at execution time. |
| NHI-05 — Overprivileged NHI | The article focuses on tool calls that can reach sensitive actions without sufficient contextual controls. | |
| NHI-07 — Long-Lived Secrets | Hardcoded credentials and standing tool secrets are a central failure mode described in the article. | |
| Recommendation — Use NHI-04 to require verifiable identity context before any MCP tool call is authorised. Apply NHI-05 to constrain MCP tools to the minimum access needed for each invocation. Eliminate long-lived MCP secrets and replace them with time-bound credential issuance. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-driven tool calls can abuse inherited privilege when the gateway lacks contextual enforcement. |
| Recommendation — Map MCP privilege decisions to ASI03 and block tool calls that exceed the actor's delegated scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential injection and JIT issuance depend on governable authenticator lifecycle. |
| AC-6 — Least Privilege | The article's core claim is that least privilege must be enforced at tool-call time, not assumed. | |
| Recommendation — Use IA-5 to manage credential issuance, rotation, and revocation for MCP-enabled access. Apply AC-6 to restrict MCP tool access to the narrowest effective entitlement set. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about evaluating authorisation context for delegated tool execution. |
| Recommendation — Align MCP gateway policy with PR.AA-05 so tool calls are authorised by context, not just connectivity. | ||
Key terms
- MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
- 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.
- 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.
- Identity context: The entitlement, ownership, and purpose information that explains why an action occurred and whether it was expected. For security operations, identity context turns raw alerts into decisions by showing which human or non-human identity acted and what it was allowed to do.
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.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org