AI agent platforms need a gateway layer for runtime security

At a glance

What this is: Kong argues that AI agent platforms need a gateway layer because recent compromises in Langflow and Dify showed traffic-layer weaknesses, not just application bugs.

Why it matters: IAM, PAM, and NHI teams need a control point that can authenticate agent traffic, enforce policy, and limit blast radius before delegated access reaches downstream services.

By the numbers:

• 1 in 5 CISOs (19.5%) report at least one AI agent-related security event, according to NeuralTrust research cited by Kong.

Context

AI agent gateway security is the practice of enforcing identity, policy, and request controls at the traffic boundary between agents and backend services. When agent platforms can invoke tools, call internal APIs, and chain actions across systems, the security model cannot rely on application code alone.

Kong's analysis frames Langflow and Dify as evidence of a widening gap between rapid AI agent deployment and the maturity of runtime controls. The governance problem is not only whether an agent is approved, but whether every request, tool call, and tenant boundary is enforced before execution.

For IAM and NHI practitioners, this is the same architectural question that surfaced with web applications and WAFs: where does enforcement live when the application itself cannot be trusted to mediate every interaction?

Key questions

Q: What breaks when AI agent security is handled like ordinary application security?

A: Application security assumes a relatively stable workload boundary and a predictable request path. AI agents can select tools, access data, and continue executing in ways that change the path mid-workflow. When teams treat them like static apps, they miss the identity and authorisation layer where real risk appears.

Q: Why do compromised AI agents create a larger blast radius than ordinary web apps?

A: Compromised AI agents can use delegated authority to call tools, reach internal APIs, and chain actions across services. That makes the impact broader than data theft from a web form because the attacker can operate through the agent's permissions. The practical risk is not only disclosure, but abuse of trusted runtime access.

Q: What are the signs that AI agent security controls are too weak?

A: Common warning signs include agents accessing systems or data outside their intended scope, sharing sensitive information inappropriately, and using credentials or tools without clear justification. Another indicator is inconsistent visibility into what the agent touched, especially when security, compliance, and legal teams do not share the same view of agent activity and data access.

Q: How should IAM teams govern AI agent access differently from human developer access?

A: IAM teams should govern AI agents as runtime consumers of access, not as users with durable credentials. That means binding privileges to the task, not the identity alone, and maintaining approval, revocation, and logging around the access event. The control objective is to prevent the agent from becoming a standing secret holder.

Technical breakdown

Why agent platforms break application-only security

AI agent platforms differ from ordinary web apps because the platform does not just serve content. It can orchestrate tool calls, pass context between services, and execute actions with delegated authority. That means unauthenticated input, weak request validation, or missing tenant isolation can turn into command execution or cross-boundary access rather than simple data exposure. In Kong's examples, the vulnerable surface was the traffic path into the platform, not only the code inside it.

Practical implication: treat the agent gateway as the enforcement point for identity, validation, and policy before requests reach the platform.

Gateway controls for AI agent runtime security

A gateway layer can authenticate agents and service calls, apply authorization, filter malicious inputs, rate limit abuse, and log traffic for audit. In identity terms, it becomes the runtime decision point that checks who or what is asking, what it is allowed to do, and how often it can do it. That is materially different from embedding controls only in downstream application logic, which can be bypassed when multiple tools, models, and microservices are involved.

Practical implication: centralise agent access enforcement where requests enter the environment, not where each application hopes to interpret them.

Why zero trust matters more when agents can act

Zero trust for AI agents means no caller is trusted by default, even if the caller is an internal agent or a known workflow component. The control objective is to prevent a compromised agent from moving laterally, invoking sensitive tools, or amplifying its own access through chained actions. For IAM teams, this shifts the problem from static entitlements to per-request governance and continuous verification at runtime.

Practical implication: design agent connectivity around continuous verification, not assumed trust in internal callers.

Threat narrative

Attacker objective: The attacker seeks to gain runtime control over an agent platform or use weak traffic controls to read data, reach internal APIs, and trigger actions under delegated permissions.

1. Entry occurred through exposed platform flaws, including unauthenticated remote code execution in Langflow and cross-tenant data exposure in Dify.
2. Escalation followed when attackers could move from platform access to internal APIs, private conversations, and tenant-separated data.
3. Impact was broader than simple disclosure because AI agents can call tools and execute workflows with delegated authority.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Gateway enforcement is becoming the minimum viable control plane for agentic systems. Agent platforms do not fail like ordinary web applications because they can translate input into tool use, workflow execution, and API calls. That changes the control problem from protecting pages to governing runtime action, which is why traffic-layer enforcement now matters more than application-only hardening. Practitioners should treat gateway policy as a core identity control, not a network convenience.

Runtime agent security exposes a trust assumption collapse in current IAM design. Least privilege was designed for actors whose permissions are relatively stable between review cycles. That assumption fails when an agent can obtain, combine, and exercise permissions within a single runtime session. The implication is not simply tighter access lists but a different governance model for delegated machine action.

Cross-tenant isolation is not enough if the traffic boundary is porous. Dify's exposure shows that multi-tenant design can still leak conversations and internal APIs when request handling does not enforce identity and boundary checks consistently. This is a governance failure as much as a technical one, because it allows the platform to inherit trust that the gateway should have denied. IAM teams need to evaluate where isolation is actually enforced, not where it is merely documented.

Identity blast radius is the right concept for AI agent platforms. A compromised agent is more dangerous than a compromised web endpoint because it can act, not just display. The relevant question is no longer whether access exists, but how far delegated access can travel before containment kicks in. That makes runtime identity boundaries and per-request authorization the decisive controls for this category.

Standardisation will not reduce risk unless it is paired with enforcement. Industry moves toward agent identity and naming infrastructure may improve interoperability, but they also make large-scale invocation easier. Without gateway policy, standardised agent discovery can widen the attack surface faster than governance teams can absorb it. Practitioners should evaluate emerging agent identity standards through the lens of enforcement, not convenience.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Identity blast radius: agent platforms need governance that assumes action, not just access. Once a platform can invoke tools and chain workflows, the unit of control becomes the request, because that is where a compromised caller turns into a privileged actor.

The operational signal for IAM and NHI programmes is straightforward: if authentication, authorisation, logging, and rate limiting live in different layers, the control plane is fragmented. Teams should watch for any agent deployment that can reach internal APIs without a consistent gateway policy applied first.

For practitioners

• Enforce gateway authentication for every agent call Require identity checks at the traffic boundary before any agent, model, or tool request reaches a backend service. This prevents unauthenticated traffic from entering runtime flows and gives security teams one place to apply policy consistently.
• Apply tenant isolation at the request layer Verify that cross-tenant boundaries are enforced before requests reach application logic, especially for chat history, internal APIs, and shared tool endpoints. Isolation that exists only in the data model is not enough if the gateway lets requests through unchecked.
• Rate limit delegated agent activity Cap tool calls, model invocations, and API requests per agent or tenant so a compromised agent cannot amplify itself into a denial-of-wallet or workflow abuse event.
• Log every tool call and policy decision Capture who requested the action, what resource was targeted, and whether the gateway allowed or blocked the request. That record is essential for audit, containment, and post-incident review.
• Separate approval from execution for sensitive actions Require explicit policy checks before an agent can reach internal services that change state, access tenant data, or invoke privileged workflows. Delegated authority should never be assumed just because the caller is internal.

Key takeaways

• AI agent platforms create a runtime governance problem because agents can act through delegated authority, not just expose data.
• The article cites two production compromises, one involving unauthenticated remote code execution and the other cross-tenant exposure of conversations and internal APIs.
• Gateway-level authentication, validation, rate limiting, and logging are the controls that change the risk profile because they enforce policy before agent traffic reaches the application.

Key terms

• Agent gateway: The local or remote control layer that authenticates, pairs, and orchestrates an AI agent’s actions across connected tools. In practice it becomes an identity concentrator, because one gateway session can govern messages, commands, and downstream systems with far broader reach than the user interface suggests.
• Delegation authority: Delegation authority is the right for one identity to act on behalf of another within a defined scope. For agents, it must be explicit, time-bound, and auditable because the system may initiate actions independently once granted access.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.