AI Agents: Vulnerabilities Beyond Authentication – Risks of Drift, Data Exposure, and Memory Poisoning

There’s a noticeable trend regarding the deployment of agents: organizations tend to prioritize gateways as their first line of defense, yet they often are ill-equipped to manage them effectively. This issue arises because gateways rely on underlying identity and attribution systems, which frequently remain underdeveloped.

The initial layer of risk isn’t hypothetical. Just last June, a vulnerability within LiteLLM was added to the CISA’s catalog of Known Exploited Vulnerabilities after it was exploited in the field. This flaw allowed attackers to run commands on the host via the gateway, and when combined with another vulnerability, could be exploited without credentials. In one month, this single AI gateway revealed seven distinct vulnerabilities. Regrettably, this is the very layer that many organizations look to first when securing their AI agents.

When planning a secure agent architecture, it’s crucial that gateway controls aren’t positioned as the initial line of defense; instead, they should be ranked fifth.

Most frameworks assessing the maturity of agent security primarily outline the necessary controls future companies will need. However, they often overlook a more nuanced challenge: how to organize these controls effectively alongside an existing identity and access management system.

If the control plane lacks awareness regarding which agent is active, who authorized the actions, the tasks assigned to the agent, and the credentials utilized, the situation lacks essential context. While a gateway can prevent clear violations of policy, it often fails to discern between a legitimate action and one that, although technically appropriate, is operationally unsuitable.

A clear failure pattern emerges in how these controls are arranged for agent deployments: enforcement is implemented prematurely, before a comprehensive identity and attribution context is developed. The security of agents behaves like a dependency chain, where each control relies on context provided by prior systems.

An Inappropriate Starting Point

Consider the scenario of managing agent traffic through a new runtime gateway. A finance-reconciliation agent attempts to modify a production record. The gateway verifies the user token and examines the API call. However, it cannot ascertain that this request originates from an agent, that the agent has a restricted function, or that it is part of a sequence triggered by an untrusted source.

The credential appears valid, and the API call is allowed, yet the action contradicts the delegation’s original intent. Although the gateway is active, it lacks adequate supporting context, leading to costly controls applied to a limited aspect of the overall situation.

Restricting an agent’s privileges to match those of the human principal it serves is beneficial. Nevertheless, setting a ceiling on privilege does not establish distinct attribution. Multiple agents could function under a single individual’s permissions, yet still require unique identities, audit trails, behavior profiles, and paths for revocation.

Deployment with Dependency Gates

This process can be termed as “dependency-gated deployment.” Upstream requirements must be met before any further downstream controls can be deemed operationally effective. It’s acceptable to develop downstream controls concurrently.

Outlined below are the six gates, along with evidence of their effectiveness:

The six dependency gates for agent security controls, contextualized by preceding gates, as analyzed from production agent deployments.

Commence with Recognized Agents

Start by identifying production agents across open-source platforms, cloud solutions, SaaS offerings, and developer tools. Document who owns each agent, their responsibilities, lifecycle phases, authorized tools, data domains, and credential sources.

Neglecting this initial step will cost organizations precious time during incident responses, as they scramble to ascertain what should have been clear. This inventory forms the basis for each control that follows.

Establish Agent Identity Without Neglecting Human Oversight

An agent should not be obscured within developer tokens, shared accounts, or human sessions. Merely acknowledging the source as an agent is insufficient. The control plane necessitates clear delegation context: Who assigned the task, what specifically was requested, and what resources the agent should access. Identity clarifies who initiated the call, while delegation specifies the authority behind it.

If this connection is severed, downstream logs will mistakenly attribute the actions of the reconciliation agent to the employee whose token was utilized, leading to misattributions.

Limit Authority Before Analyzing Behavior

Once an agent is identifiable, its capabilities must be restrained. Access should be time-limited and confined to necessary tools and resources. This can be executed through identity access management (IAM) features like workload identity, token exchange, conditional access, and time-based entitlements that organizations already possess.

According to a study involving a survey of security leaders, it was found that organizations with overly privileged AI agents reported incidents at a staggering 76%, compared to just 17% for those practicing strict minimal privileges. This data reveals that access scope within the dependency chain often outweighs the importance of context-aware runtime enforcement.

The key principle is monotonic delegation, where authority must either be preserved or decreased with each transfer of responsibility. In the case of the reconciliation agent, this means restricting an agent to just one ledger rather than allowing it access to everything the employee can reach.

Resolve Attribution Issues Before Automating Enforcement

Most auditing systems can track what resources were accessed and which credentials facilitated that access. In the agent deployments I’ve reviewed, this gate is commonly overlooked. Prior to adopting any adaptive runtime policies, ensure each relevant tool invocation is connected to the agent identity, the original principal, task ID, parent action, and outcome. Afterward, analyze the telemetry to trace one completed task from start to finish, inspecting initiators, executing agents, the authority under which actions were taken, the tools used, and results. In regulated environments, oversight without clear attribution becomes indefensible.

Now the Gateway Proves Its Worth

Utilizing registered identities, explicit delegation, scoped credentials, and accountable telemetry, the gateway can assess whether the agent is authorized to execute a particular action, for a specific principal, within a given task, and regarding the relevant resource. Although the user’s credentials may grant write access to the finance-reconciliation agent, the gateway’s context enables it to deem the action out of scope. This is where control offers the most value. Stringent controls should be implemented at crucial boundaries such as payments, policy changes, deletions, modifications to the production environment, and data exports.

Detection and Kill Paths Are Final Steps

Behavioral baselines should be developed last, as they require discernible and attributable agent activities to establish a standard. Security teams can then identify unusual patterns of tool usage, unexpected cross-domain access, and deviations from assigned tasks. Effective containment goes beyond merely disabling a singular directory object; a proper kill path entails terminating the agent’s identity, invalidating active and derived credentials, inhibiting tool initiation, halting active tasks, and isolating the workload encompassing the agent.

Begin Without Overhauling Your IAM

It’s not necessary to create an entirely new identity system. If the current identity provider doesn’t recognize agents as native object types, begin with an authoritative registry correlated to existing workload identities. From there, extend agent and task identifiers as trusted execution contexts, implement temporary credentials to limit inherited privileges, and include these identifiers in tool-call logs for future gateway processing. The dependency model can evolve as vendor support improves.

Control deficiencies are quantifiable. A recent survey indicated that only 34% of executives believe their organization applies equivalent security diligence to its agent workforce as it does to human employees. The final control in the chain cannot be applied first if this gap is to be closed.

Steps to Take in the Next 30 Days

Start with ten production agents. For each, document the owner, purpose, authorized tools, and credentials. This process will help form your initial agent registry and offer insights into governance.

Test for clear attribution. Assess if IAM and logging can differentiate each agent from the human or service that assigned the task. Without this clarity, a gateway operates in a state of invisibility.

Attempt to reconstruct a completed agent task within its action chain from start to finish, including downstream consequences. Identify where the chain fails to maintain continuity.

Implementing downstream enforcement prematurely breaks agent security. Maturity models illustrate the endpoint, while a structured build order will facilitate progress without disrupting ongoing production.

Nik Kale is a principal engineer focusing on enterprise AI platforms and security.