TL;DR: A July 2026 Darktrace disclosure shows an exposed LiteLLM AI gateway with standing Amazon Bedrock access turned one server compromise into a far wider identity risk, according to Cakewalk's analysis. The core issue is not the gateway category itself but whether it holds persistent credentials, because runtime policy at the gateway can either collapse or concentrate blast radius.
NHIMG editorial — based on content published by Cakewalk: AI Gateway Security: The New Attack Surface and the New Control Point
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI gateways in production environments?
A: Security teams should govern AI gateways like shared control planes, not convenience proxies.
Q: Why do standing credentials inside AI gateways create such a large risk?
A: Because the gateway becomes a reusable identity holder.
Q: What breaks when an AI gateway lacks enterprise governance features?
A: Without enterprise governance, teams often lose auditability, enforceable access control, and consistent policy enforcement.
Practitioner guidance
- Map every gateway-held credential to a named owner Identify whether the gateway stores instance profiles, API keys, or other secrets, then assign a human owner and a revocation path for each one.
- Move high-risk agent actions to per-call policy evaluation Require a fresh decision for writes, destructive operations, and external actions instead of allowing a session-wide grant.
- Separate model routing from tool governance Do not assume that an AI gateway that forwards model calls is also the right place to govern application actions.
What's in the full article
Cakewalk's full article covers the operational detail this post intentionally leaves for the source:
- The gateway decision flow that separates auto-approve, escalate, and deny paths for agent tool calls.
- The runtime credential injection model that keeps the agent from ever seeing a reusable secret.
- The policy evaluation structure built on Open Policy Agent and the action-type defaults for read, write, destructive, and external calls.
- The decision trace and audit model that records who delegated, what executed, and when access ended.
👉 Read Cakewalk's analysis of AI gateway security and runtime agent governance →
AI gateway security: are your agent controls still too static?
Explore further
AI gateways are becoming identity infrastructure, not just traffic infrastructure. Once the gateway holds credentials, evaluates policy, and fronts multiple model calls, it becomes a governance boundary that IAM and PAM teams cannot treat as a passive relay. The control question is no longer only who can reach the gateway, but what authority the gateway itself is allowed to exercise. Practitioners should classify it as a first-class identity control point.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 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: What should teams do when an AI gateway is exposed to the internet?
A: Treat it as a potential identity exposure, isolate it, and review whether it contains cloud credentials, model access, or agent-usable secrets. Then revoke any standing authority that is not required for the current task flow. Internet exposure plus persistent access is the combination that turns a gateway into a breach amplifier.
👉 Read our full editorial: AI gateway security redefines the control point for agent access