TL;DR: Traditional segregation of duties breaks down when AI agents, scripts, APIs and cloud services can request, approve and execute financially material actions outside human-paced checkpoints, according to Gathid. The control problem is no longer just who has access, but whether ownership, lifecycle and privilege chains can still be proven in a machine-driven workflow.
At a glance
What this is: This is an analysis of why classical segregation of duties breaks down in hybrid human-machine finance workflows as machine identities inherit broad privileges and cross control boundaries.
Why it matters: It matters because identity teams now have to govern SoD across humans, service accounts, scripts and AI agents, not just employee roles and approvals.
Context
Segregation of duties is an identity and financial control problem, not just an accounting rule. In hybrid workflows, humans and non-human identities can both initiate, approve and execute material actions, which means traditional role-based checkpoints no longer describe how work actually happens.
The governance gap is visibility. If machine identities can create suppliers, modify records or move transactions without clear ownership and lifecycle controls, SoD turns into an assumption rather than an auditable control. That is the core IAM and NHI problem this article raises.
The article frames this as a post-human operating model where access relationships change continuously across systems. That makes continuous identity governance, not quarterly review cycles, the relevant control plane.
Key questions
Q: What breaks when segregation of duties is not enforced in identity governance?
A: When segregation of duties is absent, a single identity can create, approve, and audit the same sensitive action. That removes independent oversight and makes fraud, unauthorized changes, and compliance failures much easier to hide. The most dangerous failures usually appear as conflicting permissions across finance, HR, IAM, and privileged access workflows.
Q: Why do machine identities create so much SoD risk in finance workflows?
A: They create risk because they can scale quickly, inherit permissions from automation and operate without the visibility that human managers rely on. When a bot or service account spans supplier setup, payment changes or record updates, separation of duties is no longer enforced by role design. The business impact is unauthorized movement of money or data.
Q: How do security teams know if SoD controls are actually working?
A: SoD controls are working only if live access state matches the approved separation model across systems. Teams should verify that no identity can both initiate and validate the same sensitive transaction, and that exceptions are time-bound and independently reviewed. If certification reports look clean but operational workflows still allow self-approval, the control is failing.
Q: What should organisations do when automation spans conflicting control surfaces?
A: They should treat the workflow as a control design problem, not just an access problem. If one identity can create, approve and execute across the same business process, the organisation needs to split duties across separate identities, define ownership for each non-human identity and narrow the privileges tied to each step.
Technical breakdown
Why classical segregation of duties fails in hybrid workflows
Classical SoD assumes that identity, authority and execution sit in stable human roles. That model breaks when AI agents, scripts, APIs and cloud services operate as independent actors inside the same workflow. The control boundary is no longer a person with a clear job description, but a chain of machine identities that can inherit privilege from templates, directories and automation. Once those chains span multiple systems, a single identity can effectively request, approve and execute the same business process. Practical implication: SoD rules must be defined around identity chains and workflow surfaces, not only employee roles.
Practical implication: Model SoD at the identity chain level so conflicting capabilities are visible across humans and machine identities.
How machine identity privilege drift creates hidden SoD conflicts
Machine identities do not stay bounded by organisational charts or manual oversight. They accumulate permissions as systems evolve, and that privilege drift is often invisible because the identity never leaves, complains or triggers a manager review. In practice, a bot or service account can end up spanning procurement, finance and deployment functions that were intended to be separated. That is why least privilege and SoD start to converge in hybrid environments: if privilege growth is not tied to ownership and lifecycle, the control fabric stops being provable. Practical implication: identity governance must track ownership, renewal and entitlement growth for every non-human identity.
Practical implication: Tie machine identity governance to ownership and lifecycle so privilege drift cannot silently create SoD violations.
Why continuous validation replaces periodic certification for SoD
Periodic certification works when access changes slowly and human supervisors can validate exceptions after the fact. That assumption fails when non-human identities scale elastically and workflows change hourly. A daily or near-real-time identity model is needed because SoD conflicts can appear and disappear faster than quarterly reviews can detect them. In this environment, evidence must be generated from current privilege relationships, not from static attestations. Practical implication: organisations need continuous validation of access relationships, exception visibility and privilege lineage if they want SoD to remain defensible to auditors and boards.
Practical implication: Shift SoD assurance from periodic review to continuous validation of current privileges and exceptions.
Threat narrative
Attacker objective: To use legitimate-looking machine access to move, alter or approve financially material activity without triggering the controls that separate duties.
- Entry occurs when compromised credentials, inherited privileges or overly broad machine access let an automation identity enter a financial workflow.
- Privilege abuse follows when the machine identity is able to cross SoD boundaries and perform steps that should have been separated across multiple actors.
- Impact emerges as unauthorised payments, misstatements, altered supplier details or other financially material actions are completed without effective human checkpointing.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Segregation of duties is becoming an identity lineage problem, not just a permissions problem. Classical SoD was designed for human-paced workflows with visible handoffs and stable roles. Once AI agents, scripts and APIs participate in the same business process, the control question shifts to whether the full privilege chain can be proven at any moment. The practitioner implication is that SoD design now belongs in identity governance, not only finance policy.
Ownership is the missing control when machine identities participate in financial workflows. A bot or service account can create suppliers, update records or move data without ever passing through the accountability mechanisms built for employees. That means the governance gap is not simply excess access, but unowned access that no manager can certify. Practitioners need machine identity ownership models that mirror the accountability expected of human roles.
Continuous validation is the only defensible SoD posture in environments where privilege changes faster than review cycles. Quarterly certification assumes access is stable long enough to be reviewed, but machine identities often change shape daily as systems scale and workflows evolve. That breaks the evidentiary basis of traditional control testing. The implication is that SoD assurance must become dynamic, with identity relationships reconstructed continuously rather than sampled intermittently.
Hybrid workforce governance now has to treat automation as financially material activity, not background infrastructure. When a single identity can request, approve and execute across systems, the distinction between operational automation and control failure disappears. That changes how boards, auditors and insurers should evaluate risk because the exposure is no longer just technical privilege, but unobservable business authority. Practitioners should frame NHI governance as a financial control issue, not a niche IAM concern.
Identity blast radius is the right named concept for this shift. In a hybrid human-machine environment, the key question is how far one identity can move across business controls before anyone notices. That blast radius may span supplier creation, payment approval, data modification and release promotion within the same workflow. Practitioners should measure SoD by the maximum business damage a single identity can reach, not by role titles alone.
What this signals
Identity lineage is now the operational unit of SoD. Programme owners should stop thinking only in terms of roles and start tracing how humans and non-human identities inherit, reuse and accumulate authority across workflows. That is where hidden conflicts emerge, and it is where governance has to be measured.
Machine identity ownership is becoming a board-level control question. If no named business owner can justify a bot, API or service account, the organisation cannot prove why it exists, what it can do or when it should be retired. That leaves SoD dependent on assumptions instead of evidence.
Converged identity governance is the practical response. Organisations that already manage human access reviews, PAM and lifecycle controls have the building blocks for this shift, but they need to extend them to machine identities and cross-system privileges.
For practitioners
- Map financial workflows to identity chains Trace where humans, bots, scripts, APIs and cloud services each request, approve and execute material actions so SoD boundaries reflect actual workflow paths.
- Assign named ownership to every machine identity Require a business owner, purpose statement and renewal cycle for each non-human identity that can touch finance, procurement or production data.
- Timebox and monitor exceptions Replace open-ended SoD exceptions with visible, time-limited approvals and alert on any machine identity that retains conflicting privileges beyond the approved window.
- Simulate privilege changes before deployment Test proposed entitlement changes against SoD rules before they reach production so hidden conflicts are caught before they can affect financial systems.
- Report identity risk in financial terms Translate machine identity exposure into fraud, misstatement, audit evidence and cost-of-capital language so board reporting reflects business impact.
Key takeaways
- Hybrid SoD fails when machines can participate in the same request, approval and execution chain that older controls assumed would stay human.
- The central exposure is not only excess access, but unowned and unreviewed machine privilege that can cross financial control boundaries.
- Continuous identity validation and explicit ownership are the controls that make SoD defensible in post-human workflows.
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 NIST SP 800-53 Rev 5 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 centres on machine identities carrying excessive privileges across finance workflows. |
| NHI-01 — Improper Offboarding | Unowned machine identities and stale automation access are a core governance failure in the article. | |
| NHI-09 — NHI Reuse | The article describes identities inheriting permissions from scripts, templates and legacy directories. | |
| Recommendation — Inventory and reduce overprivileged non-human identities that can span conflicting business steps. Retire machine identities when workflows change and offboard automation that no longer has a business owner. Separate and track reused credentials or identities so inherited access does not blur SoD boundaries. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SoD depends on governing entitlements and authorizations across human and machine identities. |
| Recommendation — Apply entitlement governance to machine identities so conflicting authorizations are visible before they reach production. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the control principle the article says machine identities routinely violate. |
| Recommendation — Enforce least privilege across automation accounts and remove broad access that lets one identity span multiple duties. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The article's risk story is rooted in compromised credentials and privilege abuse. |
| Recommendation — Map machine identity exposure to credential access and privilege escalation paths in your threat monitoring. | ||
Key terms
- 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.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Privilege Chaining: Privilege chaining is the process where one entitlement unlocks another access path, often across systems or roles that were never reviewed together. It turns separate permissions into a larger attack path and is a common reason one compromised identity can reach more than intended.
- Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
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 June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org