TL;DR: As MCP becomes the default tool-calling layer for agents, organisations need gateways that can enforce tool-level policy, short-lived identity assertions, session-aware controls, and auditable decisions. Pomerium’s analysis argues that traditional API gateways miss the semantic and governance gaps that agentic workflows create.
At a glance
What this is: This is a comparative analysis of five agentic gateways for securing MCP tool calls, with the key finding that agentic workloads need tool-level, session-aware controls rather than generic API protection.
Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent behaviour at runtime, not just authenticate a client or proxy a request.
By the numbers:
- Recent research uncovered 1,862 internet-exposed MCP servers with zero authentication, a stark reminder that traditional API security practices are insufficient for agentic workflows.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
- Only 5.7% of organisations have full visibility into their service accounts.
👉 Read Pomerium's analysis of the top agentic gateways for securing MCP tool calls
Context
MCP security is the problem space here. The protocol gives agents a standard way to call remote tools over JSON-RPC, but once an agent can choose tools, pass parameters, and chain calls across a session, the old assumptions behind API gateways start to fail. That is why MCP tool calls now need identity-aware policy, not just transport-layer controls.
The governance gap is straightforward: a request from an agent is not the same as a request from a human or a service account. Security teams need to know which tool was called, which identity was used, what context justified it, and whether the action should persist across multiple steps. For agentic AI programmes, that makes the gateway layer part of identity governance, not just infrastructure plumbing.
Key questions
Q: How should security teams govern MCP tool calls in agentic systems?
A: Security teams should govern MCP tool calls at the tool and method level, not just at the server or network layer. The gateway should enforce identity, context, and policy before each call, then log the decision with enough detail to support audit and investigation. Without that, agentic workflows remain only partially governed.
Q: Why do MCP-based agents need stronger controls than traditional API traffic?
A: MCP-based agents can chain tool calls, change context during a session, and pass parameters that affect downstream systems. Traditional API controls often see only a request and response, not the task intent or the semantic meaning of the tool action. That makes session-aware authorisation and richer logging necessary.
Q: What breaks when agents hold long-lived credentials for tool access?
A: Long-lived credentials expand the blast radius of agent compromise because the process can reuse those secrets outside the intended task. If the agent is hijacked, an attacker can call downstream systems until the secret is revoked. Short-lived assertions reduce that exposure by narrowing credential usefulness to a specific runtime context.
Q: How do teams evaluate whether an agentic gateway is actually working?
A: Teams should look for three signals: tool-level denial of unsafe methods, preserved session context across multi-step workflows, and audit logs that show who or what approved each call. If the gateway only blocks whole servers or records generic traffic, it is not governing agentic behaviour at the right granularity.
Technical breakdown
Why MCP changes the gateway problem
MCP is not just another API wrapper. It defines a structured relationship between agents, servers, tools, and methods, which means policy must operate at the tool level rather than the host or path level. JSON-RPC over HTTP(S) also creates a call pattern that is easy to proxy but hard to govern if the gateway cannot understand session context, tool intent, and parameter sensitivity. In practice, a gateway that only rate-limits or authenticates server access still leaves method misuse, prompt injection, and over-broad authorisation unresolved.
Practical implication: treat MCP as a distinct control plane and require tool-level policy, not generic API controls.
Identity assertions versus long-lived credentials
A core design choice in MCP security is whether the agent or the gateway holds credentials. If the agent carries long-lived secrets, compromise of the process can expose downstream systems far beyond the original task. Assertion-based designs reduce that risk by replacing persistent secrets with short-lived, signed identity claims that the server can validate at runtime. That shifts the trust boundary from secret custody to assertion verification, which is a stronger fit for agentic workflows and zero-trust access models.
Practical implication: prefer architectures that remove persistent secrets from the agent runtime.
Why session-aware authorisation matters
Agentic workflows are sequential, not single-shot. A tool call today may be valid only because a prior step established user intent, task scope, or approval state. If every request is evaluated in isolation, the gateway cannot distinguish normal task progression from scope drift, recursive tool use, or parameter escalation. Session-aware policy allows enforcement to reflect the workflow rather than the individual request, which is essential when agents chain multiple calls to complete a task.
Practical implication: require policies that preserve context across multi-step agent sessions.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP security is now an identity governance problem, not an API management footnote. The article shows that agentic gateways are needed because MCP tool calls expose a control surface that traditional gateways were not built to understand. Tool identity, session context, and delegated actions now sit inside the trust decision, which means IAM and NHI teams have to govern the call path as well as the credential. Practitioners should treat MCP as an identity enforcement layer.
Tool-level authorisation is the named concept that separates real agent security from generic proxying. A gateway that can only approve or deny whole servers still leaves method-level misuse untouched, especially when an agent has access to both safe and dangerous tools in the same service. The article makes clear that semantic policy is the important change, because MCP exposes tools as first-class objects. Practitioners should use tool-level scope as the baseline question when evaluating gateway controls.
Identity assertions reduce secret exposure, but they also change the trust model for the whole workflow. By injecting short-lived assertions instead of handing agents persistent credentials, the gateway shifts responsibility from secret storage to runtime validation. That aligns with zero-trust thinking, but it also means the organisation must trust the assertion issuer, the expiry model, and the downstream verification path. Practitioners should re-examine where credential custody really belongs in agentic architectures.
Session-aware control is the difference between governing a request and governing an agent. The article’s focus on multi-step workflows shows why a single-call authorisation model misses the real risk. Once an agent can sequence actions, policy must consider the chain, not just the step. Practitioners should assess whether their current gateways can preserve task context across calls or merely log them after the fact.
Identity blast radius: the article’s central lesson is that the dangerous unit is no longer the API key alone, but the combination of agent identity, tool scope, and session state. When those three combine without fine-grained enforcement, compromise or misuse spreads across downstream systems faster than traditional review cycles can respond. Practitioners should use blast-radius reduction as the design test for agentic gateway selection.
From our research:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, or revealing access credentials.
- For a broader control baseline, read OWASP Agentic Applications Top 10 for the risks that gateway policy needs to contain.
What this signals
Tool-level governance is becoming the practical boundary for agentic AI programmes. As agents move from chat to tool execution, the question is no longer whether they can act, but whether every action is bound to a scoped identity, a verifiable context, and an auditable decision. Teams that already manage service accounts and privileged automation should recognise the pattern: the same governance problem now applies to agentic workflows, only faster.
Session context will become the differentiator between a proxy and a control point. A gateway that cannot carry approval state across multiple calls will only document risk after the fact. That is why agentic programmes need to align gateway design with zero-trust enforcement and identity governance, not treat observability as a substitute for control.
Identity blast radius matters because 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. For agentic systems, that legacy exposure pattern combines badly with dynamic tool use, making credential custody and downstream authorisation inseparable problems. Practitioners should plan for agent-facing controls that assume secrets will be targeted wherever they still exist.
For practitioners
- Map MCP tools to explicit policy boundaries Inventory each MCP server, then separate safe, sensitive, and destructive methods into distinct authorisation groups so policy can deny tool misuse without blocking the whole server.
- Remove persistent secrets from agent runtime Prefer short-lived assertions or delegated tokens so the agent process never stores long-lived credentials that can be reused outside the task boundary.
- Test session-aware policy enforcement Validate that the gateway can carry approval state, prior user intent, and multi-step workflow context across several tool calls before the session closes.
- Require semantic audit logs for tool calls Make sure logs record the agent identity, the specific method invoked, parameters, and the allow or deny decision so investigations can reconstruct why an action happened.
Key takeaways
- MCP tool calls turn agentic AI into an identity governance problem because policy must now follow the tool, the session, and the identity together.
- The article’s core control insight is that generic API gateways are not enough when agents can choose methods and chain actions within one workflow.
- Practitioners should prioritise tool-level authorisation, short-lived assertions, and semantic audit logs as the minimum viable gateway pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers tool misuse, prompt injection, and agent identity risks in MCP workflows. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | MCP agents behave as non-human identities that need explicit governance and scoped access. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | The article’s default-deny, assertion-based model maps directly to continuous verification. |
Classify MCP agents as NHIs and enforce least privilege, rotation, and credential containment.
Key terms
- Agentic Gateway: An agentic gateway is a policy enforcement layer placed between AI agents and the tools they call. It evaluates identity, scope, and context before allowing access, then records the decision. In practice, it turns agent execution into something security teams can govern rather than merely observe.
- MCP Tool-Level Authorisation: MCP tool-level authorisation is the ability to permit or deny individual methods inside an MCP server instead of granting access to the whole service. This matters because different tools can carry very different risk, and agentic systems often need fine-grained boundaries that traditional API controls do not provide.
- Identity Assertion: An identity assertion is a short-lived, signed claim that proves an actor’s identity or delegated authority at runtime. For agentic systems, assertions reduce the need for long-lived secrets inside the agent process and shift trust to verification, expiry, and issuer integrity.
- Session-Aware Policy: Session-aware policy evaluates access decisions using the state of an entire workflow, not just one request. In agentic environments, this is essential because a tool call may be safe only in the context of prior approval, prior input, or the current task boundary.
Deepen your knowledge
MCP tool-level authorisation and session-aware gateway design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic workflows or reviewing an existing gateway stack, it is worth exploring.
This post draws on content published by Pomerium: Top 5 Agentic Gateways for Securing MCP Tool Calls in 2026. Read the original.
Published by the NHIMG editorial team on 2026-04-14.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org