The Breach Is Inevitable. The Blast Radius Is Not.
Why microsegmentation still matters in the AI era, and why the path forward has to be smaller, smarter, and more honest.
If you have ever been part of a microsegmentation project, you know the hard part usually does not start with the technology. It starts in a room.
Network teams are there. Security is there. Application owners are there. Maybe cloud, infrastructure, identity, and operations are there too. Everyone is trying to answer what sounds like a simple question:
What needs to talk to what?
Then the room gets quiet, because the real answer is usually something like this:
We think this application talks to that database. We think this service account is still needed. We think this port is required. We think that flow is legitimate. We think the business owner is still the same person. We think turning this off would break something.
That is the truth of microsegmentation. It is not hard because the concept is wrong. It is hard because the environment is complicated, undocumented, and constantly changing. Most organizations do not have one source of truth for who uses what, what talks to what, which dependencies are real, and which access paths are still justified.
Microsegmentation asks the enterprise to know itself. That is why it has been so difficult.
Microsegmentation was always part of the Zero Trust promise
Zero Trust has always had a practical goal underneath the philosophy. Assume something will get compromised. Assume credentials will be stolen. Assume malware will land somewhere. Assume an attacker will find a way in. Then design the environment so that compromise does not automatically become movement.
That is where microsegmentation matters. CISA describes it as a Zero Trust capability that protects smaller groups of resources, reduces attack surface, limits lateral movement, and improves visibility. NIST's Zero Trust guidance adds a point that is easy to overlook: Zero Trust focuses on protecting resources, not network segments, because network location is no longer the main factor in whether something should be trusted.
That is the shift. Traditional segmentation asked whether something was inside or outside, whether a subnet was trusted, whether a branch was part of the corporate network. Zero Trust asks something more specific:
Should this identity, on this device, in this context, access this resource, for this purpose, right now?
Microsegmentation is one of the ways that idea becomes real. It turns "assume breach" from a slide into an architecture.
The problem has always been visibility
The first step is visibility. That is true for almost everything in security, but it is especially true here. You cannot segment what you cannot see.
The challenge is that visibility is scattered. Firewall logs know part of the story. The CMDB knows part of the story. EDR, IAM, and cloud telemetry each know part of the story. Application owners know part of the story, although sometimes that knowledge left with someone who changed roles two years ago. None of those systems tell the whole truth by themselves.
And even when you do get traffic visibility, there is another problem. Observed does not always mean allowed. Just because two systems are talking does not mean they should be. Just because a flow has existed for five years does not mean it is still required. Just because no one has complained about it does not mean it is safe.
That is one of the traps. If we build policy only from observed behavior, we may end up formalizing bad behavior, preserving old access paths, stale dependencies, shadow integrations, and risky service account usage simply because they were already there. Visibility comes first, but visibility is not the finish line.
Microsegmentation is really a truth problem
This is where the conversation needs to be more honest. Microsegmentation is not just a network problem. It is an organizational truth problem. To do it well, teams have to answer questions that usually live across multiple parts of the business: Who owns the application? What data does it process? Which users need access? Which services depend on it? Which flows are business critical, and which are just historical leftovers? Which accounts are still valid? Which paths would an attacker use first? Which systems should never be able to talk to each other?
These are not just firewall questions. They are business, architecture, identity, and operations questions. That is why so many segmentation projects stall. The technology may be capable of enforcing the policy, but the organization struggles to define the policy with enough confidence to turn enforcement on.
No one wants to be the person who breaks payroll, takes down manufacturing, blocks a customer portal, or interrupts a clinical system because a dependency was missed. So the project slows down. The maps get reviewed. The exceptions grow. The enforcement date moves. The policy stays in monitor mode. Everyone agrees microsegmentation is important, and then the environment keeps changing.
Start with one blast radius
The mistake is trying to segment everything at once. The second mistake is making a list of every important system and calling that a starting point. Identity systems, backup platforms, production databases, developer environments, cloud control planes, security tools, and AI infrastructure all matter. But for most enterprises, any one of those could become its own project. Saying "start there" is not specific enough.
A better starting point is not an asset category. It is one movement path that should not exist. For example:
A compromised user workstation should not be able to reach the backup management console.
That is specific. It has a source, a destination, a risk, and a business reason to care. Now the work becomes more practical. Which users or systems actually need to reach the backup platform? Which admin paths are required? Which ports and protocols are in use? Which service accounts are involved? Which access is historical but no longer needed? Which flows would break recovery if blocked, and which would help an attacker if left open?
That is still hard work, but it is bounded hard work. The team is not trying to segment the entire enterprise. It is trying to reduce one dangerous blast radius.
That is how microsegmentation should start. Pick one unacceptable path. Study it. Monitor it. Validate the owners. Understand the dependencies. Write the narrowest policy you can. Test it. Enforce it carefully. Learn from it. Then pick the next path.
This is less exciting than saying the enterprise needs full microsegmentation across every critical system. But it is much more honest. Real progress usually starts with one control that survives contact with the business.
AI makes the need stronger
AI changes this conversation because it increases the speed of both attack and defense. Microsoft's 2025 Digital Defense Report warns that AI agents could help threat actors automate parts of the attack lifecycle, including reconnaissance, vulnerability scanning, and exploitation at scale. Anthropic reported a 2025 case where attackers used AI's agentic capabilities not just as an advisor, but to execute cyberattack activity.
That matters for microsegmentation. If attackers can use AI to move faster through discovery, exploitation, and lateral movement, defenders cannot rely only on static maps, quarterly reviews, and manual policy cleanup. The speed mismatch gets too large.
AI also changes the environment we are trying to protect. An AI agent may not move laterally like a traditional attacker on a flat network. It may move through permissions, tokens, APIs, SaaS integrations, plugins, memory, and workflow automation. That is still movement, and it still needs containment.
Can AI help us finally do this?
I think the answer is yes, but not in the way vendors are probably going to market it. AI is not going to magically solve microsegmentation. It is not going to understand every business process, make perfect policy decisions, and remove all the risk of enforcement. That is not realistic.
Where AI can help is with the part humans have always struggled to keep up with: making sense of the environment. Take the backup example. A team wants to know whether user workstations should be able to reach the backup management console. Before enforcing a rule, they need to understand the real paths into that platform: who logs in, from where, through which jump host, using which account, over which protocol, at what time, and for what operational reason. That investigation usually requires pulling data from several places and stitching the story together manually.
AI can help with that kind of work. It can summarize observed flows, find unusual access paths, compare behavior across similar systems, flag dependencies that do not match the expected pattern, and simulate what might break if a proposed rule is enforced. That is useful. Not because AI replaces the architect, but because it gives the architect a better starting point. Most teams do not need another blank policy matrix. They need a clearer view of what is actually happening, what appears to be required, what looks risky, and where enforcement can happen without breaking the business.
But AI cannot become the unchecked policy engine
This is the part we need to be careful about. Using AI to recommend segmentation policy is one thing. Letting AI silently rewrite production enforcement rules is something else. That is not Zero Trust. That is just moving trust to a different place.
If AI is going to help with microsegmentation, it needs to operate inside guardrails. It should recommend, explain, simulate, prioritize, and detect drift. It should help humans and policy systems move faster with better context. But high-impact changes still need governance. The model should not be the final authority on what is allowed. The policy cannot be "because the AI said so." Security teams need explainable recommendations, change control, business ownership, and deterministic enforcement.
AI can help us get closer to the truth. It should not become the truth.
For AI, start just as small
The same "one movement path" thinking applies to AI. Do not start by saying, "We need to segment all AI infrastructure." That is too broad. Start with a specific risk:
An AI agent that summarizes support tickets should not be able to call production billing APIs.
That is a real segmentation problem. Not in the old sense of one subnet talking to another, but in the newer sense of an identity, tool, or workflow reaching into a system it should not be able to affect. From there, the same questions apply. What is the agent supposed to do? Which system does it need to access? Does it need read access or write access? Does it need to call an API, or only retrieve approved content? Can it trigger a workflow? Can it reach sensitive records? Can it act without human approval? Can its access be revoked quickly?
This is where microsegmentation starts to evolve. It is no longer only about what network can talk to what network. It is about what identity, tool, agent, or workflow can reach a resource, and what it is allowed to do when it gets there. The unit of control gets smaller. The policy has to get smarter. But the starting point is still the same: pick one movement path that should not exist and remove it.
The future has to be knowledgeable, adaptive, and strict
Microsegmentation has to become knowledgeable. That does not mean knowing everything about everything. It means knowing enough about a specific path to make a confident policy decision. Who is the source? What is the destination? What identity is being used? What business process depends on it? What risk does it create? What would happen if it were blocked?
It has to become adaptive. That does not mean policies constantly changing themselves in the background. It means the architecture can recognize when something changes and bring that change back into review. A new workload appears. A SaaS integration is added. An AI agent starts calling a new tool. A service account begins behaving differently. A vulnerability changes the risk of a system that was considered low priority yesterday. The system should notice.
But it also has to remain strict. Adaptive cannot mean permissive. It cannot mean the system keeps opening access because something asked for it. It cannot mean every new dependency becomes legitimate just because traffic was observed. The end state still has to be least privilege. Deny what is not required. Allow what is known, justified, and monitored. Reduce the blast radius before an attacker gets the chance to test it.
That balance is difficult. Knowledgeable, adaptive, and strict. All three are needed.
The human part matters
We do not talk about this enough. Security teams are asked to reduce risk without breaking the business. Network teams are asked to enforce controls on systems they may not own. Application teams are asked to explain dependencies that were never documented. Business leaders are asked to approve restrictions they may not fully understand until something stops working. That is why trust between teams matters.
Microsegmentation requires people to admit what they do not know, and that can be uncomfortable. It is easier to say "we need more visibility" than to say "we do not actually understand this application well enough to enforce policy yet." But that honesty is where the work begins.
AI may help us see patterns faster, find dependencies sooner, and reduce the manual burden. But the human part does not go away. Someone still has to decide what risk is acceptable. Someone still has to own the application. Someone still has to approve the policy. Someone still has to say, "Yes, this access is required," or "No, this should not exist." The technology can help. The accountability still belongs to us.
The bottom line
Microsegmentation has always been one of the clearest promises of Zero Trust. Limit implicit trust. Reduce lateral movement. Protect critical resources. Contain the blast radius when something goes wrong. The concept has never been the hard part. The hard part has been knowing the environment well enough to enforce the concept without breaking the business.
That is why the path forward cannot be "segment everything." It has to be more practical than that. Pick one unacceptable movement path. Understand it. Validate it. Test it. Enforce it. Learn from it. Then move to the next one.
AI may help us make progress by discovering patterns, mapping dependencies, simulating policy impact, and detecting drift at a speed humans cannot match on their own. But AI does not remove the need for governance. It increases it. If AI is going to help protect us from AI-enabled threats, it has to be constrained by the same principles we are trying to enforce everywhere else: least privilege, continuous verification, explicit policy, strong visibility, and no implicit trust.
The future of microsegmentation will not be one giant enterprise policy project. It will be smaller, more focused, and more adaptive. One movement path at a time.
Because the breach may be inevitable.
The blast radius is not.
