How should organisations assign accountability when humans, service accounts, and agents share workflows?

Why This Matters for Security Teams

Shared workflows blur the line between human intent, service-account automation, and autonomous agent execution. That matters because accountability is not just a logging problem. It is a governance problem: every action needs a defensible owner, an identity source, and a target system. Without that chain of custody, incident response, audit, and legal review all stall when the same outcome could have been triggered by different actor types.

This becomes more urgent as organisations adopt agentic systems. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point to the same operational issue: when systems can act on behalf of multiple principals, attribution must be designed, not inferred after the fact. NHIMG research shows this is not theoretical. In the Ultimate Guide to NHIs, only 5.7% of organisations report full visibility into service account, which means most teams cannot reliably reconstruct who did what when a workflow spans people and machines.

In practice, many security teams encounter attribution gaps only after a production change, fraud event, or data exposure has already been traced to an indistinct workflow rather than to a clearly named actor.

How It Works in Practice

The most workable model is to treat each workflow step as a record with three linked elements: the initiating owner, the execution identity, and the resource or target. A human may approve a request, a service account may move data, and an agent may call tools, but each step should preserve provenance separately. That means logs, tickets, and policy decisions must carry actor type, identity, delegation scope, time window, and target context.

For humans, accountability usually starts with named approval, ticket references, or change records. For service accounts, it depends on workload identity, secret rotation, and tightly scoped access. For agents, current guidance suggests the identity primitive should be the workload, not the chat session or the operator’s account. Standards and implementation guidance such as the CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix reinforce the need to track tool use, escalation paths, and cross-system movement.

Operationally, teams should:

• Assign one accountable owner for each workflow, even when several identities can trigger it.
• Record the execution identity used at each step, including delegated or ephemeral credentials.
• Bind tool calls to a target and a policy decision so later review can reconstruct intent and impact.
• Use short-lived credentials and explicit revocation for non-human actors where possible.
• Separate approval authority from execution authority so one identity cannot silently self-authorise.

NHIMG’s research on the OWASP NHI Top 10 also highlights the risk of excessive privilege and weak visibility across non-human identities. These controls tend to break down in high-throughput CI/CD and multi-agent environments because rapid handoffs erase the practical link between approval, execution, and final system effect.

Common Variations and Edge Cases

Tighter accountability often increases process overhead, requiring organisations to balance forensic clarity against workflow speed. That tradeoff is real in environments where humans, scripts, and agents all touch the same assets, especially when there is no universal standard for attributing actions across mixed actor types yet.

One common edge case is delegated action: a human initiates work, but an agent performs the sub-tasks and a service account executes the final API call. In that pattern, the human remains accountable for the business decision, while the agent and service account are accountable for their executed scopes. Another edge case is shared service accounts, where attribution collapses unless the team overlays step-level telemetry, signed approvals, and per-request authorization. Best practice is evolving toward context-aware decisions that evaluate who is acting, what tool is being used, and whether the action matches the declared task.

In mature environments, this often means pairing policy-as-code with immutable audit trails and identity federation. In regulated environments, it may also require mapping evidence to control sets such as the NIST AI Risk Management Framework and the Analysis of Claude Code Security when coding agents can alter repositories, build pipelines, or deployment artefacts. Organisations that rely on coarse “system did it” attribution lose the ability to assign responsibility once an agent chains multiple actions across tools and systems.

Related resources from NHI Mgmt Group

• Why do service accounts and AI agents break traditional PAM models?
• Who is accountable for identity risk when access spans humans, admins, and service accounts?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?