A permission discrepancy is any mismatch between the access a person should have and the access they actually retain in connected systems. These gaps often appear after role changes, transfers, or offboarding. They matter because they indicate entitlement drift, which can create audit findings and unnecessary exposure.
Expanded Definition
Permission discrepancy describes a state in which access entitlements in one or more connected systems no longer match the intended access profile for a user, service account, or other identity. In NHI security, the term is especially useful because entitlement drift is often distributed across SaaS platforms, IAM directories, cloud roles, API permissions, and automation tools rather than confined to a single control plane.
Unlike a simple access error, a permission discrepancy can be temporary, inherited, or hidden behind stale group membership and delegated trust. Definitions vary across vendors, but the core governance issue is consistent: the effective permissions observed at runtime do not align with the approved access model. That distinction matters under guidance such as the OWASP Non-Human Identity Top 10 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where least privilege and account lifecycle governance are central.
The most common misapplication is treating every mismatch as a one-time helpdesk issue, which occurs when teams ignore inherited access, stale tokens, or delayed revocation after a role change.
Examples and Use Cases
Implementing permission discrepancy detection rigorously often introduces review overhead and temporary workflow friction, requiring organisations to weigh faster user transitions against stronger entitlement hygiene.
- A developer is moved to a different product team, but old cloud project roles remain active in a legacy workspace after the transfer.
- An API client keeps write access to a data store after its integration scope was supposed to be reduced to read-only.
- A service account used in CI/CD still holds production secrets permissions even after the pipeline was redesigned to use a narrower vault path.
- An offboarded contractor loses directory access but retains delegated permissions through a shared group that was never removed.
- A security team compares approved entitlements against actual runtime grants and finds drift across multiple tools, similar to the access expansion patterns documented in the Ultimate Guide to NHIs — Key Challenges and Risks.
In practice, these mismatches are often detected during periodic access recertification, incident response, or cloud permission audits, rather than at the moment they were introduced. Cases involving AI tooling can be especially difficult to spot because an agent may retain tool access even after its intended scope changed, as seen in the Replit AI Tool Database Deletion incident. The same pattern appears when secrets or delegated tokens are left in place after operational changes.
Why It Matters in NHI Security
Permission discrepancy is not just an IAM housekeeping issue. It is a direct indicator that identity governance has lost synchronisation with operational reality, which can lead to privilege creep, unauthorized data access, and failed audits. NHIMG research shows that 97% of NHIs carry excessive privileges, making entitlement drift a common and material exposure rather than an edge case, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That is why discrepancy management belongs in NHI lifecycle controls, not only in periodic human access reviews.
The practical risk is highest when discrepancies affect secrets, automation tokens, or machine-to-machine trust relationships, because those permissions can be exercised at speed and scale. Security teams also need to remember that absence of visible abuse does not mean absence of exposure. In cases involving token misuse or key leakage, the operational impact can spread before the entitlement gap is even discovered, as highlighted in the Microsoft SAS Key Breach coverage. A permissions gap often becomes obvious only after an incident review exposes the stale grants that made the event possible.
Organisations typically encounter permission discrepancies only after a breach, failed audit, or post-incident access review, at which point entitlement cleanup becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Permission drift is a core non-human identity entitlement risk. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management directly addresses mismatch conditions. |
| NIST SP 800-63 | Identity proofing and binding matter when access no longer matches the intended subject. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of actual authorization state. | |
| NIST AI RMF | AI systems and agents can accumulate mismatched permissions over time. |
Ensure identity lifecycle records stay accurate so revoked or reassigned access is not retained.
Related resources from NHI Mgmt Group
- When should organisations revoke an OAuth grant or third-party app permission?
- What is the difference between client identity and permission scope in MCP governance?
- Why do permission boundaries fail as a scale control for cloud access?
- What is the difference between SCPs and permission boundaries in AWS governance?
