Who is accountable when an agentic tool takes an action on behalf of a person?

Why This Matters for Security Teams

Accountability changes once a tool can act, chain steps, and choose actions at runtime. In a normal delegated workflow, a human request maps cleanly to a human decision. In an agentic workflow, that same request can trigger tool calls, data movement, and side effects that are not obvious at the moment of initiation. That is why current guidance suggests treating the delegation chain as part of the control model, not just a logging concern.

The risk is not only misuse. It is also ambiguity. If an agent posts data, changes records, or triggers an external workflow, defenders need to know who approved the session, what scope was granted, and whether the action stayed inside policy. Research on AI agents shows that scope creep is already common: NHIMG’s AI Agents: The New Attack Surface report notes that 80% of organisations report agent actions beyond intended scope. That is a governance issue as much as a security issue, and it is also why the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both emphasize traceability and oversight.

In practice, many security teams encounter accountability gaps only after an agent has already taken an unexpected action and the audit trail cannot prove who authorised it.

How It Works in Practice

The practical model is to make the human initiator accountable, while the agent operates under a tightly bounded delegation. That means the session must carry an explicit linkage between the person, the agent identity, the approved scope, and the actual action. Good logs are necessary, but logs alone are not enough. They must be paired with runtime authorisation checks so the system can decide whether the agent may act on the requested resource, in the requested context, at the requested time.

Practitioners increasingly split this into four controls:

• Authenticated human approval for the delegated session, especially for high-impact actions.
• Workload identity for the agent itself, so the system knows what the agent is, not just what secret it holds.
• Just-in-time access with short-lived scopes and revocation at task completion.
• Immutable audit records that preserve the delegation chain, tool calls, and downstream side effects.

This is where workload identity patterns such as SPIFFE, SPIRE, and short-lived OIDC tokens become important, because they support cryptographic proof of the agent identity without relying on static credentials. That direction aligns with the analysis in OWASP NHI Top 10 and the implementation guidance emerging in the CSA MAESTRO agentic AI threat modeling framework. The governance question is not whether the tool had access in general, but whether this specific action was authorised under this specific delegation.

These controls tend to break down in environments that still rely on shared service accounts, long-lived API keys, or loosely integrated SaaS automation where the original request and the eventual action cannot be correlated end to end.

Common Variations and Edge Cases

Tighter delegation control often increases friction for users and operators, requiring organisations to balance faster automation against stronger evidence of authority. That tradeoff becomes sharper when agents operate across multiple systems or hand off work to other agents, because the accountability chain can become fragmented very quickly.

There is no universal standard for this yet. Best practice is evolving, especially for multi-agent workflows, shared copilots, and tools that can autonomously retry, escalate, or re-plan tasks. In lower-risk cases, a simple approval plus session log may be sufficient. In higher-risk cases, current guidance suggests adding step-up approval, policy-as-code at request time, and explicit limits on what the agent can chain together. The Ultimate Guide to NHIs — 2025 Outlook and Predictions is useful for understanding why static credential models do not keep pace with autonomous systems.

Edge cases also matter. If a human merely launches a job but the agent later improvises or expands the task, accountability can still sit with the initiator, but only if the organisation has defined the scope limits clearly. If no approval boundary exists, or if the agent can act outside the session without re-authentication, then the control model has already failed. For real incident response, the ability to reconstruct who delegated what, and when, is often more valuable than proving which internal process was nominally followed.

Related resources from NHI Mgmt Group

• Who is accountable when an agentic workflow takes a wrong action in production?
• What makes agentic AI an NHI governance issue?
• Who is accountable when an AI agent takes an unsafe action?
• Who is accountable when an autonomous agent takes an unsafe action?