AI Agents Are Rewriting the Rules of Lateral Movement

Security teams have spent decades asking whether an identity has too much access. AI agents raise a harder question: how can we determine which paths an autonomous system can discover, given the access it already has?

A person may try several ways to complete a task. A deterministic application follows the flow its developer wrote. But an AI agent is relentless in its pursuit of done. In May 2026, OpenAI announced that one of its models had disproved a 1946 Erdős conjecture in discrete geometry, largely by working through paths a mathematician would abandon as too tedious.

The same principle applies to cybersecurity. An AI agent can test thousands of actions, abandon failed routes, discover credentials, switch tools, and keep going. That persistence is part of what makes agents useful, but it also changes how we need to think about lateral movement. AI agent risk has two dimensions:

• Access defines the possible blast radius
• Autonomy determines how much an agent can do without a human in the loop

Either dimension can pose a risk on its own, but the combination changes the security model. Agent behavior cannot be reliably predicted, but identity and intent make access governable.

Autonomy Turns Access Into Exploration

People often grant agents more access and autonomy than necessary because they’re focused on achieving their goals as quickly and easily as possible. Instead of a reaAccsonable spread across both axes, the reality often looks like this:

Token Security's research, the Agentic Pulse, found that 51% of external actions taken by agentic chatbots authenticate with hard-coded credentials rather than OAuth, and that 65 percent of those agents have never been used since the day they were created.

The July 2026 Hugging Face incident showed this dynamic at a scale that would be difficult for a human operator to match. Autonomous agents, driven by a combination of OpenAI models during a cybersecurity evaluation, escaped their expected environment, established an external launchpad, exploited production infrastructure, harvested credentials, escalated privileges, and moved across cloud, Kubernetes, internal network, and source-control boundaries.

Hugging Face's technical postmortem reconstructed roughly 17,600 attacker actions. Most of those actions failed, but the agents tested paths, reached dead ends, changed direction, and returned to earlier leads. Enough of those attempts eventually connected into a viable route through several independent systems.

Broad permissions, reachable credentials, porous trust boundaries, and infrastructure that exposed more than its operators intended are all familiar weaknesses. In theory, a capable human red team could have exploited many of the same weaknesses, given unlimited time and resources. But AI agents can attempt more paths, replace failed approaches more quickly, and keep exploring long after a person might have stopped.

An investigation by METR and Redwood Research found another consequence of this persistence. About 1,200 agents intended to run in isolation discovered an unauthorized way to communicate via shared infrastructure. Of those, roughly 700 later participated in the attack. Nobody had designed that infrastructure as an agent collaboration layer, but the agents found and used it anyway.

That is the central security problem. Permissions describe what an identity can access directly. They do not reveal every route an autonomous system may assemble from the identities, credentials, tools, and trust relationships available along the way.

Blast Radius Extends Across Identity Chains

The same building blocks exist in ordinary enterprises. In one recent environment reviewed by Token Security, a sales agent had Salesforce access that matched its purpose: helping the sales team prepare for customer conversations. The agent also had access to Vercel, where its permissions were far broader than the task required.

Those Vercel permissions exposed a stored credential belonging to a different non-human identity. That identity held administrator-level access in Snowflake. The sales agent did not have an account, and no one had assigned it a Snowflake identity, but the path still existed:

Sales user > AI agent > Vercel tool > Stored Credential > Snowflake Service Identity > Account Administrator > Data

Reviewed one relationship at a time, these connections appeared unrelated. Together, they formed a highly dangerous access path that should never have existed.

Traditional access reviews ask bounded questions: Can this identity reach Snowflake? Does this service account need administrator rights? Can this application call this API? Those questions remain necessary, but an autonomous agent can combine the answers in ways that no human ever would.

The real blast radius of an AI agent, therefore, includes every reachable identity hop behind its direct permissions, and an inventory of grants attached to the agent captures only the first step. Test out Token Security for yourself with a demo of our AI Security platform.

Lateral Movement Can Be Legitimate Behavior

This access chain creates a second detection problem. Security teams have traditionally treated movement between unrelated systems as a warning sign. An identity accesses a new environment, retrieves a credential, assumes a different role, or touches a resource it has never used before. For a human user or a conventional workload, those events often justify investigation.

An autonomous agent may produce similar telemetry while completing an assigned task. Agents are expected to search for information, invoke tools, connect data across systems, and recover when one approach fails. Movement alone can no longer distinguish useful execution from hostile or unintended activity.

Security teams need to know what the agent was created to accomplish, who owns it, which identity it started with, which tools it could invoke, which credentials those tools exposed, and which resources became reachable. That complete chain shows whether the action aligns with the agent's purpose or constitutes privilege escalation.

Prompt filters and output controls address different parts of the agent stack. They can reduce unsafe inputs and responses, but they do not determine which systems an agent's identities and credentials can reach. Once an agent begins chaining tools across production systems, security depends on controlling the identities, permissions, and trust relationships that enable those actions.

Identity Is the Control Plane

Permissions describe capability, but do not describe purpose. Two agents can hold similar permissions yet carry very different risks because one is expected to modify infrastructure, while the other exists to summarize support tickets. An IAM system that sees only the grant may treat them as equivalent.

Intent-based security supplies the missing context. Each agent needs a defined purpose, a named owner, and access scoped to the work it is expected to perform. Security teams can then evaluate an action against the agent, the identity it uses, the resource it reaches, and the reason it exists. Identity is the only control plane that spans every system an agent touches, and intent determines whether the access makes sense.

This is also a lifecycle problem. Organizations need to discover agents as they appear, connect each agent to its human owner, understand the full access chain behind it, right-size permissions as its purpose changes, and revoke credentials when it is retired. A point-in-time review cannot keep pace with agents that are created, connected to new tools, and abandoned while their access remains active.

OWASP's Top 10 for Agentic Applications identifies identity and privilege abuse as a distinct agentic risk. The reason is straightforward: agents can inherit powerful identities, reach leaked credentials, and combine permissions across systems. Identity governance has to follow the complete chain rather than stop at the agent's first credential.

What Security Teams Should Do Now

• Discover every agent. Include shadow agents created by developers and business teams outside formal IT processes.
• Assign ownership. Tie each agent to a named person who is accountable for its purpose, access, and retirement.
• Map the full access chain. Trace the relationships among agent, identity, tool, credential, and resource behind every direct permission.
• Compare access with intent. Evaluate what the agent can reach against the job it was created to perform, rather than against its creator's entitlements.
• Enforce continuously. Right-size permissions as they drift, revoke unused credentials, and treat shared caches, repositories, and message buses as trust boundaries between agents.

Autonomy can be useful, and constraining every agent to behave like a script would remove much of the value organizations expect from agentic AI. The stronger approach is to govern the identities and access paths that autonomy can use.

Organizations that understand those paths can let agents reason, adapt, and act without giving them an unknown blast radius. Organizations that cannot will learn what their agents can reach only after the agents find it.

Token Security helps organizations discover agents, understand intent, and complete access paths, and continuously enforce least privilege and lifecycle governance.

Note: This article has been expertly written and contributed by Itamar Apelblat, Co-Founder and CEO, Token Security.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.