Notifications
Clear all
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.
NHIMG editorial — based on content published by Kong: AI Agent with Strands SDK, Kong AI/MCP Gateway & Amazon Bedrock
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Separate tool exposure from model access Define which MCP tools an agent may discover, call, and chain at the gateway layer.
- 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.
- 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.
What's in the full article
Kong's full blog post covers the implementation detail this post intentionally leaves for the source:
- Step-by-step request flow between a Strands agent, Kong AI/MCP Gateway, and Amazon Bedrock.
- Concrete examples of gateway plugins for prompt guards, transformers, rate limiting, and observability.
- AWS CLI and Kubernetes deployment details for using EKS Pod Identity with the data plane.
- The full tool-call trace showing how the agent selects and invokes backend services.
👉 Read Kong's engineering post on Strands SDK, AI/MCP Gateway, and Bedrock →
MCP gateway controls for AI agents: what IAM teams need to know?
Explore further
25/06/2026 5:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kong’s MCP gateway pattern shows where AI agent governance starts
