Notifications
Clear all
Topic starter
04/07/2026 10:00 pm
TL;DR: Two AI agent platforms were compromised in the same week, with Langflow hit by unauthenticated remote code execution and Dify exposing private conversations and internal APIs across tenants, according to Kong’s analysis. The pattern shows why application-layer controls are not enough when agents can call tools and act with delegated authority.
NHIMG editorial — based on content published by Kong: AI Agent Platforms Are Getting Hacked. Here's What's Missing
By the numbers:
- 1 in 5 CISOs (19.5%) report at least one AI agent-related security event.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Separate prompt validation from application trust Treat prompt injection controls as part of request authorisation.
- 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.
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
👉 Read Kong’s analysis of AI agent platform security gaps and gateway controls →
AI agent gateway security: what IAM teams need to govern now?
Explore further
04/07/2026 10:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent platforms need a gateway layer for runtime security
