Notifications
Clear all
Topic starter
22/06/2026 9:55 am
TL;DR: MCP gateways can authenticate and route AI agent traffic, but Linx Security argues that tool-level policy, lifecycle governance, and human attribution are still required to control what agents can do inside enterprise systems. Without those controls, agents can outrun IAM, leaving no defensible audit trail or offboarding path for the person behind them.
NHIMG editorial — based on content published by Linx Security: What Is an MCP Gateway? Identity Security for AI Agents
By the numbers:
- 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025.
Questions worth separating out
Q: How should security teams govern AI agents that use MCP gateways?
A: Security teams should govern MCP-connected agents as identities, not just as traffic.
Q: Why do MCP gateways still leave identity risk in place?
A: Because authentication and routing do not solve scope, accountability, or lifecycle.
Q: What breaks when MCP governance stops at the server level?
A: Server-level governance collapses different tool risks into one access decision, which makes least privilege too coarse to be useful.
Practitioner guidance
- Map MCP tools to fine-grained access profiles Break each MCP server into its constituent tools and actions, then assign permissions by role, team, and task instead of granting broad server access.
- Link agent access to human ownership and lifecycle events Record the human sponsor for each agent, then revoke or review the agent when that person's role changes or they leave.
- Enforce inspection before tool execution Configure the gateway to approve or block tool calls inline before the action runs, rather than relying on post-execution logs.
What's in the full article
Linx Security's full article covers the operational detail this post intentionally leaves for the source: it explains how the MCP gateway is positioned inline, how policy decisions are applied in practice, and how the vendor says the identity layer ties into existing governance.
- Detailed explanation of the gateway architecture between AI clients and MCP servers
- Vendor examples of tool-level policy enforcement and inline inspection flow
- Expanded FAQ content on authentication, authorisation, and audit logging
- Implementation framing for connecting agent lifecycle management to identity governance
👉 Read Linx Security's analysis of MCP gateway governance for AI agents →
MCP gateways and identity blind spots: what teams are missing?
Explore further
22/06/2026 10:34 am
MCP gateway control without identity context is governance theatre. A gateway can mediate traffic, but it cannot tell you who the agent is acting for, whether the agent's scope is still valid, or whether the access still matches the sponsor's role. That means organisations may believe they have control while the real risk sits in the gap between authentication and accountable authorisation. Practitioners should treat that gap as an identity design failure, not a logging issue.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when an AI agent acts on behalf of an employee?
A: Accountability should remain with the human sponsor, but only if the programme preserves that linkage in policy, logs, and lifecycle records. The agent is the executor, but the identity programme must still answer who authorised it, why it was granted access, and when that access should end. Without that chain, investigations stall.
👉 Read our full editorial: MCP gateway governance needs identity context, not just routing
