Least privilege is the principle nearly every cloud security team endorses and nearly none of them reach. Engineers who can recite the rule by heart still hand out access far wider than any workload needs, over and over, across every account they touch.
On the surface this looks like a discipline problem, careless engineers cutting corners, but the evidence points somewhere else. Over-permissioning is what a rational engineer does when the policy in front of them cannot be read, cannot be tested, and can trigger a production outage when they scope it too tightly.
Consider what an author is actually working with in AWS. A wildcard grant such as iam:* looks compact on the page, yet it can resolve to well over a hundred individual actions, and even a tighter pattern like s3:Get* pulls in dozens. Either way, the set grows quietly as AWS ships new API actions into the namespace, so the author rarely knows its full blast radius, which keeps widening long after they have moved on.
Layered on top, the logic resists manual evaluation. In AWS, overlapping SCPs, RCPs, permission boundaries, and multi-condition statements interact in combinations few engineers resolve reliably by hand, and anything worked out under time pressure tends to get worked out loosely.
Testing doesn’t help much either. Developers can run new code in staging and catch bugs before release, but staging accounts often don’t mirror production’s identities, resource policies, permission boundaries, and SCPs, so a policy that works there can still fail live. Engineers find out a grant is too tight when a production service suddenly loses access. Teams then grant extra headroom to avoid breaking a release at two in the morning, and broad access becomes their insurance against a failure no one ever let them rehearse.
Even the platform pushes in the same direction. Character caps and policies-per-role limits force engineers to fold a precise permission set into one broad wildcard, because the tight version will not fit the platform’s deployment limits. Port that same policy to Terraform, CDK, or CloudFormation, and each translation introduces small errors and another competing account of intended access.
None of it is visible in one place. Effective reach, the set of resources an identity can actually touch once every policy layer resolves, depends on identity, resource policy, permission boundaries, session context, and network paths spread across accounts, and no single native console renders the net result. On most teams, no one can say with confidence what a given identity is able to reach at any moment.
Cleanups don’t last either. Remediation campaigns can clear a backlog for a quarter but then the sprawl returns because the incentives haven’t changed: organizations still reward shipping fast over shipping tight, and few measure how much access they grant along the way. Each cleanup treats the symptom while the cause, the engine producing over-permissioning, stays in place.
And the scale of the waste is measurable. Research has shown that nearly 96% of permissions go unused and unneeded, yet those permission pathways exist nonetheless. Microsoft found that workload identities now outnumber human ones by roughly ten to one and use an even smaller share of it, so the widest and least-used grants belong to software more than people.
AI turns that sprawl into an urgent problem, because autonomous agents run as cloud identities that inherit the same broad roles a human would, acting at machine speed without the pause a person might take before something irreversible. And they can easily utilize the access that was granted to an over-permissioned role that sat harmless for years, becoming a live path the moment an agent, or an attacker steering one, begins to move.
So the fix for a CISO sits at the foundation, in how the organization writes, tests, measures, and enforces access. Asking engineers to be more careful won’t hold while the conditions that push them to over-grant stay in place. With that in mind, a change that addresses the conditions directly, rather than relying on a shift in behavior, becomes necessary.
Firstly, access must be treated the way engineering treats code, so a team expands each policy to its true actions, simulates it against real requests, and evaluates it against intent before deployment, catching a bad grant in advance instead of in a moment of crisis.
Effective reach becomes the metric that matters, because remediation tickets reveal little about exposure. The operative question for any identity is simple: what can it actually reach right now?
Broad permission classes call for structural guardrails and boundaries rather than piecemeal fixes, since closing off whole categories of excess access holds where one-by-one remediation does not.
Every AI workload needs a hard line before it ships, carrying explicit, narrow access defined ahead of deployment and scoped to its single task, so a compromised or unpredictable agent has nowhere to travel.
And practitioners need open, community-vetted tooling so policy authoring no longer runs on guesswork, because the people who hit these walls build the sharpest instruments and shared tools beat versions each team reinvents in private.
As AI agents take on more work inside cloud environments, the organizations that adopt them safely will be the ones that fixed access first, making every policy testable and measuring each identity by what it can actually reach. They can scale agents with confidence and adopt agents without surrendering the safety of the environment because the roads to anything valuable were closed before the first agent went live.
______
About Jonathan Langer
Jonathan Langer is Co-Founder and CEO of Act Security. Previously, he co-founded Medigate, the healthcare IoT security platform acquired by Claroty in 2021, where he served as CEO and later as COO of Claroty, leading global operations at scale.
Join our LinkedIn group Information Security Community!
