Who is accountable when an autonomous worker makes an access change?

Why This Matters for Security Teams

Accountability for an autonomous worker is not just a policy question. It is an evidence question. When an agent can request, chain, and execute an access change, the organisation has to prove who delegated the task, what identity the agent used, and whether the action stayed inside approved scope. Without that chain, blame may be assigned after the fact, but accountability is weak in an audit or incident review.

This is especially urgent because autonomous systems are already exceeding intended scope in production. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and its Ultimate Guide to NHIs shows how often long-lived credentials, excessive privilege, and poor visibility combine to defeat controls. The same pattern appears in agentic environments, where runtime behaviour is harder to predict than human admin workflows.

Security teams often assume ticket approval is enough. In practice, many discover that an access change was technically authorised but operationally untraceable only after the change has already altered production access paths.

How It Works in Practice

The cleanest accountability model treats the human as the business owner, the agent as the executing workload, and the platform as the evidence layer. That means the system must preserve a durable identity chain from requester to agent session to target action. The agent should not act under a shared admin account, and it should not inherit standing privilege simply because it is “trusted.” Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance rather than static role assumptions.

In practice, that usually means:

• Issuing just-in-time credentials for the specific task, with short TTLs and automatic revocation on completion.
• Binding the agent to workload identity, such as SPIFFE or OIDC-backed proof of the workload, not a reusable password or static API key.
• Evaluating the access change at request time with policy-as-code, so approval depends on current context, data sensitivity, and target system.
• Logging the full sequence: human requester, delegated intent, agent identity, tool used, policy decision, and resulting change.

That is also where NHI governance becomes operational. NHIMG’s Key Challenges and Risks section is clear that visibility and rotation failures are common, and those weaknesses become more severe when agents can create, modify, or delegate access on their own. For organisations building agent controls, the practical standard is to minimise standing privilege and require provable delegation for every access change. These controls tend to break down when agents operate across multiple SaaS and infrastructure planes because the identity chain fragments across separate logs, tokens, and approval systems.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring organisations to balance faster automation against stronger proof of accountability. That tradeoff becomes most visible when access changes are low-risk but high-volume, or when an agent must respond in near real time.

There is no universal standard for this yet. Current guidance suggests that the most defensible model is to differentiate between low-impact delegated actions and high-impact privileged changes. For example, a bot may be allowed to update metadata or open a ticket automatically, but privilege escalation, group membership changes, or production role grants should trigger stronger approvals and shorter-lived credentials.

Edge cases matter. Shared service accounts can still appear in legacy systems, but they weaken evidentiary accountability because the action cannot be tied cleanly to a single workload instance. Multi-agent workflows introduce another layer of ambiguity: one agent may request the change, another may approve it, and a third may execute it. In those environments, current best practice is evolving toward per-step attestations and immutable audit logs. NHIMG’s 52 NHI Breaches Analysis and AI LLM hijack breach material both reinforce the same lesson: once a workload can be redirected or impersonated, attribution depends on the quality of the identity chain, not on intent statements alone.

Related resources from NHI Mgmt Group

• Why do AI agents change the access model for IAM and PAM teams?
• How do access reviews change when AI agents use enterprise-managed authorization?
• Why do autonomous attacks change the value of deception?
• When is it crucial to implement least-privilege access for AI agents?