Kong MCP gateway shows where AI agent access control breaks

At a glance

What this is: This is Kong's technical breakdown of MCP gateway and server patterns, showing that protocol mediation simplifies AI tool access while leaving key authorization and governance decisions exposed.

Why it matters: It matters because IAM and platform teams now need to govern AI agent tool access as a distinct access plane, not just another API integration, especially where OAuth, policy enforcement and audit trails intersect.

Context

Model Context Protocol gives AI applications a standard way to discover tools, resources and prompts through a client-server model. In Kong's framing, the governance gap is not whether agents can connect, but whether those connections can be mediated, authorised and observed without creating a new trust boundary problem for AI agent access.

That matters for identity programmes because MCP sits between AI apps and downstream APIs or MCP servers, which means access decisions are no longer limited to human users or service accounts. The control question becomes how to enforce OAuth-backed access, tool-level mediation and session traceability when the actor is an AI agent using protocol-native calls.

Key questions

Q: What breaks when MCP access is built on shared API tokens?

A: Shared API tokens break accountability first. Once one token is reused across people or scripts, the action trail no longer maps cleanly to a single identity, and revocation becomes blunt rather than targeted. The result is access that may still work after the original user’s intent has changed.

Q: Why does on-behalf-of OAuth matter for AI agent security?

A: It prevents the agent from directly holding the downstream service token, which reduces the blast radius if the agent logic is compromised. The server can retrieve scoped credentials on the user's behalf while keeping the sensitive token outside the agent runtime. That is a stronger control boundary than passing secrets into the model or its tool layer.

Q: How should security teams govern MCP gateway logs and telemetry?

A: They should log the identity context, tool invoked, validation result and outcome for each request, then review those records as entitlement evidence. That is the difference between knowing a gateway was used and knowing whether an AI agent used it within policy.

Q: What is the difference between protocol mediation and access governance for MCP?

A: Protocol mediation moves messages between client and server, while access governance decides whether the call should happen at all. A gateway can translate MCP traffic perfectly and still fail as a control if it does not enforce scope, audience, revocation and audit requirements.

Technical breakdown

How MCP client-server mediation changes access control

MCP separates the host, client and server roles so an AI application can request context and tools through a standard protocol rather than direct ad hoc integration. That improves interoperability, but it also moves control enforcement into the gateway or server layer. The important detail is that the MCP server exposes tools, resources and prompts, so authorization has to happen at the point where a client invokes a specific capability, not only at the network edge. In practice, this is an access brokerage problem, not just an API routing problem.

Practical implication: Design authorization around tool invocation and context scope, not only around network reachability or API exposure.

Why OAuth 2.1 and token introspection matter for MCP

The article shows Kong using OAuth 2.1 for MCP server access and token introspection to validate the caller before a tool runs. That matters because MCP clients may operate continuously across sessions, and the gateway needs a fresh decision about whether the token is valid, which audience it applies to, and whether the caller still matches the intended trust context. Without that validation layer, the gateway becomes a simple transport bridge rather than an access control point.

Practical implication: Treat token validation as part of the control plane for AI tool access, not as a decorative authentication layer.

Why MCP-specific observability is part of identity governance

Kong extends Prometheus metrics for MCP-specific telemetry, which is important because identity governance fails when teams cannot see which tools are being called, by whom and under what pattern. For AI agents, audit data must include protocol-level events, not just generic gateway logs, because the risk often sits in tool selection and invocation sequence rather than in raw connectivity. That makes observability part of entitlement governance, especially when multiple MCP servers sit behind a shared gateway.

Practical implication: Capture tool-level telemetry that can be reviewed against agent identity, authorization scope and unusual invocation patterns.

Threat narrative

Attacker objective: The objective is to use delegated AI tool access to reach data or actions beyond the agent's intended authorization scope.

1. Entry occurs when an AI application or MCP client connects to a gatewayed MCP service and begins requesting tools or resources through the protocol.
2. Escalation occurs if the gateway does not enforce token validation, tool-level authorization or scope checks tightly enough to distinguish legitimate from overbroad access.
3. Impact occurs when the agent can call exposed tools or upstream APIs with privileges that exceed its intended operational boundary, expanding the blast radius of a single mis-scoped session.

Breaches seen in the wild

• 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.
• 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.

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

Protocol mediation does not solve identity governance by itself: MCP reduces integration chaos, but it does not answer who may invoke which tool, under what conditions, or with what revocation logic. The governance burden shifts from connection setup to runtime authorization and auditability. That makes the gateway an identity control point, not just an API transport layer.

MCP tool access creates a new entitlement object: A tool is not the same as an API route, because the calling context includes host, client, server and session state. That means access reviews must reason about tool exposure and invocation authority, not only about static credentials or service-to-service trust. Practitioners should treat each tool surface as governed entitlement, not as invisible plumbing.

Ephemeral agent access changes the review problem: When AI systems request, use and discard tool access quickly, conventional periodic review becomes less informative. The useful control is not simply whether access exists, but whether the gateway can prove the right identity, the right audience and the right scope at invocation time. That shifts governance from post-hoc certification toward runtime policy enforcement.

MCP-specific telemetry is now a governance requirement: If teams cannot see tool calls, token validation outcomes and invocation patterns, they cannot govern agent behaviour or reconstruct misuse. The observability layer therefore becomes part of identity assurance, especially where multiple servers and upstream APIs share the same mediation tier. The practitioner takeaway is that auditability must be designed into the protocol path, not added later.

Gateway centralisation can either reduce or concentrate risk: Central mediation simplifies control enforcement, but it also creates a high-value decision point where a single misconfiguration can affect many AI tool paths at once. That is the right place for policy, but only if teams also assume the gateway will become a concentration point for abuse. The implication is to govern the gateway like a privileged identity plane, not a convenience proxy.

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: AI Agent Authorisation Guide

What this signals

Tool invocation is the new review unit: Access governance for AI agents will increasingly move from static credential checks to per-call authorization evidence. That matters because the control objective is not simply to authenticate an agent, but to prove the agent was allowed to invoke that specific tool at that moment.

MCP gateways also make identity blast radius more visible. When a single mediation layer fronts multiple AI applications and servers, one weak policy or mis-scoped token can expose many paths at once, so teams need to treat shared gateway design as a privilege concentration problem rather than a routing convenience.

According to State of Secrets Sprawl 2026, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone. That figure reinforces a simple point: standardisation without governance can still widen the exposure surface for agent-access infrastructure.

For practitioners

• Define tool-level authorization boundaries Map each MCP tool to a discrete approval and entitlement rule so access is granted per capability, not per broad gateway route.
• Validate token audience and scope at invocation Require the gateway to verify OAuth token validity, audience and scope before forwarding any MCP request to a server.
• Log MCP-specific identity telemetry Capture host, client, tool name, token validation result and request outcome so investigations can reconstruct agent activity precisely.
• Review shared gateway blast radius Inventory which AI apps, MCP servers and upstream APIs share the same mediation tier and identify where a single misconfiguration would overexpose multiple paths.

Key takeaways

• MCP standardises how AI agents reach tools, but the real governance problem is still who may invoke what, under which context and with what proof.
• A shared gateway can reduce integration sprawl while also concentrating failure if OAuth scope checks, token validation or audit logging are weak.
• For IAM teams, the practical shift is from managing connectivity to governing runtime authorization, telemetry and blast radius for agent tool access.

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.
• Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.
• Token Introspection: Token introspection is the server-side check used to determine whether an opaque token is still active. It trades latency for authoritative revocation awareness and is especially useful when access decisions need to reflect current token status immediately.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.