Permission Review

Expanded Definition

Permission review is the discipline of evaluating what access a software identity requests, what it actually needs, and whether the approved scope still matches the business use case. In NHI and IAM programs, this applies to service accounts, API keys, OAuth clients, workloads, and browser extensions that can read data, write data, modify requests, or inject scripts. It is closely related to privilege review, but permission review is narrower and more concrete: it focuses on the specific capabilities granted, not just the label assigned to an identity. Guidance varies across vendors and platforms, so teams should treat permission review as a control process rather than a product feature.

For browser extension risk, permission review should include runtime capabilities, data access, and modification rights, not only whether the extension is installed. That distinction matters because an extension with broad script injection or request interception can create a far larger attack surface than a simple read-only add-on. NIST’s Privacy Framework and the OWASP Non-Human Identity Top 10 both reinforce the need to assess access in context, not by identity name alone. The most common misapplication is treating installation approval as permission approval, which occurs when teams ignore the actual scopes, methods, and data paths enabled at runtime.

Examples and Use Cases

Implementing permission review rigorously often introduces operational friction, because every approval must be weighed against the benefit of tighter control and the cost of slower delivery.

• A CI/CD service account is allowed to deploy only to one namespace, and the review removes blanket write access to production clusters.
• An OAuth application requests read, write, and offline access, but the business case supports read-only reporting, so the surplus scopes are denied.
• A browser extension is approved for translation, but the review finds it can inject scripts into internal portals, so its permissions are narrowed before rollout.
• A workload identity is granted access to a secrets manager, and the review confirms it can retrieve only the exact secrets needed for one application path.
• A third-party automation bot is re-reviewed after a feature change expands its request-modification capability, triggering a scope reset.

Permission reviews are most effective when paired with lifecycle controls such as visibility, rotation, and offboarding, themes covered in Ultimate Guide to NHIs — Key Challenges and Risks. They also align well with the OWASP Non-Human Identity Top 10, especially where over-permissioned identities become a repeat finding across pipelines, SaaS integrations, and agent toolchains.

Why It Matters in NHI Security

Permission review is one of the clearest ways to reduce blast radius when NHIs are compromised. NHIs are frequently granted more access than they need, and NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which broadens attack paths and makes abuse easier once an identity is hijacked. This is why permission review is not just administrative housekeeping; it is a practical containment control for secrets, tokens, and machine-to-machine access.

When permission review is weak, organisations tend to discover the problem only after a breach, a failed audit, or a production incident reveals that long-lived access was never justified. That gap is especially dangerous in environments where secrets are stored outside approved vaults, because access can persist long after the original business need has changed, as highlighted in the Ultimate Guide to NHIs — Key Challenges and Risks. In practice, the control becomes a forcing function for least privilege, approval hygiene, and periodic entitlement recertification. Organisations typically encounter unauthorized data movement only after an identity is abused or an extension is exploited, at which point permission review becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When should organizations review their NHI policies?
• When should organizations review access controls?
• When should enterprises review their extension policies?
• When should organisations review service accounts and API keys?