Here's a scenario we've walked through with more clients than we can count. Their cloud is well run. Workloads are patched, images are scanned, the posture dashboard is reassuringly green. Then we start an assessment, and within a couple of days we've moved from a single low-value foothold to something that should have been unreachable — not by exploiting a workload, but by walking a chain of identities and permissions that everyone had stopped looking at years ago.

The workload was never the point. In the cloud, identity is the perimeter, and most organisations are still securing the wrong thing.

The path an attacker actually takes

When people imagine a cloud breach they picture something dramatic — a zero-day, a clever exploit against a running service. The reality is almost always more mundane and more embarrassing. It's a chain of small, individually reasonable privileges that nobody looked at as a whole.

It starts with a foothold that's often trivial: a leaked token in a code repository, an over-permissioned CI/CD pipeline, a developer's credentials phished. From there it's not exploitation, it's navigation. This identity can assume that role. That role can assume another. That one has read access to a secrets store it never needed. Those secrets unlock a database. Each hop is boring on its own. Strung together, they run from "compromised a build runner" to "reading the customer table," and no single step tripped an alarm because each step was, technically, allowed.

We've drawn that chain on a whiteboard for a lot of surprised platform teams. The reaction is almost always the same: "I didn't know that role could reach that." Nobody did. That's the problem.

Why posture scores lull people to sleep

Cloud security posture tools are everywhere now, and they're useful for catching the obvious — the public bucket, the open security group, the unencrypted volume. But a good posture score measures configuration hygiene, not exploitability. It tells you the doors are shut. It doesn't tell you that a set of keys left in a drawer opens half of them.

The gap between "well configured" and "actually secure" in the cloud is almost entirely about identity and the relationships between identities. And those relationships are exactly what a posture score flattens into a checkbox. We've assessed environments with excellent scores and appalling identity sprawl, and the score gave everyone a false sense of safety right up until we drew the chain.

What's actually worth looking at

When we assess cloud identity properly — across Microsoft Entra ID, AWS, and Google Cloud, because most real estates are now multi-cloud whether they admit it or not — the questions are specific and they're about paths, not settings.

Who holds privileged access, and how many service principals and machine identities are quietly over-scoped? What can be reached through OAuth grants, tokens, and delegated permissions that nobody audits? Where are the role-assumption chains that let one identity become another, and another, across account boundaries? Where do secrets live, and which identities can read them? And ultimately: from any given foothold, where can an attacker get, and does anything actually stop them along the way?

That last framing is the one that matters, and it's the one posture tooling can't answer. It requires walking the graph the way an attacker would, not scoring the nodes in isolation.

Least privilege is a verb, not a project

Everyone agrees with least privilege in principle. Almost nobody sustains it in practice, and the reason is structural. Permissions only ever accrete. Someone needs access for a project, gets it, the project ends, the access stays. A role gets a broad grant "temporarily" to unblock a deployment. A service account is created with more than it needs because scoping it tightly was fiddly and the deadline was Friday. Multiply that across a few years and a growing team, and you get the sprawl we find in almost every mature environment.

So least privilege isn't a state you achieve and tick off. It's a discipline you keep applying, and — this is the part people skip — something you have to keep testing, because the config that was tight last quarter has drifted. The useful question is never "are we configured correctly?" It's "if an attacker lands here, where can they get?" And you answer that by actually tracing it, on a real environment, periodically.

The regional footnote

For UAE organisations there's an added incentive to take this seriously. Between Central Bank expectations on financial institutions, ADHICS in healthcare, and the data-residency and protection obligations under the PDPL, "an attacker reached our customer data through a chain of cloud identities" isn't just an incident — it's a reportable one, with regulatory and reputational weight behind it. Identity attack paths are precisely the kind of exposure that turns a contained security event into a disclosable breach.

Where to start

If your cloud posture looks healthy, that's genuinely good — but it's the beginning of the question, not the answer. The next step is to stop scoring nodes and start tracing paths: run a real attack-path assessment across your identities, find the chains nobody meant to create, and close them before someone else maps them for you.

A five-minute exercise worth doing today

Before you commission anything, here's a small exercise that tends to be uncomfortably revealing. Pick one service account or automation identity in your cloud — ideally one attached to a CI/CD pipeline or a shared automation, because those tend to accumulate the most. Now try to write down, from memory, everything it can reach: which resources, which roles it can assume, which secrets it can read, which data stores it can touch. Then go and check the actual permissions against your list. In our experience the reality is almost always broader than anyone remembers, and the difference between what people think an identity can do and what it can actually do is precisely the space attackers operate in. If that one account surprises you, it's a fair bet the other few hundred would too. This isn't a substitute for a proper attack-path assessment — you can't eyeball a graph of thousands of identities — but it's a quick gut-check that usually convinces a sceptical platform team that the problem is real and worth mapping properly. The gap you find in five minutes is a preview of the one an attacker would spend a week exploiting.

We've drawn a lot of those chains over the years, and the environments that came out strongest were the ones that went looking for them on purpose. If you'd like us to trace yours, get in touch.