Kong’s MCP gateway pattern shows where AI agent governance starts

At a glance

What this is: This is Kong's walkthrough of using an AI/MCP gateway with Strands agents and Amazon Bedrock to control how agents reach tools, APIs, and cloud services.

Why it matters: It matters because IAM teams now need to govern agent tool access, token use, and upstream service permissions as a single control plane problem, not as separate application features.

Context

MCP gateway governance is the control problem of deciding which tools, models, and services an AI agent can reach, under what authentication path, and with what observability. In practice, that means the gateway becomes the policy boundary for agentic workloads rather than a simple routing layer.

Kong's article frames this around Strands agents, MCP tools, and Amazon Bedrock, with the gateway mediating access to models and backend services. For IAM and NHI teams, the important shift is that agent permissions are no longer just application logic; they are part of the identity boundary that must be governed end to end.

The article's starting position is typical for early agent deployments: teams want to make tool use work first, then discover where authentication, prompt control, and cloud access need to be separated. That is exactly where governance tends to lag adoption.

Key questions

Q: What breaks when AI agents connect directly to tools without a gateway?

A: Direct connections create fragmented secrets, inconsistent policies, and limited visibility into what the agent actually did. That makes it harder to revoke access quickly, investigate misuse, or prove control coverage, especially when multiple agents call multiple tools across different environments.

Q: Why do workload identities reduce risk for agent backends compared with long-lived AWS keys?

A: Workload identities reduce persistence of privilege. A gateway pod that assumes AWS permissions through identity-bound workload credentials is easier to scope and revoke than one carrying reusable access keys. That matters because agent runtimes are operationally dynamic, while static secrets create a durable attack surface.

Q: How do teams know whether agent tool controls are working?

A: They are working when every allowed call is attributable, every disallowed call is blocked at the gateway, and the agent cannot reach systems outside its exposed MCP endpoints. If the model can still influence backend behavior outside those paths, the control boundary is incomplete.

Q: What is the difference between prompt-level controls and runtime governance for agents?

A: Prompt-level controls decide what enters the model, while runtime governance decides what the agent is allowed to do after the response. The second layer is stronger because it can inspect file access, process creation, and network activity in real time. That is where practical containment has to happen.

Technical breakdown

How an MCP gateway separates agent capability from upstream access

An MCP gateway sits between the agent and the tools or APIs it wants to call, which lets the platform expose capabilities without exposing direct backend credentials. In this pattern, the agent may request a tool action, but the gateway handles authentication, policy checks, transformation, and logging before the request reaches an MCP server or cloud API. That distinction matters because tool availability and tool authority are not the same thing. The gateway becomes the enforcement layer for who may invoke what, not just the transport path for the call.

Practical implication: Treat the gateway as the place to bind agent identity, tool authorization, and audit logging before any upstream access is granted.

Why prompt controls belong in the same governance boundary as tool access

The article groups prompt template controls, prompt decorators, prompt guards, response guards, and PII sanitization alongside gateway policy. That is important because an AI agent does not only consume data, it also consumes instructions, and those instructions can alter tool selection, data exposure, and downstream actions. Prompt governance is therefore part of identity governance for the agent's runtime behaviour, not a separate content-safety concern. If prompt content can shape what the agent is allowed to do, then prompt controls are effectively part of authorisation design.

Practical implication: Use prompt filtering, injection controls, and response inspection as governance controls, not as optional safety add-ons.

Why EKS Pod Identity changes the credential model for agent backends

For Amazon Bedrock access, the article recommends EKS Pod Identity rather than long-term AWS access keys for the data plane. That shifts the trust model from stored static secrets to workload-based AWS permissions, which is closer to how production NHI governance should work. The pod assumes a role through AWS IAM and can call Bedrock without embedding reusable cloud credentials in the deployment. For identity teams, this is the difference between a durable secret and an identity-bound workload permission that is easier to scope and observe.

Practical implication: Prefer workload identity over long-lived cloud keys when the gateway or agent runtime needs AWS access.

Threat narrative

Attacker objective: Use agent-mediated access to reach tools, models, or cloud services with more authority than the original request should allow.

1. Entry occurs when an agent is allowed to reach tools or cloud services through direct, uncoupled access rather than through a governed gateway boundary.
2. Credential abuse follows if the runtime depends on long-lived keys or reusable API credentials that can be reused outside the intended agent path.
3. Escalation happens when the agent can expand from a narrow tool call into broader backend access, especially if prompt content can influence tool choice or request shape.
4. Impact is governed by whether the gateway can contain that access, observe it, and separate the agent's intent from the privileges of the underlying services.

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.
• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

MCP gateway governance is the first real control point for AI agents: Once an agent can select tools at runtime, the risk moves from model output quality to delegated access scope. Kong's pattern shows that the central governance question is not whether the agent can reason, but whether the gateway constrains what that reasoning may touch. For IAM and NHI teams, the control boundary starts before the first tool call.

Prompt controls and authorization controls now belong in the same design conversation: The article places prompt guards, prompt templates, response guards, and authN/authZ in one architecture because the agent's instructions shape its access path. That is a useful operating model for agentic systems: instruction handling can influence privilege use just as directly as identity assertions can. Practitioners should stop treating prompt safety as separate from access control.

Long-lived cloud credentials are the wrong primitive for gateway-mediated agents: EKS Pod Identity is a workload identity pattern, not a secret-sharing pattern, and that matters when an agent is invoking Bedrock on behalf of a service. Static access keys preserve reusable privilege in places where the agent lifecycle is short-lived and task-scoped. The governance issue is credential persistence, not just credential strength.

Delegated access without upstream separation creates identity blast radius: If the gateway normalizes many models, tools, and APIs behind one policy plane, then over-permissioning there can expose the full operational surface at once. That is why gateway design is now an identity architecture decision, not merely an API management decision. Teams should judge agent platforms by how well they separate agent intent from backend privilege.

Runtime observability is the only way to make agent governance auditable: Kong's emphasis on logs, metrics, and tracing reflects a broader reality: agents are not governable if their tool use is invisible after the fact. Access review alone is too late when the workload is ephemeral and the action chain is dynamic. Practitioners need to see which tool was called, under which identity, and against which upstream service.

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 Identity Security Buyer's Guide

What this signals

MCP gateway governance is becoming the practical control plane for agentic workloads because runtime tool use, model routing, and upstream permissions converge in one path. That means IAM teams need to evaluate agent access the same way they evaluate any privileged integration point: by issuance path, auditability, and blast radius, not by the model label attached to it.

The most important operational shift is that agent governance cannot live only in the application layer. Once tool calls are mediated through a gateway, policy, observability, and workload identity should be designed together, otherwise teams end up with visible prompts and invisible privileges.

For practitioners

• Define the MCP gateway as the policy boundary Map every agent tool, model endpoint, and backend API to a single governed control plane so authentication, authorization, and logging happen before upstream access is possible.
• Replace long-lived cloud keys with workload identity Use workload-based AWS permissions such as EKS Pod Identity for gateway pods and agent runtimes instead of embedding reusable access keys in deployment secrets.
• Bind prompt controls to access decisions Treat prompt templates, prompt guards, and response guards as part of the agent authorisation model when those instructions can alter tool selection or data exposure.
• Instrument tool use at the gateway layer Capture which agent called which tool, what upstream service was reached, and which identity path was used so incident review can reconstruct the action chain.
• Separate model routing from privilege scope Keep model selection, MCP tool exposure, and cloud permissions independently governed so a change in one plane does not widen access in another.

Key takeaways

• AI agents change the identity problem by turning tool access into a governed runtime decision, not just an application feature.
• The article's architecture shows that gateway policy, prompt controls, and workload identity are part of the same control boundary.
• Practitioners should focus on auditability and privilege separation before they scale agent deployments across tools and cloud services.

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.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Prompt Governance: Prompt governance is the set of controls used to manage who can create, edit, approve, and roll back prompts in a live AI system. It treats prompts as change-controlled artefacts because small text changes can materially alter model behaviour, data exposure, and tool use.
• 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.