Notifications
Clear all
Topic starter
24/06/2026 9:07 pm
TL;DR: Agent decision paths can outgrow the policy assumptions embedded in conventional IAM and API governance, according to Kong’s walkthrough of how ReAct agents route prompts, tools, and model calls through an AI gateway, with architecture spanning LangGraph, multi-model selection, and observability layers. The central issue is that agent decision paths can outgrow the policy assumptions embedded in conventional IAM and API governance.
NHIMG editorial — based on content published by Kong: How to Strengthen a ReAct AI Agent with Kong AI Gateway
Questions worth separating out
Q: How should security teams govern AI agents that can route to multiple models and tools?
A: Security teams should govern AI agents through a control plane that can enforce model access, tool access, logging, and policy decisions outside the prompt.
Q: Why do ReAct agents complicate traditional IAM and API security models?
A: ReAct agents complicate traditional IAM because they make decisions during execution, not only at provisioning time.
Q: What breaks when agent policy lives only in prompts or application code?
A: When policy lives only in prompts or application code, it becomes easy to bypass, hard to audit, and fragile across model changes.
Practitioner guidance
- Inventory every model and tool dependency Create a complete list of models, external functions, vector stores, and observability endpoints that the agent can reach.
- Enforce policy outside the agent prompt Move access rules, routing constraints, and logging requirements into the gateway or surrounding control plane.
- Trace every reasoning loop hop Record prompt input, model selection, tool invocation, response handling, and failure state for each agent run.
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 ReAct agent code and prompt structure used in the example architecture
- Kubernetes and Konnect deployment commands for the data plane and control plane
- Minikube, Redis, Ollama, and observability setup details for the lab environment
- The blog series roadmap for extending the agent from a simple ReAct loop to LangGraph and multi-LLM patterns
👉 Read Kong’s walkthrough on strengthening a ReAct AI agent with Kong AI Gateway →
ReAct AI agents and gateway policy: what IAM teams need to know?
Explore further
25/06/2026 6:08 am
AI agent governance collapses when orchestration is treated as plumbing instead of identity control. The article shows an agent loop that decides, routes, and invokes tools across multiple model providers. That is not a simple API proxy problem, because access decisions happen inside the runtime sequence itself. Practitioner implication: governance must follow the decision path, not just the endpoint list.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: How can teams reduce the blast radius of AI agents in production?
A: Teams should reduce blast radius by separating high-risk tools, limiting model reach, and enforcing allowlists at the gateway or control plane. They should also make logging granular enough to reconstruct each action in the reasoning loop. If a task does not need a capability, the safest choice is to remove it.
👉 Read our full editorial: Kong AI Gateway for ReAct agents exposes the governance gap
