AI Changes the Economics of Lateral Movement

Everyone is talking about AI-powered vulnerability discovery, offensive tooling, and how attackers are going to move faster than defenders. That part is probably true.

But AI has not created a brand-new cyber security problem.

It has accelerated an old one: unrestricted lateral movement inside flat or poorly contained environments.

For years, attackers needed time, patience, manual reconnaissance, and technical skill to move through enterprise environments. They had to understand trust relationships, work out management paths, identify useful pivots, and move carefully enough to avoid detection.

AI compresses that process dramatically.

Reconnaissance accelerates. Exposure mapping accelerates. Attack path analysis accelerates. Exploit chaining accelerates.

That means architecture matters more than ever.

The real issue is reachability

A vulnerability does not exist in a vacuum.

Exploitability depends on reachability.

Reachability depends on architecture.

Architecture changes risk materially.

A vulnerable internet-facing system with unrestricted east-west access carries very different operational risk compared to the same workload sitting behind clear segmentation boundaries with tightly constrained communication paths. That does not remove risk, but it changes it materially.

This is why AI-era security needs exposure-aware thinking, not just vulnerability enumeration.

In many mature environments, the question is no longer just:

• Do vulnerabilities exist?

The more useful question is:

• What can those vulnerabilities actually reach?

What customers often discover first

For customers who are brand new to segmentation or containment, the first win is usually visibility, not enforcement.

Customers often discover things they assumed were already controlled:

• Unexpected server-to-server traffic.

• Direct database access from user devices.

• Internet-reachable workloads they thought were internal-only.

• Old services that are still reachable inside the network.

• Shared management paths with far broader reach than anyone expected.

That visibility creates the business case for action.

You cannot manage what you do not measure. And once teams see those exposure paths clearly, they usually cannot unsee them. That is often the turning point where segmentation stops looking like a security project and starts looking like basic operational risk reduction.

Convenience creates exposure

Some of the most important exposure paths are not dramatic. They are normal, convenient, and long accepted.

A common example is a user on a laptop connecting directly to an SQL database.

From a convenience perspective, that can seem reasonable. It is fast, flexible, and often grew out of a practical business need.

From a security perspective, it creates a direct path from a highly exposed endpoint into a critical system.

If that laptop is compromised, the database may be one step away. In an AI-accelerated threat environment where endpoint compromise, credential theft, and automated path analysis are all getting easier, that kind of connection is not just a technical shortcut. It is an architectural exposure.

The answer is not always to ban access outright. Sometimes there is a valid business process that needs to happen.

But there should be a process to get through:

• Access should be mediated, not wide open.

• The path should be visible.

• The trust should be limited.

• The activity should be monitored.

• The blast radius should be small if the endpoint is compromised.

That is what mature containment looks like in practice.

Shared platforms multiply the problem

This issue becomes even more serious in service-provider and shared-platform environments.

In one environment reviewed, a managed IT provider had multiple customers running on its own virtual infrastructure with effectively no meaningful separation between tenants. If one customer had been compromised, an attacker could potentially have moved laterally into other customers’ systems and data.

That is not a small design flaw. That is shared blast radius.

In those situations, one customer’s incident can become everyone’s incident very quickly.

The practical response was not to wait for the provider to redesign everything. The response was to segment the customer’s environment separately, establish its own trust boundaries, and reduce the ability for compromise elsewhere on the platform to become compromise here.

That is an important point for enterprise buyers and service providers alike: sometimes the first meaningful security improvement is not fixing the whole world. It is creating containment around the part you can control.

Compliance is one driver, visibility is another

Some organisations pursue separation and segmentation because they have to.

That might be due to ISO-aligned controls, contractual isolation requirements, regulated data handling, customer separation obligations, or general governance expectations. In those environments, the need for separation is already accepted. The task is to design and implement it properly.

But many customers do not start there.

Many move only after visibility makes the problem undeniable.

They see a direct laptop-to-database flow.

They see unexpected server-to-server communication.

They see an old internal service still reachable from places it should not be.

They see management paths extending much further than intended.

At that point, the conversation changes.

Instead of asking, “Do we really need segmentation?”, they start asking:

• Why is this path here?

• Who approved this trust relationship?

• Does this actually need to exist?

• What is the safest way to keep the business process without keeping the exposure?

That is a much more valuable conversation.

The first step is usually visibility

For customers new to this space, the first win is rarely broad enforcement on day one.

It is visibility.

The first practical step is to understand:

• What is talking to what.

• Which paths are expected.

• Which paths are surprising.

• Which flows support real business processes.

• Which flows simply exist because nobody ever removed them.

This is where lightweight visibility work can be extremely valuable. It gives security teams, infrastructure teams, and service providers a common view of the environment as it really operates, rather than as it was originally designed or documented.

Once that view exists, the next steps become much easier to prioritise:

• Remove obviously unnecessary trust.

• Reduce broad east-west access.

• Put proper process around sensitive paths.

• Separate customer environments where shared infrastructure creates cross-tenant risk.

• Build segmentation around critical systems before an incident forces the issue.

For many organisations, that visibility phase is what unlocks action. It makes the commercial case, the technical case, and the operational case at the same time.

Why AI raises the stakes

None of these principles are new.

Segmentation is not new.

Containment is not new.

Least privilege is not new.

Blast-radius reduction is not new.

What AI changes is the economics.

It reduces the time and effort required for attackers to identify pathways, chain opportunities together, and move through environments that were already too open.

That means environments with unnecessary reachability become more dangerous, faster.

The organisations that respond well will not necessarily be the ones with the loudest AI messaging. They will be the ones that understand their own architecture, can see their own exposure paths, and are willing to reduce unnecessary trust before an attacker does the mapping for them.

What matters now

In practical terms, the path forward is not mysterious.

• Start with visibility.

• Identify what should not be talking to what.

• Reduce unnecessary reachability.

• Put process around sensitive access paths.

• Segment where compliance requires it.

• Segment where visibility shows the risk is already there.

• Treat architecture as a control, not just a diagram.

Because in an AI-enabled threat landscape, the most important question is often not whether a system is vulnerable.

It is what that system can reach next.

In the next article, the focus shifts to secure enclaves, compensating controls, and the reality that not every system can be patched or modernised on demand. That is where containment becomes not just useful, but operationally necessary.