Back to resources
Blog

Network and identity each see half your cloud. Your attacker sees both.

Cloud access takes two tests at once, reachability and permission, but enterprises split them across two teams and tools. Your attacker fuses them by default. Here is why that gap is the real problem.

Offir Levy
June 29, 2026
Table of Contents

Enterprise security started with the network. Then the cloud arrived, identity became the new perimeter, and the industry decided the network had dissolved. It did not. Packets still flow, and routing tables still exist. Cloud access only makes sense when you combine network and identity together, because each one sees only half the picture.

For most of enterprise history, the network was the authorization layer: where you sat decided what you could reach. A lot of us at Act grew up in that world; the discipline goes back to the nineties. The cloud then made identity the primary control plane, and the industry’s focus followed it there for good reason, since most lateral movement and privilege escalation now runs through identity. But the network did not disappear. Identity and network just landed in separate tools, and neither one tells the full story of access in the cloud.

Every action takes two tests

To do anything in the cloud, an identity attached to a workload has to pass two tests at once: reachability from the network, and permission in IAM. That is the entire definition of access. Yet those checks are evaluated separately, by separate teams, using tools with no shared context. So nobody computes what an identity or a compromised workload can truly reach once both halves are fused. We obsess over logs that describe what happened in our environment, yet we remain completely blind to what could actually happen next.

It starts at the front door, and only gets worse inside

Verizon’s 2025 DBIR makes stolen credentials the most common way attackers get in. And it works every time. A stolen credential is still a very real identity: the identity tool waves the session past, and the network tool sees an allowed connection with no idea who is behind it. The intersection that would have caught it, a valid login from somewhere it has no business being, is the one nobody checks.

And that is just the front door; the same gap runs through every internal path. Because the cloud never stops moving - with workloads and identities spinning up and tearing down by the hour - the map you drew this morning is already stale by afternoon. The irony is that the boundaries meant to handle this already exist within your cloud: Security Groups, NSGs, SCPs, RCPs, guardrails, private endpoints etc. These native boundaries are designed to isolate production, scrutinize data access, and minimize the blast radius. They are owned by everyone, yet rarely actually used for granular segmentation, simply because no one can realistically compute reachability and permissions together across thousands of access paths, and we’re all scared of breaking production in the process.

A dream problem for AI, whether it’s theirs or yours

Reconnaissance and lateral movement are just mapping a huge graph and finding the paths through it iteratively, exactly the work machines are now really good at.

It gets more scary when you think about the timing. Open-source, open-weight models that approach Mythos-class capability are becoming available on the internet to everyone as we speak, shrinking time to exploit from months to minutes. CrowdStrike measured the average breakout time at 29 minutes in 2025, and the fastest at 27 seconds (!!), crediting AI for the acceleration: attackers combining the two halves you keep apart, at machine speed.

And it’s not just about attackers anymore. The agents your own teams are wiring into the cloud are already inside, and by nature, they go looking for data to crawl and levers to pull. Diligent and over-helpful, they use every permission handed to them, and in their clumsy way do things nobody intended: exposing a bucket, deleting a record, reaching into production through a role cloned months ago. An agent mimics software, not a human, yet they often get plenty of wildcards (*) in their policies, because the developers building them are pushed to ship fast, not secure.

Application-layer controls (like asking the agent nicely to not do stupid things) are helpful but will fail statistically. The control that holds 100% of the time lives at the infrastructure layer, in the identity and network boundaries set for the agent, the one part of the cloud you fully own. Set that boundary before you wire the agents in, because untangling it afterward is far harder.

Why Zero Trust stayed a principle, not a program

None of this is lost on the authorities. CISA and its Five Eyes partners urge organizations to assume attackers are now leveraging AI to increase the speed and complexity of their attacks, and lean on preventive zero trust and microsegmentation to contain lateral movement. They said it long before Mythos had a name; CISA’s Zero Trust Maturity Model already puts identity and network in one framework and pushes least privilege.

The trouble is that many security leaders have been on the zero trust journey and watched it fail time and time again… So they are skeptical. If you buy in to the network-identity disconnect thesis answer this: how can we strive for least privilege if we don’t even understand our current state of privilege?

Your adversary already has the better map

Minutes after coming in, your adversary holds a more accurate map of your estate than your own tooling does, because they combine reachability and permission as a matter of course while you have split that picture across two teams. Defenders should not accept that disadvantage.

Act closes that gap, combining network and identity into one view so you can finally see what can talk to what - and how to close down the attack surface safely.