Identity governance and SoD matrices are becoming AI-era controls

At a glance

What this is: This is an analysis of segregation of duties matrices as part of identity governance, with the central finding that access control now has to cover human and non-human identities across cloud, SaaS, ERP, and AI workloads.

Why it matters: It matters because IAM teams can no longer treat approval workflows, role design, and certification as human-only problems when NHIs and AI agents can create the same toxic access combinations.

👉 Read SafePaaS's analysis of segregation of duties matrices and identity governance

Context

A segregation of duties matrix is a governance tool that maps conflicting access combinations before they turn into fraud, audit failures, or uncontrolled privilege. In NHI governance terms, the same logic now applies to service accounts, API keys, tokens, certificates, and AI agents that can hold business-critical access without a human sitting in the middle.

SafePaaS frames identity governance as the control layer that decides who or what should get access, who approved it, and whether it still makes sense. That is a fair reading of the current problem space: when identities are spread across ERP, SaaS, cloud, and infrastructure, spreadsheets and ticket trails stop being defensible evidence. For teams building NHI governance, this is a familiar starting point rather than an edge case.

Key questions

Q: How should organisations build a segregation of duties matrix for modern IAM programs?

A: Start with business processes, not system lists. Define the actions that should never sit in the same identity, then map those conflicts to roles, entitlements, and approval paths across ERP, SaaS, cloud, and automation layers. Include non-human identities because service accounts and AI agents can also create toxic access combinations.

Q: Why do non-human identities make access certification harder?

A: Because certification depends on a clear owner, a stable purpose, and a human reviewer who can judge necessity. NHIs often lack one or more of those conditions. They can also accumulate access through integrations and pipelines, so teams need continuous ownership, expiry, and revocation logic instead of relying only on periodic reviews.

Q: What is the difference between identity governance and runtime IAM enforcement?

A: IAM enforces access at the point of login or transaction. Identity governance decides whether that access should exist in the first place, whether it is still appropriate, and whether it violates policy. Governance supplies the rules and evidence layer, while IAM supplies the runtime gate.

Q: When should security teams treat AI agents like privileged identities?

A: Whenever an AI agent can act independently, touch sensitive data, trigger workflows, or chain actions across systems. At that point, it is not just an application feature. It is an identity with execution authority, and it needs ownership, scoping, review, and revocation controls like any other high-risk account.

Technical breakdown

How segregation of duties matrices work in identity governance

A segregation of duties matrix defines combinations of entitlements that should not coexist in the same identity. The matrix is usually built from business processes first, then translated into access rules, role constraints, and review logic. In practice, this matters because SoD conflicts are not only about job titles. They are about the ability to create, approve, move, and hide value in the same system. For NHI governance, the same model has to include service accounts and AI agents, because a non-human identity can accumulate conflicting privileges just as quickly as a person can.

Practical implication: Map toxic entitlement combinations before role assignment, not after audit findings appear.

Why NHI and AI agent identities complicate access review

Traditional access review assumes a manager or application owner can judge whether a person still needs access. That assumption breaks down for NHIs, which may not have a clear business owner, may be embedded in pipelines, and may change behavior through automation. An AI agent adds more complexity because its access can be task-scoped, dynamic, and delegated across tools. The governance question becomes whether the identity has the right standing privileges, the right scope, and the right expiry logic, not whether a human employee still needs a permission.

Practical implication: Require explicit ownership and expiry rules for every non-human identity before certification cycles begin.

Policy-based role design and lifecycle controls

Policy-based identity governance separates access intent from access enforcement. That allows teams to define clean roles, test them with simulation, and enforce joiner, mover, and leaver rules consistently across systems. The architectural value is that lifecycle controls become repeatable rather than manual, which reduces orphaned access and hidden exceptions. For NHI programs, the same pattern should cover provisioning, rotation, offboarding, and revocation, because lifecycle drift is one of the main ways machine identities become overprivileged.

Practical implication: Tie role design, access reviews, and NHI lifecycle events to the same control model.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Segregation of duties is no longer a finance-only control. Once access spans ERP, SaaS, cloud infrastructure, and automation layers, SoD becomes a general-purpose identity control for preventing concentrated power in any one account. That extends directly to NHI governance because service accounts and AI agents can execute sensitive workflows without human friction. Practitioners should treat SoD matrices as a living control surface, not an annual audit artifact.

Non-human identities create a new form of role creep. Human role creep usually comes from job changes and exceptions. NHI role creep comes from pipelines, integrations, and delegated permissions that accumulate quietly over time. That makes periodic certifications necessary but not sufficient, because the access pattern itself can be structurally wrong. Practitioners should move from static review to continuous entitlement hygiene.

Identity governance is becoming the operating model for AI governance. If AI agents can request data, trigger workflows, or interact with business systems, the control question is no longer just authentication. It is policy, approval, scope, evidence, and revocation across an autonomous identity. That makes governance the binding layer between IAM and AI risk. Practitioners should stop separating AI governance from identity governance in their operating model.

Access evidence now matters as much as access decisions. Auditors and regulators increasingly expect organizations to show why access exists, who approved it, and when it was removed. In NHI-heavy environments, that evidence must cover machine identities, not only employees. The practical conclusion is simple: if your control cannot produce durable evidence, it is not yet a governance control.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That gap is why teams should pair access certification with lifecycle controls, as described in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Identity governance teams should expect SoD matrices to absorb NHI risk directly. Once service accounts and AI agents participate in business workflows, the old separation between human access review and machine access review stops making operational sense. The programme implication is to unify entitlement policy, ownership, and revocation under one control model, then map it to NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture.

Access drift is now a lifecycle problem, not a point-in-time review problem. When identities outlive projects, integrations, or pipeline jobs, the governance issue becomes stale privilege rather than missing approval. Teams should watch for long-lived machine credentials, orphaned roles, and exceptions that never expire, then align remediation with the Ultimate Guide to NHIs.

Role design should move closer to policy engineering. If access rules are not testable before deployment, SoD enforcement will remain reactive and inconsistent. Practitioners should prepare for more simulation-driven role design, more evidence capture, and more explicit control ownership across both human and non-human identities.

For practitioners

• Define toxic access combinations across human and non-human identities Build an SoD matrix that includes ERP functions, cloud admin roles, CI/CD permissions, and machine identities with business impact. Use it to block conflicting access at request time rather than relying on after-the-fact review.
• Assign explicit owners to every non-human identity Every service account, API key, token, certificate, and AI agent should map to a business owner and a technical custodian. Without ownership, certifications become guesswork and revocation becomes delayed.
• Connect lifecycle events to policy enforcement Tie provisioning, rotation, offboarding, and access review to one policy-based workflow so that role changes automatically trigger control checks. This reduces orphaned access and keeps audit evidence consistent.
• Use simulation before role changes go live Test role redesign and access policy changes against real entitlement data before deployment. Simulation helps detect hidden conflicts, preserves least privilege, and prevents new SoD violations from entering production.

Key takeaways

• Segregation of duties is becoming a cross-domain identity control, not a narrow finance workflow.
• Non-human identities make toxic access harder to see because ownership, purpose, and lifecycle are often weaker than in human accounts.
• Teams that unify policy, lifecycle controls, and access evidence will be better positioned to govern AI-era identity risk.

Key terms

• Segregation Of Duties Matrix: A segregation of duties matrix is a policy map of access combinations that should not exist in the same identity. It helps organisations prevent fraud, mistakes, and abuse by defining conflicting permissions before they are assigned, reviewed, or certified in production systems.
• Identity Governance: Identity governance is the control layer that decides who or what should get access, why that access exists, and when it should be removed. It combines policy, approvals, reviews, and evidence so access decisions are repeatable, auditable, and aligned to business risk.
• Non-Human Identity: A non-human identity is any machine or software identity that authenticates to systems and acts with execution authority. This includes service accounts, API keys, tokens, certificates, bots, and AI agents, all of which can accumulate privilege and create governance risk if unmanaged.
• Identity Certification: Identity certification is the periodic review of existing access to confirm that it is still appropriate. In mature governance programs, certification is tied to ownership, business context, and lifecycle events so that revocation happens quickly when access no longer has a justified purpose.

Deepen your knowledge

Identity governance, SoD matrices, and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is extending into service accounts and AI agents, it is worth exploring.

This post draws on content published by SafePaaS: What is a Segregation of Duties Matrix. Read the original.