Blog

Jun 30, 2026 | 10 min

How to Audit Excessive Permissions Across Cloud and SaaS

Token Security Staff

No items found.

Key Takeaways

An excessive-permission audit earns its keep when it ties every entitlement to an owner, a workload, observed use, and the data it can reach.
Palo Alto's Unit 42 analyzed more than 680,000 cloud identities and found 99% were granted excessive permissions that went unused for 60 days or more, which is exactly the gap an excessive-permission audit exists to close.
A serious cloud permission audit maps the indirect paths too: assume-role chains, pass-role permissions, SaaS scopes, and CI/CD trust rules.
The safest findings are not simply the riskiest permissions. They are the ones with enough evidence to remove or reduce them without a fight.

How do you audit excessive permissions?

Start with the identity that can act, then prove whether each grant still matches real work. A useful audit joins AWS IAM, Azure Entra ID, Google Cloud IAM, Kubernetes, GitHub Actions, SaaS OAuth grants, service accounts, and AI agents to activity logs, owners, data sensitivity, and blast radius. The goal is not a longer list of risks. It is to identify unused permissions and hand an owner a change they can approve.

Group permissions by the identity that can use them, not only by role or policy name.
Compare observed use with the job the identity is actually supposed to do.
Prioritize access that reaches production data, admin APIs, or paths shared by several workloads.
Send owners a proposed change with evidence, a test plan, and a rollback path, not just a risk score.

Quick Facts

Risk	What it means	How to address it
Role export only	The audit lists assigned rights but misses how the identity actually behaves.	Compare grants with cloud logs, SaaS events, and CI/CD runs.
Missing owner	Security finds risky access but cannot route the fix to anyone accountable.	Attach every identity to a team, a workload, and a business purpose.
Hidden access path	A role is reachable through trust policies, delegated admin, or OAuth scopes.	Map direct and indirect paths before deciding what counts as excess.
Stale privilege	Access was needed once and stayed live for months after the task ended.	Identify unused permissions and set an expiry or a removal plan.

What makes an excessive permission finding actionable?

A finding becomes useful when it tells an owner exactly what can change and why the change is safe. That takes more than a severity label. It takes the identity, the access path, the evidence, and a reversible plan. Governance frameworks describe this as identity governance and administration, but on the ground it comes down to two kinds of proof.

Owner evidence shows who can approve the change and who will respond if it fails.
Activity evidence separates access that is truly unused from access that is rare but still required.

Why do cloud permission audits miss the permissions attackers use?

Most audits begin with assignment data because it is the easiest thing to collect. Cloud consoles export roles. SaaS admin pages list connected apps. The problem is that assignment data describes potential, not behavior, and attackers do not care what a policy was intended to do. They care what it lets them reach. Access that looks dormant on paper can still be a live path to production, and access-token reuse can carry that path well beyond the workflow it was built for. It helps to treat every access token as a credential that can be replayed, not a detail buried in a policy.

Capital One is still a useful cloud lesson because it separates entry from impact. In the 2019 breach, an attacker exploited a server-side request forgery weakness and a misconfigured web application firewall, then used an over-permissioned role to reach data in cloud storage. As Krebs on Security documented, the initial foothold was almost mundane. The damage came from what the compromised role could touch: records tied to more than 100 million people, including roughly 140,000 Social Security numbers.

That is the intent-based cybersecurity point in one example. The audit should not ask only whether a role exists. It should ask what the role is for, what it can reach, and whether that still matches the task in front of it. This is the same behavior the MITRE ATT&CK Valid Accounts technique describes, where legitimate credentials become the quietest path an attacker has, and it is why the privilege escalation tactic focuses on how ordinary access turns into control.

Where should the audit look first?

Start where the blast radius is large and ownership is weak. In practice that means production cloud roles, service accounts with old keys, SaaS apps with broad scopes, and the identities several workloads quietly share. Work from impact down to convenience, not the other way around.

Identity or path	Evidence to collect	Red flag	First move
Cloud role	Granted actions, used actions, last access, and trust relationships.	Admin actions exist but never appear in logs.	Generate a narrower policy candidate.
Service account	Owner, workload, key age, last use, and reachable resources.	No owner, or a long-lived key attached to production data.	Assign an owner and schedule a key or scope review.
AI agent	Purpose, tools, data classes, invoking identity, and behavior baseline.	A tool call falls outside the declared purpose.	Require review or scope the tool path down.
SaaS OAuth app	Scopes, refresh tokens, connected users, and app owner.	A high-risk scope with no recent use.	Remove unused scopes or revoke the app.
CI/CD identity	Repository, branch, environment, subject claims, and deploy targets.	A trust policy accepts broad subjects or wildcard branches.	Limit trust to approved repos and branches.

How do you turn audit results into remediation?

A practical sequence is to remove identity-specific excess first, then move to shared roles once the dependencies are clear. For high-blast-radius permissions, require an owner test, a change window, and monitoring for denied calls. If a team cannot prove a permission is safe to remove, narrow it, set an expiry, or convert it to a temporary exception rather than leaving it broad forever.

Clean up orphaned identities before you tune complex policies. Dead accounts do not need delicate remediation.
Track closed findings by permissions reduced, identities retired, and blast radius lowered, not by tickets created.

Common mistakes that make audits sound complete but change nothing

Counting roles instead of identities, which hides how many machine actors can walk the same path.
Treating last-used data as the whole truth when logs miss rare jobs, migrations, and failover paths.
Reviewing human users carefully while non-human identities and AI agents sit in a separate queue.
Sending owners a vague risk label instead of the permission, the evidence, and the proposed reduction.
Stopping at discovery when the real outcome is fewer standing privileges in production.

How Token Security approaches excessive permission audits

The challenge

Excessive permissions rarely sit in one console. They spread across cloud IAM, SaaS apps, repositories, pipelines, secret stores, and AI tools. A team may know a workload exists without knowing which credentials it carries, which scopes it inherited, or who is responsible for approving a change to it.

The approach

Token Security treats the actor as a non-human identity first. Discovery finds agents, service accounts, machine identities, OAuth apps, and workload credentials. Entitlement mapping connects each identity to what it can reach. Blast-radius analysis ranks the exposure. Behavioral baselines show what the identity actually does. Automated remediation and lifecycle governance help teams reduce or retire access instead of carrying another static finding into the next review.

A Discover, Understand, and Enforce loop keeps the program from collapsing into a one-time audit. Discover finds the identities and credentials. Understand explains access, ownership, and behavior. Enforce narrows access, retires stale paths, and applies policy at the moment the identity acts.

The outcome

Security teams get a working path from discovery to a safe fix. The audit no longer hinges on one cloud export or one quarterly review. It becomes a living control loop for AI agents, service accounts, machine identities, and SaaS apps that keeps reducing privilege as the environment shifts underneath it.

How security leaders are applying this model

Audits fail when a team cannot separate a real machine-identity risk from a noisy alert. Lemonade points to the value of findings detailed enough to act on.

"Token Security has enhanced our security by providing us accurate and relevant visibility into machine identity risks, something I have yet to see from other vendors. It's the first service I've seen that delivers on the widely-made claim of finding machine identity risk. It provides us with the right amount of detail to mitigate issues without burdening us with tens of rows of useless alerts." - Jonathan Jaffe, CISO at Lemonade

That maps directly to permission auditing. The useful finding is not the loudest one. It is the one that names the identity, shows the access path, and gives the owner enough detail to reduce the risk.

Elastic frames the other half of the problem, which is scale. Non-human identity programs tend to start with visibility because teams cannot govern access they cannot see.

"Non-human identity is a top priority for many teams and it is challenging to gain insight into the full scale and scope of the issue. Token provides an easy solution to get that visibility to then determine where you need to take action." - Mandy Andress, CISO at Elastic

Why the NHI gap keeps widening

Excessive permissions keep coming back because machine access grows faster than review cycles. A developer spins up a service account for a deployment. A SaaS app adds a scope. An AI agent gets wired into a ticketing system, then a data warehouse, then a workflow tool. Each step is reasonable in the moment. Six months later, nobody can trace the whole path.

The future of permission auditing is not a bigger spreadsheet. It is stronger proof about which identity is acting, why it is acting, what it can reach, and whether that access still matches the task. Once identity becomes the control layer, teams can audit excessive permissions where risk actually moves: cloud roles, SaaS scopes, service accounts, and AI agents.

FAQs

What does it mean to audit excessive permissions?

Auditing excessive permissions means comparing what an identity can do with what it actually needs to do. The audit should cover users, service accounts, workloads, AI agents, OAuth apps, and CI/CD identities. It should map owners, used actions, unused permissions, indirect access paths, and reachable data so a team can reduce access safely rather than just documenting risk.

How often should cloud permissions be audited?

Evaluate cloud permissions continuously, with deeper reviews around major releases, new data stores, new SaaS integrations, and AI agent deployments. A quarterly access review is useful for governance evidence but too slow for cloud change. New roles, keys, scopes, and agents can appear every day, so the audit process needs a continuous feed of identity and activity data.

What evidence do you need before removing unused permissions?

Collect last-used activity, owner approval, the workload schedule, dependency data, and a rollback path. Last-used data alone is not enough, because some permissions support monthly jobs, migrations, or incident response. A safe removal includes a proposed policy change, a test plan, monitoring for denied calls, and a clear owner who can restore access if needed.

Why do non-human identities make permission audits harder?

Non-human identities are created by automation, shared across workflows, and rarely reviewed like human accounts. They can hold cloud roles, SaaS scopes, API tokens, and service-account keys without a clear owner. AI agents add complexity because they call tools and act through delegated access, so the audit has to follow the action path rather than just the credential.