The Autonomy Paradigm: AI Agents Are Changing What Lateral Movement Looks Like

We’ve been looking at a lot of AI agents inside enterprise environments lately, and there’s one pattern I keep coming back to: the more autonomy we give an agent, the harder it becomes to predict how it will use its access.

For years, we’ve thought about access in a fairly straightforward way. An identity has permission to a system or resource, and we ask whether that permission is necessary, whether it is too broad, and whether it is actually being used. For people, this has defined Role-Based Access Controls for decades.

AI agents change this equation because they can decide how to use the access available to them in unexpected ways. They can try one path, fail, try another one, discover a credential, use a different tool, and keep going until they accomplish the goal.

And they do this a lot.

The number of actions an agent can take matters almost as much as the permissions it starts with. A human might try a handful of ways to solve a problem. A deterministic application will generally execute the flow its developer created. An autonomous agent can test hundreds or thousands of possible actions and access paths. A real-world example of this is how ChatGPT solved an Eros math problem by attempting approaches that would be too tedious for a human. This AI involvement changes what lateral movement looks like.

At Token, we’ve been thinking about risk across two dimensions: how much access an agent has, and how much autonomy it has to decide what to do with that access. A recent survey reveals that security leaders believe that “70% of AI systems have more access than a human in the same role.”

That is already a problem. But what becomes much more interesting is what happens when excessive permissions meet autonomy and a very high volume of actions.

An agent with broad permissions but a narrow, predefined workflow, with a person in the loop, is still reasonably predictable. Give that same agent freedom to decide how to complete a task, and it can start finding access paths that neither a human nor the developer of a deterministic application would necessarily have considered.

The security question then becomes much bigger than “What can this agent access?”

We need to understand the complete path the agent can take to a resource, including every identity, permission, and system it can use along the way.

Hugging Face gave us a glimpse

The Hugging Face incident this summer is probably the clearest example we have seen of why this matters.

Autonomous agents were running as part of a cybersecurity evaluation. Instead of following the expected path to solve the challenge, they found another way to accomplish the objective. The agents escaped their original sandbox, found external infrastructure to use as a launchpad, exploited Hugging Face’s infrastructure, harvested credentials, escalated privileges, and began moving laterally between systems.

Hugging Face reconstructed roughly 17,600 actions from the campaign. The important part is that most of those actions did not lead anywhere. The agents tried paths, hit dead ends, changed direction, and tried something else. Eventually, enough of those attempts connected.

At one point, the agents went from access inside a production pod to cloud and Kubernetes identities. They inspected service-account tokens, reached node credentials, found other service identities and tested what those identities could do. Hugging Face documented three separate lateral-movement techniques, including 1. Node impersonation and CSI token theft, 2. Forged identity tokens, and 3. Supply-chain write access.

A human attacker could have exploited many of the same weaknesses. What changed was the scale. Hugging Face described an agent testing thousands of actions, replacing failed paths quickly and repeatedly coming back to previous leads.

This is an important point for enterprise security. The individual weaknesses were familiar: a permission that was too broad, a credential that could be reached, a trust relationship that went further than expected.

The agent was simply very good at finding a chain between them.

The same building blocks are in normal enterprise environments

You don’t need an incident like Hugging Face to see how this can happen. We recently looked at a sales agent inside an enterprise environment. The agent was built to help the sales team with deal preparation and had access to several tools. That sounds pretty normal.

What became interesting was when we stopped looking at each connection individually and followed the access path. The agent had a Salesforce tool, which made sense for its purpose. In parallel, it had access to Vercel. The permissions it inherited in Vercel were far broader than what the agent needed for sales preparation.

Those permissions gave the agent access to resources inside Vercel that contained an existing Snowflake credential. That credential belonged to another non-human identity and had administrator-level access in Snowflake.

So an agent that was created to help prepare for sales calls had a potential path that looked something like this:

Sales user → AI agent → Vercel tool → privileged Vercel identity → secret/API key → Snowflake service identity → Account Admin → Snowflake data

Salesforce sat alongside that path as another legitimate tool available to the same agent:

Sales user → AI agent → Salesforce identity → Salesforce

The Salesforce access was expected. The path through Vercel into Snowflake was not.

This is the part that gets lost when we review permissions one system at a time. The sales user did not need to have a Snowflake account. The agent did not need to have a Snowflake identity assigned directly to it. The agent could potentially reach Snowflake because one identity gave it access to a resource that exposed another identity, and that second identity had much broader permissions.

Adding another identity hop makes the problem much harder to spot.

Access is becoming a chain

This is where I think our traditional way of looking at least privilege starts to struggle.

We normally ask questions one relationship at a time:

• Can this identity access Snowflake?
• Does this service account need admin?
• Can this application call this API?

Those are still important questions, but an autonomous agent can combine the answers. It can have legitimate access to one tool and excessive permissions inside that tool. Those permissions may expose another credential, which may represent another identity with access somewhere else. That application may have another trusted connection.

Eventually, the agent reaches a resource that appears several hops away from where it started. So the real blast radius of an agent is not defined only by its direct permissions. It includes the identity hops and access chains behind those permissions.

Agent → tool → identity → secret → another identity → application → another resource.

And potentially another tool and another identity after that.

This is very similar to the way we already think about attack paths, but at massive scale and complexity. Individual permissions may look relatively harmless. The risk appears when those permissions are connected and create a path for privilege escalation or lateral movement. Token’s attack-graph work is specifically designed to connect those risks into lateral-movement paths rather than evaluate identities only in isolation.

Agents make this problem more urgent because they can actively search those paths.

Lateral movement can now be legitimate behavior

There’s another complication. Security teams are trained to treat lateral movement as suspicious: An identity starts touching new systems. It retrieves a credential. It accesses something it has never accessed before. It moves between environments. Those are good reasons to investigate a human user or a compromised workload.

An autonomous agent may do some of the same things while simply trying to complete its task. We want agents to search for information, to use tools, and connect information across systems. We want them to recover when one approach doesn’t work and find another way to accomplish the goal. That is autonomy.

So seeing an agent move from one system to another is no longer enough to tell us that something is wrong. We need to know the complete path.

What was the agent trying to accomplish? Which identity did it start with? What could that identity access? Which tools could the agent invoke? Which identities were behind those tools? Which credentials could those identities reach? What additional permissions did those credentials introduce? And, eventually, which resources become reachable?

That is what tells you the agent’s actual blast radius.

The goal isn’t to make agents less autonomous

There is an obvious answer to all of this: constrain the agent. Give it one tool. Define every workflow. Remove anything it doesn’t explicitly need.

That works, but it also misses much of the reason companies are excited about agents in the first place. The value of an agent is its ability to figure things out. We want it to reason about a goal, decide what information it needs, choose the right tools, and adjust when something doesn’t work.

Security has to support that without assuming the access path will always look the way the developer expected. That means understanding every possible hop from the agent to the resource, including the identities and credentials in between. It means finding permission misconfigurations before an agent discovers them. And it means being able to decide whether an action makes sense based on the agent, its purpose, the identity it is using, and the resource it is trying to reach.

Token Security already correlates agents, humans, identities, secrets, permissions, and resources because those relationships are what expose this type of blast radius. We’ve spent years trying to stop attackers from moving laterally through organizations.

Now we’re introducing software that can take thousands of actions, discover unusual access paths, switch between identities, and find its own way to a goal.

That capability is exactly what will make autonomous agents useful. It’s also why understanding the entire identity and access chain, all the way to the resource, will become one of the biggest security challenges of the agentic era.

‍