AI agents that pass authentication can still drift, expose data, or get memory-poisoned
Our take
The recent article highlighting the misprioritization of security controls for AI agents resonates deeply with the challenges we're seeing across the industry. There’s a clear repeating trend: organizations rush to implement gateways as the primary defense, overlooking the foundational need for robust identity and attribution layers. This is akin to installing a sophisticated lock on a door without first ensuring you know who has keys and what they're authorized to access. The CISA addition of a LiteLLM flaw to its vulnerability catalog [AI agents need their own identity before they need a gateway] serves as a stark reminder that this isn’t a theoretical concern; attackers are actively exploiting these gaps. This underscores the importance of a layered approach, where gateways are just one piece of a much larger puzzle. The author's assertion that gateways should be the *fifth* control, not the first, is a crucial shift in perspective.
The core issue lies in the sequencing of controls. The article rightly points out that enforcement is often applied prematurely, before the necessary context – agent identity, delegation details, and task scope – has been established. This creates a dependency chain where each control relies on the context generated upstream. Imagine a finance-reconciliation agent attempting to alter a production record; a gateway might authenticate the user token and check the API call, but it lacks the awareness that the request originates from an agent executing a limited function or is part of an untrusted tool chain. This highlights a fundamental flaw – the gateway operates in a vacuum, unable to distinguish a justified action from one that is technically permissible but operationally inappropriate. It's a problem compounded by the tendency to grant agents broad permissions mirroring those of the human principal, further blurring the lines of accountability and making detection significantly harder. We’ve explored this further in our piece about the need for agent identities [Cloudflare Extends AI Search to Make it Easier for Agents and Developers to Search Custom Data], emphasizing the importance of treating agents as distinct entities with their own governance.
The author's proposed six-gate dependency model offers a practical roadmap for implementing secure agent architecture. Starting with agent inventory and accountable ownership, progressing through distinct agent identity, task-scoped credentials, attributable telemetry, runtime enforcement, and finally, behavioral baselines and kill paths, provides a logical and actionable framework. The emphasis on "dependency-gated deployment" – requiring upstream exit tests before downstream controls are considered complete – is particularly insightful. This shift in mindset moves beyond reactive security measures to a proactive approach that prioritizes context and attribution. The analogy of shrinking authority before inspecting behavior perfectly encapsulates the principle of least privilege and reinforces the idea that limiting an agent’s capabilities to the bare minimum required for its task is paramount. The connection to the Teleport study, highlighting the increased incident rate associated with over-privileged AI, provides compelling empirical evidence supporting this approach. Even more so, the discussion of how organizations can leverage existing IAM infrastructure [py-evoFE: Automated Evolutionary Feature Engineering for Tabular ML in Python (Genetic Algorithms + Scikit-Learn + Polars) [P]] demonstrates a practical, pragmatic approach that minimizes disruption and maximizes return on investment.
Ultimately, this article serves as a critical wake-up call for organizations embracing AI agents. It's a reminder that true security isn’t about deploying the latest, flashiest technology; it’s about building a solid foundation of identity, attribution, and control. The call to action – starting with the agents you *can* name and testing attribution – is a tangible first step. As AI agents become increasingly integrated into critical workflows, the ability to accurately track and attribute their actions will be paramount. The question moving forward is not just *how* to secure these agents, but *who* is ultimately responsible for their actions, and how can we ensure accountability across the entire agent lifecycle?
There is a clear 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. This is the layer many enterprises reach for first to secure their AI agents.
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. A gateway may block clear policy violations, but will struggle to distinguish a justified action from one that is technically permissible but operationally inappropriate.
The pattern of failure is clear when sequencing these controls for agent production deployments: Enforcement is taken early, while the identity and attribution context it depends on has yet to be developed. Agent security functions as a dependency chain, with each control depending on context generated upstream.
The wrong starting point
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.
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.
Dependency-gated deployment
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:
Gate | Control | Operational proof it works |
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 six dependency gates for the agent security controls. Each control is contextualized by the gates above it. From the author's analysis of production agent deployments.
Start with the agents you can actually name
To begin, recognize the production agents in open-source frameworks, cloud offerings, SaaS services, and developer tools. For each, 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.
An agent needs its own identity, but it cannot lose the human behind it
An agent 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 the authority to access. 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.
Shrink authority before you inspect behavior
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.
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 access scope in the dependency chain is more important than context-aware runtime enforcement.
The primary principle is monotonic delegation. Every transfer of responsibility must preserve or diminish authority; under no circumstances should it increase authority. For the reconciliation agent, this means an agent who can view one ledger as opposed to one who inherits the employee's access to all systems the employee can access.
Fix attribution before automating enforcement
Most audit stacks can capture what resource was accessed and which credential allowed access. In the agent deployments I have reviewed, this is the most commonly missed gate. Prior to utilizing an adaptive runtime policy, link any relevant tool invocation to the agent identity, initiating principal, task id, parent action, and outcome. After doing so, examine the telemetry: For one completed task, see if you can track down the initiator, the agent who executed it, the authority under which the action was taken, the tools utilized, and the outcome. In regulated environments, oversight that is not attributed cannot be justified.
Now the gateway earns its keep
The gateway can use registered identities, explicit delegation, scoped credentials, and attributable telemetry to question if this agent is authorized to perform this action, for this principal, within this task, involving this resource. Although the user's credentials may provision write access to the finance-reconciliation agent, the gateway has situational context and so determines that it is out of scope. This is control's point of greatest value. The most stringent controls should be applied at irreversible boundaries — payments, access policy changes, deletions, modifications of the production environment, and data exports.
Detection and the kill path come last
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.
Start without replacing your IAM
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.
Control gaps are measurable. 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. The last control from the chain cannot be applied first to close that gap.
What to do in the next 30 days
Begin with 10 production agents. For each one, identify the owner, purpose, approved tools, and credentials. 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.
Adding 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.
Nik Kale is a principal engineer specializing in enterprise AI platforms and security.
Read on the original site
Open the publisher's page for the full experience