TL;DR: Identity governance is shifting from manual access administration to a structured control layer for employees, contractors, service accounts, and AI agents, according to SafePaaS. As access sprawl and SoD risk grow, the real control problem is proving who can do what, why, and for how long.
At a glance
What this is: This is a SafePaaS analysis of identity governance and segregation of duties matrices as controls for modern access sprawl across human and non-human identities.
Why it matters: It matters because IAM teams now have to govern access decisions, review cycles, and toxic combinations across employees, service accounts, and AI-enabled workflows, not just enforce logins and permissions.
Context
Identity governance is the layer that decides who should get access, under what conditions, and for how long. The article frames that layer as the control plane that keeps pace when applications, roles, and risk change faster than manual review processes can handle.
The governance gap is not authentication alone. Organisations can have strong login controls and still fail on approval evidence, segregation of duties, role creep, orphaned access, and recertification across ERP, SaaS, databases, infrastructure, and AI-connected identities.
Key questions
Q: What breaks when segregation of duties is the only control in place?
A: SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access. Users can change roles, projects can end, and temporary access can become permanent without any SoD alert. A programme built only on prevention still accumulates governance debt over time.
Q: Why do identity governance failures create audit and compliance risk?
A: Because auditors need evidence that access was approved, appropriate, and reviewed, not just technically granted. When that evidence lives in tickets, emails, and spreadsheets, organisations struggle to prove control operation over time. The risk is not only policy violation, but inability to demonstrate that the policy was enforced consistently.
Q: How do security teams know when access review processes are not enough?
A: When reviews are happening but high-risk access, role creep, or orphaned accounts keep reappearing, the programme is checking records rather than controlling outcomes. A review process is effective only if it changes access state, removes conflict, and leaves a clear trail of decisions. If it does not, the process is cosmetic.
Q: Why do service accounts and AI agents need different controls from human users?
A: Service accounts and AI agents authenticate and act without the predictable patterns that human identity systems expect. They can operate across runtimes, scale quickly, and carry permissions into automated workflows. That means access decisions should consider workload context, runtime behaviour, and time-bound authority rather than relying only on user-centric IAM patterns.
Technical breakdown
How identity governance turns access into an auditable control
Identity governance sits above runtime access enforcement and turns entitlement decisions into policies, approvals, certifications, and revocations. It answers the questions auditors and risk teams care about: who approved access, whether it remains appropriate, and whether conflicting permissions were prevented. In practice, that means identity governance is the control layer that makes IAM defensible, because it connects access to role intent, risk, and evidence rather than treating permissions as one-time setup work.
Practical implication: teams should treat governance workflows as the evidence layer for access decisions, not as a spreadsheet exercise.
Why segregation of duties matrices matter across ERP, SaaS, and cloud
A segregation of duties matrix defines which combinations of permissions are toxic, such as creating a vendor and approving payment. The article’s key point is that those conflicts do not stay inside one application. As entitlements spread across ERP, SaaS, databases, and infrastructure, SoD analysis has to evaluate combined access across systems, otherwise the conflict is invisible until fraud or an audit finding exposes it.
Practical implication: map SoD conflicts across application boundaries, not just inside a single system.
How identity governance extends into AI-era access control
The article extends identity governance beyond human users to service accounts and AI agents, which means the same policy logic has to cover non-human identities as well. That matters because machine and agent access often bypass the informal checks used for people, yet still reaches sensitive data and business systems. The governance model therefore has to include role boundaries, access approval, and ongoing review for identities that do not behave like employees but still create business risk.
Practical implication: include non-human identities in governance design, certification, and SoD review from the start.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity governance is becoming the only practical way to make access decisions defensible at scale. Authentication proves who logged in, but it does not prove whether the access was approved, appropriate, or still valid. As business applications, SaaS, and cloud estates fragment entitlement ownership, the governance problem becomes one of evidence and accountability, not just enforcement. Practitioners should treat governance as the control that keeps access from becoming an unreviewed accumulation of exceptions.
SoD matrices are now cross-platform control models, not application-specific policy tables. The article correctly points to toxic combinations such as vendor creation and payment approval, but the larger issue is that those combinations now emerge across ERP, SaaS, and supporting infrastructure. That means role design must be evaluated as a graph of effective privileges, not as a list of local entitlements. The practitioner takeaway is to model conflicts where they actually occur, across systems and business processes.
Human and non-human identities now share the same governance problem, even if they do not share the same operating pattern. Service accounts and AI agents can hold access that outlives a task, a change, or a review cycle, which makes lifecycle governance part of the SoD discussion. Identity governance programmes that stop at employee access reviews will miss the identities most likely to accumulate hidden privilege. The implication is that lifecycle, approval, and certification design must span both people and machines.
Named concept: governance evidence debt. The article describes a common enterprise failure mode where access is technically granted but cannot be easily defended through approvals, rationale, and review history. That is governance evidence debt: the longer organisations rely on ad hoc tickets and spreadsheets, the harder it becomes to prove why access exists and whether it remains appropriate. Practitioners should treat that debt as a control failure, not an administrative inconvenience.
AI-era identity governance will force GRC and IAM teams to converge on the same control vocabulary. The article shows why role definitions, SoD rules, certifications, and access lifecycle logic can no longer live in separate governance silos. Once AI tools and agents touch business data and systems, identity controls have to express policy in a way both security and business owners can understand. The practical conclusion is that governance models must become machine-readable and audit-readable at the same time.
What this signals
Governance evidence debt: identity programmes fail when access can be approved but not easily defended through durable evidence. That is why tickets and spreadsheets are a weak foundation for auditability, especially once roles, exceptions, and reviewers change.
Identity governance teams should now design for cross-platform effective privilege, not isolated entitlements. The same user or workload can accumulate a toxic path across ERP, SaaS, cloud, and databases long before any single system looks risky.
The operational shift is from access administration to control assurance. That means lifecycle governance, SoD analysis, and certification all need to describe the same access story in a form business owners can actually review.
For practitioners
- Define SoD matrices around business transactions Start with high-risk business flows such as vendor setup, payment approval, journal posting, and procurement changes. Then map which combinations of access across applications create a toxic path, even when those permissions sit in different systems.
- Centralise approval and certification evidence Replace ticket trails, email approvals, and spreadsheets with a governed record of who approved access, when it was reviewed, and why it remains appropriate. That evidence needs to survive audits and role changes.
- Extend lifecycle governance to non-human identities Bring service accounts and AI agents into the same joiner mover leaver logic used for people, including ownership, review cadence, and revocation triggers when the task, role, or system relationship changes.
- Model access as effective privilege across systems Review the combined effect of access across ERP, SaaS, cloud, and databases instead of validating entitlements one platform at a time. The control question is whether the user or workload can complete a restricted business action end to end.
- Separate runtime login control from governance policy Keep IAM enforcement and identity governance distinct. One enforces sign-in and entitlement checks at runtime, while the other decides whether the access should exist and how it is certified over time.
Key takeaways
- Identity governance is becoming the control layer that makes access decisions provable, reviewable, and tied to business risk.
- Segregation of duties has to be assessed across systems and workflows, because toxic combinations often appear only when entitlements are combined.
- IAM teams need lifecycle and certification logic that includes service accounts and AI agents, not just employee access.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article extends governance to service accounts and AI agents with excess access risk. |
| NHI-01 — Improper Offboarding | Lifecycle governance and revocation are central because access must be removed when roles change or end. | |
| Recommendation — Review non-human access paths for overprivilege and remove entitlements that are not required for the task. Tie joiner mover leaver processes to NHI ownership so stale accounts are revoked when tasks or systems change. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing who should have which access and why. |
| Recommendation — Use entitlement governance to align access permissions with approved business roles and revoke exceptions. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article stresses account lifecycle, certification, and revocation across identities. |
| Recommendation — Standardise account management so approvals, reviews, and revocations are recorded and enforceable. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Overprivileged and orphaned identities expand the paths attackers can use after compromise. |
| Recommendation — Map excessive entitlement paths to Credential Access and Lateral Movement to prioritise reduction work. | ||
Key terms
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
- Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
- Certification Review: A certification review is a formal access attestation process where a manager or resource owner confirms whether a user should keep specific access. It is a core identity governance control because it helps detect excess, stale, or inappropriate entitlements and supports timely revocation decisions with an auditable record.
- Effective Privilege: Effective privilege is the real access an entity can exercise after inheritance, delegation, token scope, and connected-system trust are applied. It is often broader than the permissions shown in an identity repository, which is why runtime validation matters.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 27, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org