AI agent platforms need a gateway layer for runtime security

At a glance

What this is: This is Kong’s argument that AI agent security needs a traffic-layer gateway because recent platform compromises exposed how quickly application-layer assumptions fail.

Why it matters: It matters because IAM, NHI, and agentic AI programmes all need enforceable identity, policy, and logging controls at the boundary where agents, tools, and APIs interact.

By the numbers:

• 1 in 5 CISOs (19.5%) report at least one AI agent-related security event.

👉 Read Kong’s analysis of AI agent platform security gaps and gateway controls

Context

AI agent platforms are now being exposed to the same structural problem that hit early web applications: they move faster than the security controls around them. When agents can call tools, chain outputs, and operate with delegated authority, the boundary between application logic and identity enforcement becomes the real control point for AI agent platforms.

The article’s core point is that gateway-level enforcement is becoming the practical answer for AI agent security. That makes this relevant to NHI governance, because the identity subject is not only the model or app, but also the agent, its credentials, its tool calls, and the APIs it reaches under delegated access.

Key questions

Q: How should security teams secure AI agent platforms at the traffic boundary?

A: Security teams should enforce identity, policy, and logging at the traffic boundary rather than relying on application code alone. Every agent-to-service request should be authenticated, authorised, validated, and recorded before it reaches backend systems. This gives teams one consistent place to stop unsafe tool use, isolate tenants, and reconstruct actions after a compromise.

Q: Why do AI agents create a larger security risk than ordinary web applications?

A: AI agents can act with delegated authority, chain tool calls, and reach internal APIs without human pacing. That means a compromise can move from data exposure to active execution much faster than in a traditional web app. The risk is not just stolen data, but uncontrolled use of the identity and permissions attached to the agent.

Q: What do organisations get wrong about prompt injection and agent security?

A: They often treat prompt injection as a model-quality issue instead of a governance problem. Once a prompt can influence what tools an agent calls or what actions it takes, the issue becomes access control and policy enforcement. Teams need controls that stop malicious input before it can alter execution paths or privilege use.

Q: Who should own AI agent security across IAM, API, and platform teams?

A: Ownership should be shared but explicit. IAM teams should define identity and access policy, API teams should enforce request controls, and platform teams should manage the runtime boundary and logging. If ownership is split informally, gaps appear exactly where agents cross from one service to another.

Technical breakdown

Why AI agent platforms fail at the application layer

Application code cannot reliably enforce every control that matters once agents begin acting across services. Langflow and Dify show the same pattern in different forms: unauthenticated execution, tenant isolation failures, and inputs reaching sensitive logic before the infrastructure can validate them. That is why traffic-layer enforcement matters. A gateway can consistently inspect caller identity, request shape, and policy context before the backend executes a tool call or model action.

Practical implication: move authentication, request validation, and audit enforcement to the boundary where agent traffic enters the environment.

Prompt injection protection and traffic validation

Prompt injection is not just a model problem. It becomes an access problem when malicious input changes what an agent is allowed to do, what data it can request, or which service it can call. Semantic guards, rate limits, and request policy checks reduce the chance that a crafted prompt becomes an operational action. This is especially important when the agent is connected to internal APIs or privileged workflows.

Practical implication: treat prompt validation as an access-control layer, not only as content filtering.

Zero-trust enforcement for AI agent traffic

Zero trust for agentic systems means every request is authenticated, authorised, and logged even when the caller is already inside the environment. That matters because a compromised agent can act with delegated permissions and trigger downstream workflows faster than humans can intervene. The gateway becomes the place where identity, policy, and observability converge for AI traffic.

Practical implication: require per-request identity checks and logging for all agent-to-service communication.

Threat narrative

Attacker objective: The attacker objective is to turn an exposed AI agent platform into an execution and data-access point that crosses tenant boundaries and reaches internal services.

1. Entry occurred through unauthenticated or weakly controlled AI platform endpoints that allowed attackers to reach sensitive functions or internal services.
2. Escalation followed when platform flaws exposed cross-tenant conversations, internal APIs, or code execution paths that expanded attacker reach beyond the original request.
3. Impact was the loss of tenant isolation, exposure of private data, and the ability to operate inside production agent workflows with delegated permissions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

Gateway enforcement is now the missing identity layer for AI agents. When agents can call tools and execute actions across systems, application logic alone cannot be trusted to preserve identity boundaries. A traffic gateway becomes the practical place to authenticate callers, constrain privileges, and preserve auditability. Practitioners should treat the boundary as part of the identity stack, not a networking convenience.

AI agent security exposes a control assumption that web-era IAM was built on. Access controls were designed for requests that arrive through predictable application paths and remain bounded long enough to be checked. That assumption weakens when an agent can generate, chain, and replay calls at machine speed across multiple services. The implication is that governance models must be rebuilt around request-level enforcement, not just application ownership.

Semantic prompt guards are a security control, not a usability feature. Once prompts can drive tool selection or downstream actions, malicious input becomes a path to privilege abuse. This is why prompt injection belongs in the same conversation as RBAC, rate limiting, and API isolation. Practitioners should evaluate whether their controls stop input manipulation before it becomes authorisation drift.

AI agent traffic growth is already forcing programme re-scoping. With agent activity scaling quickly, the question is no longer whether teams will need dedicated governance for AI workloads, but where that governance sits and who owns it. NHI, API security, and AI platform teams will need a shared boundary model. Practitioners should plan for converged policy enforcement across agents, models, and internal services.

Identity blast radius is the right named concept for this category of failure. A compromised agent is not just a compromised application session, because it can move through delegated credentials into multiple tools and services. The control problem is the size of the operational blast radius created by a single identity event. Practitioners should design for containment at the first boundary that sees agent traffic.

From our research:

• AI agent traffic grew 7,851% year over year, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities. That gap is why agent governance needs identity controls that are enforced at runtime, not only at provisioning time.
• For the broader identity picture, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding work when access must be governed continuously.

What this signals

The programme implication is straightforward: AI agent traffic is now large enough that gateway policy can no longer be an optional overlay. Identity blast radius is the useful concept here. When one agent identity can touch multiple services, the boundary where requests are approved and logged becomes more important than the application that finally receives them.

Teams should expect AI governance to converge with API security and NHI governance rather than sit beside them. That convergence will reward organisations that can enforce per-request identity, not just per-deployment access, and it will expose environments that still depend on trusted internal traffic. For a practical baseline, review the OWASP Agentic Applications Top 10 alongside your gateway policy model.

For practitioners

• Enforce gateway-authenticated agent traffic Require every agent, tool, and model request to pass through a policy enforcement point that validates identity before backend execution. Use per-request logging so you can reconstruct which caller triggered which action across internal services.
• Separate prompt validation from application trust Treat prompt injection controls as part of request authorisation. Validate content before it reaches model or tool logic, and block requests that attempt to redirect execution toward unexpected APIs or internal functions.
• Apply rate limits to agent-driven execution Set token quotas and request thresholds for agent traffic so a compromised identity cannot accelerate abuse through thousands of calls in a short period. Tie limits to service class and workflow sensitivity, not only user tier.
• Audit tenant isolation assumptions Review whether multi-tenant agent platforms still rely on trusted-caller assumptions inside the architecture. Test whether one tenant can infer, reach, or replay another tenant’s internal API traffic through mis-scoped gateway rules.
• Map agent governance to existing IAM ownership Assign clear owners for agent identity, API policy, and downstream service permissions so no team assumes another layer will absorb the risk. Use one control model across AI platforms, API gateways, and identity governance.

Key takeaways

• AI agent platforms are failing where application assumptions end and runtime identity enforcement should begin.
• Recent compromises show that unauthenticated execution and tenant isolation failures can turn agent platforms into active attack infrastructure.
• The strongest control response is boundary enforcement that authenticates, validates, and logs agent traffic before backend services act.

Key terms

• Agent Gateway: A gateway for AI agents is a policy enforcement point that sits between the agent and the services it can call. It authenticates requests, applies authorisation rules, validates inputs, and logs activity so the platform can govern runtime behaviour rather than trusting the application alone.
• Prompt Injection: Prompt injection is the manipulation of an AI system through crafted input that changes how it behaves, what it retrieves, or which tools it uses. In agentic environments, the risk is not only bad output but unwanted actions taken under delegated authority.
• Identity Blast Radius: Identity blast radius is the amount of damage one credential, token, or agent identity can cause if it is misused or compromised. In agentic systems, the blast radius expands when one identity can chain actions across multiple tools, APIs, and workflows without additional controls.
• Traffic-Layer Enforcement: Traffic-layer enforcement means applying security controls at the point where requests enter or move between systems. For AI agents, it is the practical way to make identity, policy, and logging consistent across models, tools, and backend services.

What's in the full analysis

Kong's full blog post covers the operational detail this post intentionally leaves for the source:

• Specific gateway policy examples for authenticating agent-to-service calls across internal APIs
• Implementation details for semantic prompt guards, token quotas, and request-level logging
• The article’s practical comparison between AI agent security and the earlier WAF model for web apps
• References to Kong AI Gateway documentation and related implementation guidance

👉 Kong’s full post covers the Langflow and Dify incidents, gateway enforcement, and traffic-layer controls in more detail.

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 programme maturity, it is worth exploring.