What breaks when human and machine identities share the same workflow?

When a Shared Workflow Stops Having a Single Owner

The core failure is accountability collapse. Once a workflow mixes a human decision, delegated automation and autonomous execution, the old assumption that one login equals one actor no longer holds. The practical question becomes who initiated the action, who approved it, which identity exercised it, and which party must be able to explain or reverse it later.

A useful way to think about this is to separate the workflow from the login event. The login may belong to a person, but the effective action may be carried out by a service, token or agent operating with different authority. That is why shared workflows need explicit attribution boundaries, not just authentication at the start.

That boundary problem is easiest to see in environments that already blur human and machine access. NHIMG’s Human vs Non-Human Identity guide covers where ownership, lifecycle and governance diverge, while the Identity Convergence Guide explains why converging those identity types only works when you preserve distinct accountability rules.

Why Audit, Revocation and Ownership Become Ambiguous

Audit evidence breaks down first. A log line that shows a user started a workflow does not prove that the same person performed every downstream action, especially if the workflow invoked automation, delegated access or an agentic step. When teams cannot reconstruct the full identity chain, they cannot reliably answer whether an action was human-directed, system-generated or separately authorised.

Revocation becomes harder for the same reason. Removing a person’s access does not necessarily stop a running workflow, cached token, inherited privilege or service credential that still sits inside the process path. The better mental model is to revoke the whole chain of authority, not only the human account.

NHIMG’s NHI Ownership and Accountability Guide is useful here because ownership is not just an inventory problem, it is the mechanism that keeps a workflow from becoming unowned once execution moves beyond the person who launched it. The Service Account Security Guide adds the operational side of that problem, especially where shared or long-lived service accounts keep the workflow alive after the human session is gone.

What Controls Need to Follow the Whole Identity Chain

Controls need to bind action to context, not just to a front-door login. That means the workflow should carry an auditable record of the initiating human, the delegated machine identity, the scope of authority, and any step where automation can act independently. If a workflow can change data, move funds, approve access or trigger production action, every handoff needs its own traceable control point.

This is where identity choice matters. If the workflow relies on a workload or service identity, the authentication method, credential lifetime and trust boundary must match that role instead of borrowing a human pattern by convenience. NHIMG’s NHI Authentication Guide is a practical reference for the mechanisms that make machine and delegated access verifiable rather than implicit.

For workflow design, the safest pattern is least authority at each hop. The person should authorise the intent, the machine should execute only the narrow task, and the system should preserve enough evidence to prove both. If the workflow cannot produce that split cleanly, the design is too coarse for reliable accountability.

Risk and Threat Considerations

Shared human-machine workflows create a concentrated failure mode: one weak control can expose both personal and automated authority at once. Attackers also benefit from the ambiguity, because stolen human credentials, overprivileged service accounts or abused delegation paths can all look like routine workflow activity unless the chain is explicitly separated and monitored.

Failure mechanism: A compromised login, delegated token or overprivileged automation step can inherit trust from the human context and continue operating after the original user is gone, making misuse difficult to attribute or revoke cleanly.

Impact: Organisations can lose the ability to prove who authorised an action, who executed it and when to cut it off, which increases blast radius, delays containment and weakens audit defensibility.

Practitioner Guidance

What to verify: Check whether every workflow step has a distinct actor, a distinct authority scope and a distinct audit record. If a single approval path can launch actions that later execute under a different identity, verify that the handoff is explicitly logged and revocable.

Decision rule: If a workflow can outlive the human session, treat the machine side as a separate control object with its own ownership, credential lifecycle and revocation path. Do not rely on user offboarding alone to shut down the full workflow.

Practitioner takeaway: The real control objective is not “who clicked start”, it is whether every identity that can change state is separately attributable, bounded and removable.

Related resources from NHI Mgmt Group

• Why do access review programmes struggle when human and machine identities share the same control plane?
• What should security teams do when human, machine, and agentic identities all share the same trust paths?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?