Rethinking segregation of duties for hybrid human-machine work

At a glance

What this is: This is an analysis of why segregation of duties fails in hybrid human-machine workflows, and how machine identities now carry financial control risk that older human-only models miss.

Why it matters: It matters because IAM, PAM and IGA teams now have to govern duties, ownership and evidence across humans and non-human identities in the same control fabric.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Gathid's analysis of segregation of duties in hybrid human-machine work

Context

Segregation of duties was built for a world where people requested work, other people approved it, and a separate person executed it. That model assumes stable identities, visible ownership and workflow checkpoints that can be audited after the fact. In a hybrid human-machine workforce, those assumptions collapse because machine identities can create, modify and execute actions without the same organisational boundaries that apply to employees.

The governance problem is broader than finance. AI agents, automation scripts, APIs and cloud services now operate inside the same control surface as human users, but they do not fit job descriptions, resignation processes or the usual access review cadence. That leaves IAM and PAM teams trying to enforce SoD across actors whose privileges can expand silently and whose accountability is often unclear. For practitioners, the question is no longer whether SoD still matters, but whether the programme can see every identity it is supposed to govern.

Key questions

Q: What breaks when segregation of duties is applied to machine identities?

A: Segregation of duties breaks when a bot, script or service account can span request, approval and execution inside one workflow. The control assumes human separation of duties and visible accountability, but machine identities can inherit privileges from templates and automation layers that collapse those boundaries. The result is a material action path with no clear human checkpoint.

Q: Why do machine identities increase financial control risk?

A: Machine identities increase financial control risk because they can operate with standing privilege, scale across systems and keep acting after the original business need has changed. In finance workflows, that can allow silent supplier changes, record updates or payment actions without the friction that normally slows human abuse. The risk is hidden privilege plus high velocity.

Q: How do security teams detect SoD violations in hybrid workflows?

A: Teams detect SoD violations by tracing the full identity chain across systems, not by reviewing one application at a time. The key signal is whether one workflow path can create, approve and execute a financially material action. That requires daily visibility into entitlements, ownership and workflow lineage, then simulation of changes before they are deployed.

Q: Who should own segregation of duties for automation and API accounts?

A: Ownership should sit with both the business process owner and the technical custodian, because machine identities affect financial control and system operations at the same time. If no one owns renewal, review and offboarding, the account can outlive the workflow it supports. That makes accountability visible and auditable instead of assumed.

Technical breakdown

Why classical segregation of duties breaks in machine workflows

Classical segregation of duties separates requesting, approving and executing actions across different people. That works when identity is human, workflow is linear and access changes are visible. In machine-driven environments, a single bot, script or agent may inherit permissions from templates, service principals or cloud automation, then cross control boundaries that used to be enforced by job role separation. The failure is structural: the control assumes a stable human operator behind each action, but machine identities can combine steps that would be separated in a human process. Once that happens, the duty boundary is no longer tied to a person or a clear approval trail.

Practical implication: Map every automated workflow to the duties it spans, not just the systems it touches.

Machine identity ownership and lifecycle are part of SoD

Machine identities are not self-governing. They need explicit ownership, renewal, offboarding and monitoring because their privileges often persist after the business reason for access has changed. If an API key, service account or bot account is never tied to a accountable owner, SoD becomes a paper control rather than an enforceable one. Lifecycle management matters because the identity may still be active long after the workflow it supported has changed. In practice, SoD for machines depends on whether the organisation can prove who owns the credential, why it exists, and when it should be removed or revalidated.

Practical implication: Require named ownership and expiry for every machine identity that can affect financial workflows.

Privilege chains create hidden conflicts across systems

Hybrid workflows often move through several identity layers, such as an employee triggering a script that uses a service account to call an API, which then writes to a financial system. Each step may look acceptable in isolation, yet the combined path can violate SoD because the same actor chain effectively requests, approves and executes a material action. This is why static role reviews miss the real problem. The control surface is not a single entitlement, but the end-to-end privilege chain that links people, machines and systems across trust boundaries. Visibility at the chain level is what turns SoD from a policy statement into a demonstrable control.

Practical implication: Trace end-to-end privilege chains and test for conflicts across the full workflow, not within one application.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

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

NHI Mgmt Group analysis

SoD is no longer a human-only control, because the workforce is no longer human-only. The article’s core point is that machine identities now participate in financially material workflows that traditional segregation logic was never designed to govern. That matters because the control objective has not changed, but the actor set has. Practitioners should treat machine participation as a first-order SoD design problem, not an edge case.

Standing privilege in machine workflows is the real control failure, not automation itself. Automation becomes risky when credentials persist beyond the work they were created to perform, then inherit broader access as systems evolve. The operational issue is not that machines act quickly, but that they often act with privileges that were never re-justified after drift. SoD programs need to focus on the duration and scope of machine entitlements, not the existence of automation.

Identity blast radius is the right concept for hybrid financial control. The article shows that one identity chain can span supplier creation, payment changes, data modification and production promotion. That collapses multiple checks into a single execution path, which is why board reporting has to shift from access counts to the maximum business impact of any one identity. Practitioners should assess how far a compromised machine identity can move before detection.

Continuous evidence is now part of SoD assurance. Quarterly certification cannot prove that machine identities stayed within approved duties when access changes hourly and workflows are elastic. The governance model needs daily visibility into who or what can move money, alter records or approve actions, because the proof of control must match the speed of the process. Boards and auditors will increasingly expect demonstrable lineage, not policy statements.

Financial control teams and identity teams now share the same problem space. SoD failure in a hybrid workforce is simultaneously an IAM issue, a PAM issue and a finance-control issue. That means programme ownership cannot sit only with compliance, and it cannot sit only with engineering either. Practitioners should build joint governance around machine identities, with finance, identity and security sharing the same evidence model.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For lifecycle depth and control design, see the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Identity blast radius: the useful metric here is not how many controls exist, but how far one compromised machine identity can move before the organisation notices. As automation expands, SoD programmes need to shift from role review to chain review, because the hidden conflict often sits between systems rather than inside one system.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, which means most control teams are still trying to govern machine participation with partial evidence. That gap will continue to surface first in finance, where access needs to be provable and time-bound.

For the next phase of programme maturity, teams should align SoD with Zero Trust and lifecycle governance rather than treating it as a narrow audit control. The practical test is simple: can the organisation show who or what owns each privileged action, and can it prove that access did not persist beyond the workflow? See the Ultimate Guide to NHIs , Standards.

For practitioners

• Model SoD around identity chains, not single accounts. Inventory the full request-to-execute path for any financial workflow and identify every human and machine identity that participates. Flag any chain where one actor can create, approve and execute the same material action, even if it does so through different systems.
• Assign accountable owners to every machine identity. Require a named business and technical owner for each service account, bot or API credential that can touch financial systems. Tie that owner to renewal, review and offboarding decisions so the identity cannot persist without justification.
• Timebox and review machine privileges continuously. Replace open-ended access with explicit expiry for credentials used in procurement, payments, reporting and release automation. Monitor for privilege drift across templates, directories and orchestration tools, then remove access when the workflow no longer needs it.
• Test privilege-chain conflicts before deployment. Simulate workflow changes before they go live and check whether the combined path creates a SoD violation across systems. Focus on hidden conflicts created by automation scripts, cloud roles and API-driven actions rather than only on named user roles.
• Report identity risk in financial terms. Translate machine identity exposure into business impact by showing which accounts can move money, change vendor data, or alter financial records. Use that evidence to brief boards, auditors and insurers on the control failures that matter most.

Key takeaways

• Traditional segregation of duties weakens when machine identities can request, approve and execute material actions inside the same workflow.
• The control gap is visible in the numbers: only 20% of organisations formally offboard and revoke API keys, which leaves machine access living longer than the business need.
• Practitioners should move to identity-chain visibility, explicit ownership and timeboxed privilege if they want SoD to remain auditable in hybrid environments.

Key terms

• Segregation of duties: Segregation of duties is the practice of splitting a sensitive process so no single actor can request, approve and execute the same material action. In hybrid environments, the actor may be a person, service account, script or agent, so the control must be evaluated across the full identity chain, not just at the user role level.
• Machine identity: A machine identity is any non-human account or credential used by software, infrastructure or automation to authenticate and act. It includes service accounts, API keys, tokens and bot credentials. These identities must be owned, reviewed and retired because they can accumulate privilege just like human accounts, often without the same visibility.
• Identity chain: An identity chain is the linked sequence of human and non-human actors that carries an action from request to execution. It matters because each step may appear safe in isolation while the combined path creates a SoD conflict, privilege escalation route or hidden accountability gap.
• Identity blast radius: Identity blast radius is the maximum business impact that a compromised or over-privileged identity can reach before detection or containment. The term is useful for hybrid workforces because the key question is not only who has access, but how far one credential can move across systems and controls.

Deepen your knowledge

Segregation of duties for machine identities is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme needs to govern bots, scripts and APIs alongside people, this is a practical place to start.

This post draws on content published by Gathid: Rethinking Control In A Hybrid Human-Machine Workforce. Read the original.