Topic starter
24/06/2026 8:39 pm
TL;DR: The governance issue is not model choice, but whether agent tool use and upstream permissions are being constrained, audited, and separated from long-term credentials, according to Kong. Kong’s architecture shows how Strands agents, MCP tools, and Amazon Bedrock can be mediated through a gateway that centralises authentication, prompt controls, observability, and Pod Identity-based access to AWS services.
Editorial analysis by NHI Mgmt Group, based on content published by Kong: “Build Prod-ready Agents with Strands, Kong AI/MCP & Bedrock”.
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.
Q: Why do workload identities reduce risk for agent backends compared with long-lived AWS keys?
A: Workload identities reduce persistence of privilege.
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.
Practitioner guidance
- 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.
Bottom line: AI agents change the identity problem by turning tool access into a governed runtime decision, not just an application feature.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 5:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kong’s MCP gateway pattern shows where AI agent governance starts