6 minBusiness
AI agent security experts warn gateways are not the first control to deploy
Enterprises are rushing to deploy AI gateways as their first security control, but experts argue this approach is flawed. Identity and attribution layers must come first, or agents can drift, expose data, or suffer memory poisoning.
Enterprises racing to secure their AI agents are reaching for the wrong control first, according to security experts who study production deployments. The gateway, which sits between agents and the systems they access, is often the first layer teams install — but it is the one they are least prepared to run effectively. The reason is simple: gateways depend on identity and attribution layers that most organizations have not yet built.
The risk is not hypothetical. In June, the Cybersecurity and Infrastructure Security Agency added a flaw in LiteLLM, a popular AI gateway, to its Known Exploited Vulnerabilities catalog after attackers were found abusing it in the wild. The bug allowed remote command execution on the host through the gateway itself, and when chained with a second flaw, required no credentials at all. That single gateway disclosed seven common vulnerabilities and exposures in one month.
Security professionals argue that gateway controls should not be the first line of defense in agent architecture — they should be the fifth. The problem is sequencing. Most models describing agent security maturity focus on what controls a company will eventually need, but they miss the harder question of how to layer those controls on top of an existing identity and access management system. If the control plane cannot determine which agent is acting, who delegated the work, what task the agent is supposed to perform, and what credentials are being used, then the context is incomplete.
A gateway may block clear policy violations, but it will struggle to distinguish a justified action from one that is technically permissible yet operationally inappropriate. Consider a finance-reconciliation agent that tries to alter a record in production. The gateway authenticates the user token and checks the API call. What it cannot observe is that the request is agent-initiated, that the agent is executing a more limited function, or that the request is part of a tool chain invoked by an untrusted artifact. The credential is valid. The API call is permissible. The action contradicts the purpose of the delegation.
Limiting an agent's privileges to those of the human principal is useful, so the agent does not exceed the person it serves. However, having a privilege ceiling does not create separate attribution. Twenty agents might operate under a single person's permissions and still need unique identities, audit logs, behavior profiles, and revocation paths.
Experts propose a framework called dependency-gated deployment. Under this model, upstream exit tests must be satisfied before any downstream control is considered operationally complete. The framework includes six gates. The first is agent inventory and accountable ownership, meaning every production agent has a named owner, purpose, approved tools, and lifecycle state. The second is distinct agent identity plus delegation context, so the system can identify the agent, its owner, and the principal it is acting for. The third is task-scoped, short-lived credentials, so a compromised agent cannot reach resources unrelated to its assigned task. The fourth is attributable telemetry, allowing a completed task to be reconstructed from initiation to downstream effect. The fifth is runtime action enforcement, where policy decisions incorporate agent, principal, task, and action context, not just token validity. The sixth is behavioral baselines and cross-system kill paths, so the agent's effective authority can be stopped everywhere it reaches.
The first step for organizations is to recognize the production agents already running in open-source frameworks, cloud offerings, SaaS services, and developer tools. For each, teams should record the owner, responsibility, lifecycle stage, allowed tools, data domains, and sources of credentials. Bypassing this step means losing the first hour of incident response while figuring out what should have been obvious.
An agent needs its own identity, but it cannot lose the human behind it. Agents should not be buried in a developer token, a shared service account, or a human session. Simply knowing the caller is an agent is not sufficient. The control plane requires additional delegation context: who delegated the work, what specific task the agent was instructed to execute, and which resources the agent needs authority to access. Identity specifies which actor placed the call. Delegation answers whose authority it acts under, and for what reason. Once that connection is cut, downstream logs attribute the agent to the employee whose token it borrowed, and every action it takes is attributed to someone who did not start it.
Once an agent can be identified, capabilities should be limited. Access restrictions should be time-bound to the task and limited to the tools and resources required to perform the work. This can be implemented using identity access management features such as workload identity, token exchange, conditional access, and time-bound entitlements.
