Permissions only ever grow. Someone is blocked, a broader role is attached to unblock them, the immediate problem resolves, and nobody returns to narrow it. Repeat over several years and every service has far more access than it uses, which means every compromised credential is worth far more than it should be.
Fixing this by designing correct policies from first principles does not work. Fixing it from observed usage does.
What changed in 2026
- Usage-based policy generation improved. Cloud platforms generating suggested narrow policies from observed access logs made narrowing practical rather than theoretical.
- Just-in-time elevation spread. Requesting temporary elevated access, rather than holding standing admin roles, became a common pattern beyond large organizations.
- Agent identities raised the stakes. Autonomous systems acting with delegated permissions made scope limits more consequential, as covered in AI agent permissions.
- Unused permission reporting matured. Tooling surfacing permissions granted but never exercised made the accumulation visible.
Where over-permission hides
| Pattern |
Why it is granted |
What it actually allows |
| Wildcard on actions |
Nobody knew which specific actions were needed |
Everything the service can do |
| Wildcard on resources |
Convenient during development |
Access to every resource of that type |
| Broad managed roles |
Faster than writing a policy |
Whatever the provider included |
| Admin for troubleshooting |
Granted during an incident |
Never removed afterwards |
| Shared role across services |
Simpler to manage |
Union of everything any of them needs |
| Human role used by automation |
Available and worked |
A person's full access, applied programmatically |
The last row deserves specific attention. Automation running under a human's credentials inherits everything that person can do, and it destroys audit attribution — nobody can tell from the log whether a person or a script made a change. Every automated process should have its own identity, which is also the foundation for the agent controls in AI agent permissions.
Narrowing from evidence
Designing a minimal policy in advance requires knowing exactly which operations a service performs, which nobody does accurately. The workable method inverts it.
Start with the permissions currently granted and enable access logging. Run for a period covering the full range of activity — including monthly jobs, deployment paths, and incident procedures, which is why the window needs to be long enough.
Then generate a policy from what was actually used. Cloud platforms increasingly do this automatically, and doing it manually from logs is straightforward if tedious.
Apply the narrowed policy in a monitoring mode where the platform supports it, so denied actions are logged without being blocked. That catches the paths your observation window missed before they cause an outage.
Then enforce, and watch for denials.
Iterate. Permissions accumulate again; a periodic pass using unused-permission reports keeps the drift bounded.
Common mistakes
- Designing minimal policies up front. Nobody knows the full requirement in advance.
- Wildcards left from development. The most common source of excess.
- Standing admin access. Time-bound elevation is nearly as convenient and much narrower.
- Automation under human credentials. Destroys attribution and over-grants.
- Narrowing without a monitoring period. Breaks the monthly job nobody remembered.
- One-time cleanup. Permissions regrow; make it periodic.
FAQ
How long should the observation window be?
Long enough to include infrequent operations — monthly reports, quarterly jobs, incident procedures. A month is a common minimum.
What about permissions needed only during incidents?
Time-bound elevation, requested when needed. Standing access for rare situations is exactly the pattern to remove.
Does this apply to human users too?
Yes, and elevation matters more for humans since their standing access tends to be broadest.
How do I handle a service whose needs change?
The narrowed policy will deny something new, which surfaces as a clear error rather than a silent over-permission. That is the system working.
Where to go next
For credential lifecycle, read secrets rotation guide. For agent-specific scoping, AI agent permissions, and for infrastructure access, Terraform state management.