Notifications
Clear all
Topic starter
09/07/2026 3:26 pm
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.
NHIMG editorial — based on content published by Linx Security: AI Access Control, What We Learned Building an MCP Gateway: It's Not a Routing Problem
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.
Questions worth separating out
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.
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.
Q: What breaks when AI agents can call privileged tools without context checks?
A: What breaks is the assumption that authentication is enough.
Practitioner guidance
- Resolve the full principal chain at every tool call Map the initiating human, service account, and agent context before authorising execution.
- 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.
- 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.
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.
👉 Read Linx Security's analysis of MCP gateway identity and access control →
MCP gateway security: what IAM teams are missing at tool call time?
Explore further
09/07/2026 3:45 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP gateway security is an identity problem, not routing
