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

At a glance

What this is: This is a Kong engineering post on wiring Strands SDK, Kong AI/MCP Gateway, and Amazon Bedrock into a governed agent stack with centralized control points.

Why it matters: It matters because IAM teams now have to govern tool access, API mediation, and workload identity as one chain, not as separate AI and infrastructure problems.

By the numbers:

• 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.
• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Kong's engineering post on Strands SDK, AI/MCP Gateway, and Bedrock

Context

AI agent governance is the control problem created when a runtime can select tools, call upstream APIs, and act on model output through a shared execution path. In this case, the primary issue is not the foundation model itself, but the combination of gateway policy, tool exposure, and workload identity that determines what the agent can actually do.

Kong’s pattern shows a familiar enterprise tension: developers want agent flexibility, while security teams need bounded access, auditable calls, and credential separation. That puts MCP, API gateway controls, and AWS identity management into the same programme conversation, which is where IAM teams should already be operating.

The article is a practical implementation example, not a governance framework. Its value is that it exposes the places where control must be asserted if an agent is going to talk to tools and Bedrock without turning the whole path into unmanaged runtime access.

Key questions

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

A: They should treat the gateway as the control point for discovery, authorization, and audit. The agent framework should not see every backend capability by default, and each tool route should be tied to a specific identity, policy, and logging requirement. That is how teams keep agent behaviour inside a governable boundary.

Q: Why do AI agents complicate workload identity and secrets management?

A: Because an agent stack often combines model access, tool access, and backend API calls in one runtime path. If those permissions are handled with shared secrets or broad service credentials, the agent inherits more access than its task requires. Workload identity narrows that problem to a governed runtime identity instead of a portable secret.

Q: What breaks when agent tool access is not mediated through a gateway?

A: Tool exposure becomes a flat capability set instead of a bounded decision surface. That increases the chance that the agent will call systems it does not need, chain actions across services without review, or leave security teams unable to prove which tools were used in a session. Gateway mediation is what makes the trail visible.

Q: Which frameworks apply to AI gateway governance and agent identity?

A: OWASP NHI and Zero Trust are the most direct fits for workload identity, tool exposure, and least-privilege control. For broader AI governance, teams should also use an AI risk framework to define ownership, evidence, and accountability across the agent lifecycle. The common requirement is that runtime access must be explainable.

Technical breakdown

How MCP gateway mediation changes agent tool access

Model Context Protocol exposes tools as callable interfaces, but the security question is who is allowed to see which tools, under what route, and with what identity. A gateway adds policy enforcement between the agent and the MCP server, which turns tool access from an open catalog into a controlled interaction surface. In practice, that means the agent is no longer coupled directly to every backend capability. Instead, the gateway can shape exposure, add authN/authZ, and observe what is being invoked.

Practical implication: restrict tool exposure at the gateway rather than assuming the agent framework will self-limit access.

Why workload identity matters for Bedrock access

When a gateway proxies requests to Amazon Bedrock, the data plane needs its own AWS permissions to call the Converse API. Using EKS Pod Identity avoids embedding long-lived AWS keys in the deployment and shifts access to a workload identity bound to the pod. That matters because the gateway becomes an identity-bearing component in its own right, with a discrete trust boundary and audit trail. The architectural decision is not cosmetic. It changes whether credentials are static secrets or managed workload identity.

Practical implication: assign Bedrock permissions to the workload, not to human-managed access keys.

Agent observability is an identity control, not just an ops metric

The post emphasises logging, token accounting, request transformation, and policy plugins because agent governance depends on knowing what was requested, which model handled it, and which tool calls were made. In AI systems, observability is part of identity control because it provides the evidence needed to distinguish intended action from scope drift. Without that telemetry, security teams cannot reconstruct whether the agent used the right route, the right model, or the right backend access path.

Practical implication: treat agent telemetry as a control requirement, not as optional operational monitoring.

NHI Mgmt Group analysis

Gateway mediation is becoming the practical control plane for AI agent identity. The article shows a design where agent requests, tool calls, and model access are all forced through a policy layer instead of being allowed to fan out directly. That is the shape of governance enterprise teams will need when agent frameworks start acting as integration middleware. The practical conclusion is that access should be mediated where the agent meets the tool, not after the fact.

Long-lived credentials are the wrong trust primitive for agentic infrastructure. The use of EKS Pod Identity reflects the fact that the gateway itself needs a workload identity that can be governed and rotated without manual key handling. This aligns with OWASP-NHI and NIST Zero Trust thinking: the identity of the calling workload matters as much as the request content. Practitioners should re-center Bedrock access on workload identity rather than static secret distribution.

Named concept: agent tool blast radius. This post illustrates how quickly an agent can inherit too much capability when tool catalogs, model endpoints, and upstream APIs are all exposed through the same path. The blast radius is not only the model's output, but the set of actions available through the gatewayed toolchain. The practitioner implication is that agent access scope must be designed as a bounded execution surface, not as a broad integration convenience.

Auditability has become a prerequisite for AI governance claims. Kong’s emphasis on observability, prompt controls, and plugin-based inspection shows that organisations cannot credibly govern agents if they cannot reconstruct what happened during a session. That is as true for human-operated AI workflows as it is for future autonomous systems. The practical conclusion is that governance evidence must be built into the runtime path, not assembled from disconnected logs later.

This architecture reinforces a broader market direction toward identity-aware AI gateways. The security boundary is shifting from model access alone to the combined control of prompts, tools, backend credentials, and response handling. That creates a stronger case for identity and policy teams to own the agent mediation layer alongside platform engineering. The practitioner takeaway is to evaluate AI gateway designs as identity infrastructure, not just as API plumbing.

From our research:

• 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, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to the same report.
• For a broader control model, review OWASP Agentic Applications Top 10 alongside the evidence base in the report.

What this signals

Agent tool blast radius is now the programme-level risk to watch. Once AI systems can call tools through mediated gateways, the security question shifts from model trust to how far a session can reach before policy stops it. Teams should expect pressure to classify agent routes, limit tool catalogs, and tie every call to a workload identity that can be audited end to end.

With 98% of companies planning to deploy even more AI agents within the next 12 months, the governance gap will widen unless runtime controls keep pace. That is why gateway mediation, workload identity, and session telemetry need to be designed together instead of being bolted on later. For a control blueprint, start with the NHI Lifecycle Management Guide and the OWASP Top 10 for Agentic Applications 2026.

AI agent oversight is becoming a cross-functional identity issue. Kong’s pattern is a reminder that developers, IAM, and platform teams now share responsibility for what an agent can see, call, and persist across a session. Organisations that keep AI gateway governance separate from identity governance will struggle to produce reliable evidence for compliance, incident response, or access review.

For practitioners

• Separate tool exposure from model access Define which MCP tools an agent may discover, call, and chain at the gateway layer. Keep tool visibility narrower than the full backend catalog, and review routes as identity-controlled surfaces rather than generic integration endpoints.
• Bind Bedrock access to workload identity Use EKS Pod Identity or an equivalent workload-bound mechanism so the data plane authenticates to AWS without embedded access keys. This keeps permission scope tied to the runtime rather than to manually managed secrets.
• Instrument agent sessions for forensic reconstruction Capture prompts, tool calls, route decisions, and response transformations so you can reconstruct the execution path after the fact. Treat that telemetry as evidence for governance, not just as observability data.
• Review gateway plugins as policy controls Map prompt guards, request transformers, rate limits, and response filters to specific governance objectives. Each plugin should answer a control question such as who can call what, under which identity, and with which content constraints.

Key takeaways

• AI agent governance depends on the gateway layer because that is where tool exposure, policy enforcement, and auditability intersect.
• Workload identity is the safer trust primitive for Bedrock-connected infrastructure than shared long-lived credentials.
• If teams cannot reconstruct tool calls and request paths, they do not have meaningful control over agent behaviour.

Key terms

• Model Context Protocol: A standard way for AI systems to discover and call external tools and data sources. In practice, it creates an identity and authorization problem because the tool surface can become much larger than the task. Governance depends on mediating which tools are visible, callable, and auditable.
• Workload Identity: An identity assigned to a running workload instead of a person. It lets infrastructure authenticate to cloud services without shared long-lived secrets. For AI platforms, workload identity is critical because the runtime itself often becomes the actor making privileged requests.
• Agent Tool Blast Radius: The amount of system reach an AI agent has through its callable tools, routes, and connected services. The blast radius grows when tool exposure is broad, policy is weak, or logs cannot reconstruct the execution path. Teams should treat it as a governance boundary, not a convenience metric.

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: AI Agent with Strands SDK, Kong AI/MCP Gateway & Amazon Bedrock. Read the original.