Enterprise teams often prioritize runtime gateways as the first line of defense for AI agents, yet these systems frequently operate without the necessary identity context to function effectively. Security experts argue that this approach is fundamentally flawed because gateways depend on attribution layers that are usually absent in current deployments. If the control plane cannot identify the acting agent, the delegating principal, or the specific task at hand, a gateway may block clear policy violations but fail to distinguish a justified action from an operationally inappropriate one. This gap creates a dangerous scenario where valid credentials are used to perform unauthorized tasks, potentially exposing sensitive data or allowing agents to drift from their intended purpose.
Security researchers describe a repeating trend in agent deployments: the gateway is the first control teams reach for, but it is the one they are least ready to run. This is because gateways sit on top of identity and attribution layers that are mostly not there. The first layer of risk is not hypothetical. In June, CISA added a LiteLLM flaw to its Known Exploited Vulnerabilities catalog after attackers were caught abusing it in the wild. The bug ran commands on the host through the gateway itself, and chained with a second flaw it required no credentials. It was one of seven common vulnerabilities and exposures (CVEs) disclosed in that single AI gateway in a month.
When considering secure agent architecture, gateway controls should not be the first control. They should be the fifth. Most models on the maturity of agent security describe the controls a company will need in the future. They tend to miss, from my experience, the more difficult problem of describing the brownfield scenario: In what order should these controls be layered in conjunction with an identity and access management system that is already in place? If the control plane is unaware of which agent is acting, who delegated the work, what task the agent is to perform, and what credentials are being used, then the context is incomplete.
Think about routing agent traffic via a new runtime gateway. A finance-reconciliation agent tries to alter a record in production. The gateway authenticates the user token and checks the API call. What it can’t 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. The gateway is there, but its set of supports seems absent, so a costly control is applied to a very small part of the whole picture.
Related: Meta AI unveils efficient EvoHarness-RL agent
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. Identity specifies which actor placed the call. Delegation is the answer to whose authority it acts, and for what reason. Once that connection is cut off, the downstream logs attribute the reconciliation agent to the employee whose token it borrowed, and every action it takes is attributed to someone who did not start it.
A six-step sequence for safer agent deployments
I call this process dependency-gated deployment. Upstream exit tests must be satisfied before any downstream control is considered operationally complete. Concurrent development of downstream controls is permissible. Here are the six gates, and the proof that they work:
- 1. Agent inventory and accountable ownership: Every production agent has a named owner, purpose, approved tools, and lifecycle state.
- 2. Distinct agent identity plus delegation context: The system can identify the agent, its owner, and the principal it is acting for.
- 3. Task-scoped, short-lived credentials: A compromised agent cannot reach resources unrelated to its assigned task.
- 4. Attributable telemetry: A completed task can be reconstructed from initiation to downstream effect.
- 5. Runtime action enforcement: Policy decisions incorporate agent, principal, task, and action context, not just token validity.
- 6. Behavioral baselines and cross-system kill path: The agent’s effective authority can be stopped everywhere it reaches.
The last control from the chain cannot be applied first to close the gap between how security is applied to humans and how it is applied to agents. In Okta’s 2026 survey, only 34% of executives said their organization always applies the same level of security rigor to its agentic workforce as to its human workforce. This suggests that organizations must prioritize attribution and inventory before attempting to enforce complex policies. Designing a whole new identity program is unnecessary. If the existing identity provider doesn’t treat agents as native object types, begin with an authoritative registry linked to the existing workload identities. Following this, extend agent and task identifiers as trusted execution contexts, implement short-lived credentials to mitigate inherited privileges, and include those identifiers in tool-call logs for subsequent gateway ingestion. The dependency model remains unchanged as vendor support matures.
Access scope in the dependency chain is more important than context-aware runtime enforcement. With regard to the 2026 Teleport study involving 205 security leaders, the access scope surpasses the predictive capacity of industry, maturity, or self-assurance concerning predicting AI-related incidents. For example, organizations with over-privileged AI reported a 76% incident rate, whereas AI incidents occurred in 17% of organizations under the least privilege. This indicates that restricting authority to the specific task at hand is a more effective defense than waiting to detect anomalies after they occur.
Behavioral baselines are developed last because distinguishable and attributable agent activity must be established to set a standard. Then, security teams are able to identify anomalous patterns of tool usage, unexpected cross-domain access, and deviations from their assigned tasks. Containment is more than just the disabling of a single directory object: A proper kill path entails disabling the agent’s identity, invalidation of active and derived credentials, blockage of tool activation, termination of active tasks, and isolation of the workload that contains the agent. The most stringent controls should be applied at irreversible boundaries — payments, access policy changes, deletions, modifications of the production environment, and data exports. 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 task. This can be implemented using identity access management (IAM) features such as workload identity, token exchange, conditional access, and time-bound entitlements which the organization already possesses.
Related: Prompt injection tops security threat lists
Immediate steps for implementation
Begin with the agents you can actually name. For each one, record the owner, responsibility, lifecycle stage, allowed tools, data domains, and sources of credentials. Bypass this step, and the organization will lose the first hour of incident response while they figure out what should have been obvious. The inventory identifies the asset that every control thereafter governs.
Add downstream enforcement ahead of required context breaks agent security. Maturity models describe the destination. A build order gets you there without breaking production along the way. By now, you should have the beginnings of an agent registry and perhaps your first insights on governance.
Test attribution. Find out if IAM and logging can tell each agent apart from the human or service that delegated the task. If this kind of differentiation is not possible, a gateway would be operating without any visibility. Reconstruct one completed agent task within an action chain, from start to finish, including downstream effects. Wherever the chain breaks is where your deployment falls short.
Nik Kale is a principal engineer specializing in enterprise AI platforms and security. Welcome to the VentureBeat community! Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise. AI agents hit limits of messy business data. Read more from our guest post program — and check out our guidelines if you’re interested in contributing an article of your own!
