Kong AI Gateway for ReAct agents exposes the governance gap

At a glance

What this is: An engineering walkthrough of how Kong AI Gateway sits in front of ReAct agents, model routing, and tool access, with the key finding that agent architecture needs explicit governance boundaries.

Why it matters: It matters because identity and access teams now have to govern AI agents as runtime decision-makers, not just API consumers, and that changes policy, logging, and containment requirements across NHI and future autonomous use cases.

👉 Read Kong’s walkthrough on strengthening a ReAct AI agent with Kong AI Gateway

Context

ReAct agents combine reasoning, tool use, and orchestration in a loop that can change model selection and action flow at runtime. That is why primary keyword coverage here is not just about agent frameworks, but about how AI agent identity and access behave once tool calls and model routing become part of the control plane. Kong’s article is a practical architecture example, not a policy framework.

For IAM and NHI teams, the real issue is separation of duties between the agent, the models it can reach, and the external systems it can invoke. If policy lives only inside prompts or application code, the governance boundary stays brittle. A gateway layer can help, but only if access decisions, telemetry, and model routing are treated as identity controls rather than simple traffic management.

This is a strong fit for a broader agentic AI governance discussion because the post spans orchestration, model access, external functions, and observability. The starting point is typical for early AI agent builds: functional, instructive, and not production-hardened.

Key questions

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. The key is to treat the agent as an identity with bounded runtime reach, not as a harmless application feature. That keeps model changes, tool changes, and audit requirements visible in one place.

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. A single request can become a sequence of model calls and tool invocations, which means least privilege, approval, and audit all need runtime enforcement. Static entitlements alone do not describe the full access path.

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. The organisation loses a reliable control point for routing, logging, and privilege reduction. That creates hidden access paths that are difficult to detect after the agent has already acted.

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.

Technical breakdown

ReAct orchestration and runtime decision paths

ReAct, short for reasoning and action, combines iterative thought with tool calls and observations. In practice, the agent does not just answer a prompt, it enters a loop that can revise plans, select tools, and invoke external services before producing output. That makes the orchestration layer part of the identity boundary, because it controls when the agent can move from inference to action. When multiple models are available, routing also becomes a governance decision, not just an optimisation step.

Practical implication: treat orchestration as an access control surface and require visibility into every model call and tool invocation.

AI gateway policy for model and tool access

An AI gateway sits between the agent and the services it consumes, much like an API gateway sits between apps and backends. The difference is that the gateway may need to govern multiple model endpoints, external functions, and data sources at once. That introduces policy questions that are closer to NHI governance than to traditional API proxying: which identities can call which models, under what constraints, with what logging, and with what redirection if a model is removed or replaced.

Practical implication: centralise model and tool entitlements so access changes are enforced outside the agent codebase.

Observability, auditability, and agent containment

The article’s use of Grafana, Loki, and Prometheus points to a basic truth about agentic systems: you cannot govern what you cannot trace. For agent workflows, auditability must include prompt inputs, model routing choices, tool calls, and failures in the reasoning loop. That is especially important when the agent uses external functions or multiple model providers, because the blast radius is not just one API call but a sequence of decisions across services and identities.

Practical implication: log agent decisions at each hop so containment and post-incident review can reconstruct the full action chain.

Threat narrative

Attacker objective: The attacker wants to turn the agent’s own reasoning and tool access into a wider path for data exposure or unauthorized action.

1. Entry occurs when an agent is allowed to interact with multiple models and external tools through a loosely governed runtime loop rather than a tightly bounded policy layer.
2. Escalation happens when the orchestration layer can select models or invoke tools with more privilege than the original request should justify, especially if access rules live in prompts or application logic.
3. Impact is a widened agent blast radius, where one compromised or misdirected agent can touch multiple backends, leak context, or trigger unintended actions across the environment.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Identity blast radius is the right named concept for multi-model ReAct architectures. Once an agent can call several models, external functions, and observability systems, the security problem is no longer single-account privilege but cross-service reach. The question becomes how far one agent identity can move before oversight or containment breaks. Practitioner implication: map every tool and model dependency to a bounded blast-radius model.

Standing policy assumptions do not fit agent-timed execution. Traditional IAM assumes access can be reviewed after it is granted, but ReAct agents decide at runtime which path to take and when to take it. That weakens any control model that depends on human-paced review of a stable request. Practitioner implication: redesign entitlement review around runtime behaviour, not static provisioning records.

Gateway placement matters because it separates agent intent from downstream privilege. Kong’s architecture makes the gateway the place where model access, external function access, and observability can be unified. That is the correct design direction for NHI governance, but only if the gateway actually enforces policy rather than just records traffic. Practitioner implication: do not confuse mediation with control unless policy is enforced at the gateway layer.

Agentic AI governance now overlaps NHI, API security, and lifecycle governance in one control problem. The same architecture that routes models also has to support onboarding, rotation, removal, and audit of external dependencies. That means IAM teams cannot keep agent governance in a separate innovation track. Practitioner implication: fold agent runtime access into existing NHI and IGA operating models before production scale makes the gap harder to close.

From our research:

• 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.
• Read OWASP Agentic AI Top 10 for a practical framework on the risks that gateway policy needs to contain.

What this signals

Identity blast radius is the operational question that will decide whether agent programmes stay governable as they scale. Once one ReAct loop can touch multiple models, vector stores, and external functions, the control problem shifts from access grant to access containment. Teams should expect gateway policy, logging depth, and model routing rules to become board-level governance topics rather than engineering preferences.

The adoption curve is moving faster than the control curve, and that gap is already visible in the research data. With 98% of organisations planning to deploy more AI agents, the next programme review should ask where agent identities are inventoried, how tool access is bounded, and whether revocation works when the orchestration layer changes. That is the practical test of readiness.

For teams building on agentic AI, the next step is to align runtime policy with NIST AI Risk Management Framework governance expectations and the agent-specific risks captured in the OWASP Top 10 for Agentic Applications 2026. The signal is clear: identity control must move upstream of agent execution, or the governance boundary will keep shifting after deployment.

For practitioners

• Inventory every model and tool dependency Create a complete list of models, external functions, vector stores, and observability endpoints that the agent can reach. Classify each dependency by business criticality and required privilege, then separate direct application access from gateway-mediated access.
• Enforce policy outside the agent prompt Move access rules, routing constraints, and logging requirements into the gateway or surrounding control plane. Prompts can guide behaviour, but they should not be the only place where privilege boundaries are defined.
• Trace every reasoning loop hop Record prompt input, model selection, tool invocation, response handling, and failure state for each agent run. Keep those logs usable for incident review so you can reconstruct what the agent attempted and why it changed course.
• Bound agent blast radius by function Split high-risk tools, sensitive models, and write-capable integrations into separate policy zones. If the agent does not need a capability for the task, remove that path entirely rather than relying on prompt instructions to avoid it.
• Review lifecycle handling for agent identities Treat agent provisioning, credential rotation, and decommissioning as part of identity lifecycle management. When an agent, model, or tool is retired, remove its access through the same offboarding discipline used for service accounts and other NHIs.

Key takeaways

• ReAct agents turn model routing and tool use into an identity problem, not just an architecture problem.
• If policy sits only in prompts or code, agent behaviour can outrun the governance boundary before anyone notices.
• Teams need gateway-enforced access, granular logging, and lifecycle controls if they want AI agents to stay within a defensible blast radius.

Key terms

• ReAct agent: An AI agent that combines reasoning and action in a loop. The system plans, calls tools, observes results, and then revises its next step. In agentic environments, this pattern can expand access risk because decisions and execution happen together.
• AI gateway: A control layer that mediates access between AI applications and the models, tools, or data sources they use. It can enforce policy, logging, routing, and safety controls. For identity teams, it becomes a practical place to bind agent behaviour to enforceable access rules.
• Identity blast radius: The amount of damage an identity can do before containment or revocation stops it. For AI agents, the blast radius includes model calls, tool invocations, and downstream services that the agent can reach in a single reasoning sequence.
• Agent runtime policy: The rules that govern what an AI agent may do while it is executing, including model selection, tool access, logging, and output constraints. Unlike static configuration, runtime policy has to remain effective as the agent changes paths during a live session.

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: How to Strengthen a ReAct AI Agent with Kong AI Gateway. Read the original.