Why IAM Might Be the Most Dangerous Part of Your Cloud

Ask someone where cloud risk lives, and you’ll usually get the same answers: exposed databases, misconfigured storage buckets, maybe a server left open to the internet. Those are the things people screenshot, write postmortems about, and use in security presentations. They’re also not where most of the interesting problems come from.

If you spend enough time looking at real systems, you start noticing a different pattern. Things don’t usually break because someone hacked through layers of infrastructure like in a movie. More often, access was already there. Just… a bit broader than anyone realised. That’s IAM.

One of the more uncomfortable things about identity issues is that, from the system’s point of view, everything is working exactly as designed. A role has permission to read from a storage bucket. It reads from the bucket. A service account can trigger a job. It triggers the job. There’s no red flag, no obvious “this shouldn’t be happening” moment. Which is great until it isn’t.

Because once an identity has more access than it should, you don’t need to break anything. You just need to use what’s already there. That’s a very different kind of failure mode. Quieter, harder to notice, and often much more powerful. It’s the difference between breaking a door and finding out it was never locked.

Nobody sets out to create a mess in IAM. It usually starts clean. A few roles, some clear boundaries, maybe even a well-thought-out naming convention that makes everyone feel like things are under control. Then reality shows up. A new service needs access, and it needs it now. Someone adds a permission and tells themselves they’ll clean it up later. Another team integrates something and asks for broader access “just to get it working.” A temporary fix becomes permanent because nothing breaks.

Weeks pass. Then months. At some point, nobody is entirely sure what a given role actually allows anymore, but it’s been working fine so far, so no one is eager to touch it. This is how IAM grows. Not through big mistakes, but through small, reasonable decisions that quietly stack on top of each other.

With infrastructure, risk tends to be visible. If a database is exposed, you can point at it and say, “That’s bad.” With identity, it’s more abstract.

A single role might have permission to read data in one place, write somewhere else, and trigger processes in a third system. On paper, those permissions look unrelated. In practice, they can be chained together in ways that aren’t obvious unless you go looking for them. And nobody really enjoys going looking for them.

So the system ends up with these invisible connections, where access in one area quietly unlocks behaviour in another. Everything still looks segmented from a high level, but underneath, it’s a bit more… connected than you’d expect.

This is the part that tends to surprise people when they first dig into it. Humans are not the main actors in your cloud environment. Services are.

APIs calling APIs, background jobs moving data around, pipelines deploying things at 2 a.m. — all of that runs on identities. Keys, tokens, roles, service accounts. Whatever the platform calls them, they all serve the same purpose: letting one piece of the system talk to another.

And they accumulate quickly. You create one for a new service, another for a pipeline, and a few more for integrations. They work, so you move on. Nobody logs in as them, nobody complains about their permissions, and they rarely get revisited unless something breaks.

Which means they tend to stick around with exactly the level of access they were first given—plus a bit extra, just in case.

At some point, someone suggests auditing IAM. It sounds straightforward: list the roles, review the permissions, and tighten what’s too broad. Then you open the actual policies. They’re spread across different services: some inherit permissions from others, some include conditions that only apply in certain contexts. A role that looks simple at first glance turns out to have a surprising amount of reach once you trace it through. You can absolutely do it. It just takes time, patience, and a strong willingness to question things that have been “working fine” for months. Which is why it doesn’t happen as often as it should.

Everyone agrees on least privilege. It’s one of those principles that sounds so reasonable it barely needs explaining. Give services only the access they need. Nothing more.

In practice, it turns into a bit of a negotiation. You don’t always know exactly what a service needs, especially early on. Tight permissions can break things in ways that are hard to debug. Deadlines don’t leave much room for trial and error. So access gets widened, just to be safe.

And once it works, nobody is in a hurry to revisit it. Over time, “just enough” quietly becomes “more than necessary,” and the gap isn’t always obvious.

AI tools are starting to help with IAM. They can suggest policies, explain configurations, and generally make the whole thing feel less opaque. That’s useful.

But they also make it easier to generate something that looks correct and move on. If you’re not paying attention, you end up with policies that technically solve the problem while still granting broader access than intended, which, to be fair, is exactly what humans were already doing—just faster now. So the core issue doesn’t go away. It just scales a bit more efficiently.

There isn’t a clean, “do these three things, and you’re safe” answer. IAM doesn’t really work like that.

What tends to help is less about tools and more about habits.

Short-lived credentials, for example, make a difference—not because they’re perfect, but because they reduce how long a mistake can exist. Tighter, purpose-specific roles help too, even if they feel slightly annoying to maintain at first. That annoyance is usually a signal that boundaries are doing their job.

One thing that seems to work better than big audits is small, continuous cleanup. Instead of trying to fix everything in one go (which never happens), teams that treat permissions as something that gets revisited regularly tend to stay in a better place. Not perfect, but understandable.

And maybe the biggest shift is this: treating IAM as part of system design, not as something you configure at the end. If access is an afterthought, it will reflect that.

A lack of knowledge doesn’t usually cause IAM problems. Most teams know what “good” looks like. Least privilege, rotation, clear boundaries—all of that is familiar. The issue is that those things take time, and time is always under pressure. So decisions get made in the direction of speed, and the consequences show up later, in ways that are harder to trace back to a single moment.

Infrastructure failures tend to be loud. Something goes down, alerts fire, people jump in. Identity issues are quieter: everything keeps working, maybe a bit too well. That’s what makes IAM tricky. Not because it’s fragile, but because it’s easy to assume it’s fine.

If there’s one thing to take away, it’s probably this: most systems get compromised because someone had more access than they needed—and nobody noticed.