Kong MCP gateway shows where AI agent access control breaks

At a glance

What this is: Kong’s technical breakdown explains how MCP Gateway can broker AI-to-tool traffic while enforcing OAuth-based control and protocol translation.

Why it matters: It matters because IAM, NHI, and agentic AI teams are now being asked to govern tool access, authorization, and observability at the protocol boundary rather than only at the application layer.

By the numbers:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Kong's technical breakdown of MCP Gateway and MCP server controls

Context

MCP is a protocol for connecting AI applications to tools, resources, and prompts through a client-server model. For identity teams, the key issue is not the syntax of the protocol but the trust boundary it creates for non-human access, especially when agents can call tools and consume context dynamically.

Kong’s post focuses on how its gateway mediates MCP traffic with OAuth 2.1 and protocol translation, which places authorization, routing, and observability at the center of agent governance. That is relevant wherever AI systems rely on reusable tools and shared infrastructure, because the same control plane may now need to handle both API clients and AI clients.

The governance question is broader than one vendor’s implementation: enterprises need a way to decide which tools an AI system may reach, how that access is authenticated, and how activity is audited after the fact. For most organisations, that is still a developing model rather than a mature operating practice.

Key questions

Q: How should security teams govern AI agents that access tools through MCP?

A: Security teams should govern MCP access the same way they govern other non-human identities, with explicit scopes, strong token validation, and complete audit trails. The gateway should decide which tools can be reached and which methods can run, while downstream systems should assume the caller is authenticated but still tightly bounded.

Q: When does MCP create more risk than it reduces?

A: MCP creates more risk when it standardises access but fails to narrow privilege, because the same convenience that improves integration can also enlarge the blast radius of a compromised or over-permissioned agent. Risk rises further when logging is too coarse to reconstruct which tool or method was used.

Q: What do teams get wrong about gateway-based AI access control?

A: Teams often assume a gateway alone solves the problem. In reality, the gateway only helps if it enforces identity-aware policy, preserves method-level visibility, and ties each token to a specific tool action. Otherwise it becomes a routing layer that obscures accountability instead of strengthening it.

Q: Who should own MCP authorization in an enterprise?

A: MCP authorization usually sits at the intersection of IAM, API security, and platform engineering, but the ownership model should be explicit. Identity teams should own authentication and policy standards, platform teams should own gateway enforcement, and application teams should own the tool inventory and business justification.

Technical breakdown

MCP client-server flow and tool exposure

MCP separates the host, client, and server roles so an AI application can request context and invoke tools through a standard interface. The server exposes tools, resources, and prompts, while the client maintains the session and exchanges JSON-RPC messages over a transport such as streamable HTTP. That structure makes tool access more modular, but it also means identity and authorization must be enforced consistently at the protocol edge rather than inside each downstream tool.

Practical implication: inventory every MCP-exposed tool as an access surface and apply policy at the gateway, not only inside the backing API.

OAuth 2.1 as the control plane for MCP authorization

Kong’s post places OAuth 2.1 and token introspection at the center of MCP access control. In practice, that means the gateway validates whether a consumer token is active and whether the caller is allowed to invoke the requested tool before the request reaches the server. This is the same core pattern IAM teams already use for federated access, but MCP makes the policy boundary more explicit because the caller is not necessarily a human and the action is not necessarily a simple API read.

Practical implication: align MCP authorization with existing federated identity controls so token validation, audience checks, and scope enforcement remain consistent.

Protocol translation changes the blast radius of tool access

The AI MCP Proxy plugin translates between MCP and HTTP, which lets existing APIs participate in an MCP workflow without rewriting every service. That simplifies adoption, but it also means the gateway becomes a control chokepoint for routing, telemetry, and policy enforcement across heterogeneous tool back ends. The security outcome depends on whether the translation layer preserves least privilege, enforces method-level restrictions, and records enough detail to support investigation after an agent action chain completes.

Practical implication: require per-tool and per-method logging at the translation layer so investigative evidence survives protocol conversion.

Threat narrative

Attacker objective: The objective is to turn legitimate tool connectivity into unauthorized data access or unintended system actions through overly broad delegated access.

1. entry: An AI application or MCP client reaches a tool through the gateway using a session and bearer token rather than direct unauthenticated access.
2. escalation: If authorization is too coarse, the caller can invoke tools or resources beyond the intended scope of the session or workflow.
3. impact: The agent can trigger downstream API actions, expose data, or amplify access through repeated tool calls and shared credentials.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 access control is becoming a non-human identity problem, not just an integration problem. Once an AI application can invoke tools through a gateway, the real governance unit is no longer the application alone but the authenticated, auditable, non-human caller. That changes how IAM, PAM, and API security teams divide ownership. The implication is that MCP traffic needs identity policy, not only transport policy.

Protocol mediation creates a new identity chokepoint that can either improve or obscure governance. A gateway that translates between MCP and HTTP can centralise enforcement, but it can also hide what the agent actually did unless logging is method-specific and identity-aware. Kong’s model shows why the boundary matters: the same control point can become the only place where tool use, token scope, and request intent are all visible. Practitioners should treat that boundary as part of the identity architecture.

Tool invocation without clear scope controls turns agentic access into standing privilege by another name. When an AI system can repeatedly call tools under a long-lived token or broad audience, the risk is not simply misuse but persistent authority to act inside a session. That is the same structural problem NHI teams have seen with over-broad service credentials, now expressed through MCP. The implication is that agent access must be governed as an entitlement lifecycle, not as a one-time onboarding event.

Named concept: protocol-bound identity blast radius. MCP concentrates tool access, identity validation, and telemetry into a narrow mediation layer, which means mistakes in token scope or logging can expand the impact of one session across many downstream systems. This is not a generic API gateway issue. It is a governance problem where the protocol boundary defines how far an agent can reach before human oversight can intervene. Practitioners should measure blast radius at the gateway, not only at the tool.

Existing IAM programmes will need to reconcile human-style authentication with machine-style action timing. The post shows a model in which the identity authenticates like a client but behaves like an automated caller across tools and resources. That sits between familiar IAM categories and is exactly why agent governance is hard to bolt on later. The implication is that teams need policy models that understand tool context, not just user context.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• If you are extending gateway controls to AI workflows, start with NHI Lifecycle Management Guide and pair it with the OWASP Top 10 for Agentic Applications 2026 to close the policy gap.

What this signals

Protocol-bound identity blast radius: enterprises should expect the gateway to become the new point where agent permissions either stay contained or fan out across multiple tools. With 98% of organisations planning more AI agents even after 80% have already seen out-of-scope behaviour, according to AI Agents: The New Attack Surface report, the control challenge is now structural.

Identity and platform teams should prepare for MCP to blur the line between API governance and AI governance. That means access reviews must expand beyond human users and service accounts to include agent sessions, token audiences, and tool-level entitlements. The practical standard is whether a reviewer can reconstruct who acted, what tool was called, and whether the call stayed within policy.

Teams should also align agent controls with OWASP Top 10 for Agentic Applications 2026 and the identity lifecycle model in NHI Lifecycle Management Guide. That combination helps convert a protocol discussion into a governance programme that can actually measure and reduce agent risk.

For practitioners

• Map every MCP tool to an explicit entitlement Create an inventory of tools, resources, and prompts exposed through MCP and assign owners, scopes, and review cadence for each one. Treat the gateway as the enforcement point for those entitlements, not the tool backend.
• Enforce token validation at the gateway Require OAuth 2.1 introspection, audience validation, and narrow scope checks before any MCP request reaches a tool server. If a token cannot be tied to a specific tool action, reject it.
• Log identity and method at the translation layer Capture caller identity, tool name, method, parameters, and downstream API target in a single audit trail so protocol conversion does not erase evidence. Use those logs for access review and incident reconstruction.
• Separate discovery from execution for high-risk tools Allow agents to list available capabilities without automatically granting execution rights. Make sensitive actions require a narrower policy decision than simple context retrieval.

Key takeaways

• MCP is an identity governance issue as much as a protocol issue, because it turns AI tool use into a governed access path.
• The real security boundary is the gateway, where token scope, tool reach, and audit visibility either hold or fail together.
• Enterprises should treat AI agent access like a lifecycle-managed non-human entitlement, not like a one-off integration detail.

Key terms

• Mcp Host: The MCP host is the application that coordinates one or more MCP clients and decides what context to request. In identity terms, it is the orchestrating caller, so its permissions, session handling, and oversight determine how far tool use can extend.
• Mcp Server: An MCP server is the system that exposes tools, resources, or prompts to a client through the MCP protocol. It is not just an API endpoint, because it defines the available context surface and therefore becomes part of the non-human identity governance boundary.
• Protocol translation layer: A protocol translation layer converts requests between two protocols, such as MCP and HTTP, without changing the business action being requested. In security programmes, it is often where identity, logging, and policy controls either remain visible or get lost during mediation.
• Tool entitlement: A tool entitlement is the right for an AI system or other non-human identity to invoke a specific tool or method. It should be scoped to a purpose, tied to a credential or token, and managed through lifecycle controls rather than left as ambient access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Kong AI/MCP Gateway and Kong MCP Server Technical Breakdown. Read the original.