Who is accountable when an agent performs an action that the requester could not do directly?

Why This Matters for Security Teams

Accountability becomes difficult the moment an agent is allowed to execute an action that a human requester could not perform directly. That is not just a logging problem. It is an authorisation and delegation problem, because the requester may have had the intent, while the agent had the operational capability. Current guidance suggests treating that gap as a control failure, not an audit curiosity, especially where tool use, API calls, or data movement are involved.

This is why NHI governance and agentic AI governance converge. The same credential sprawl and weak visibility patterns seen across non-human identities also appear in autonomous systems. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — 2025 Outlook and Predictions, which helps explain why delegation chains are often reconstructed after an incident rather than designed up front. In practice, many security teams discover the authority gap only after the agent has already touched production data, rather than through intentional delegation review.

How It Works in Practice

Practical accountability starts by separating three things: the human requester, the agent principal, and the policy that allowed the task. For autonomous or agentic systems, static RBAC is often too blunt because the agent’s behaviour is dynamic and goal-driven. An agent may chain tools, choose a different path than expected, or request privileges that were never part of the original human workflow. That is why current practice is moving toward intent-based or context-aware authorisation, where decisions are made at runtime based on the task, data sensitivity, environment, and step in the workflow.

Security teams should use workload identity as the identity primitive for the agent, then layer ephemeral credentials on top. Standards and implementation guidance from the NIST AI Risk Management Framework, the OWASP Agentic AI Top 10, and the CSA MAESTRO agentic AI threat modeling framework all point toward runtime policy checks, tight scoping, and explicit provenance.

• Issue short-lived tokens per task, not long-lived shared secrets.
• Bind each request to a human approval record, agent ID, and data object touched.
• Evaluate policy at request time using full context, not only the requester’s base role.
• Revoke credentials automatically when the task completes or the plan changes.
• Log tool calls separately from business actions so audit teams can reconstruct delegation.

NHIMG case studies reinforce the operational risk: the CoPhish OAuth Token Theft via Copilot Studio and Replit AI Tool Database Deletion show how agent access can be wider than the human’s own direct permissions. These controls tend to break down when agents are granted broad workspace tokens, because the agent can pivot across tools faster than approval or monitoring systems can react.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, requiring organisations to balance auditability against latency and workflow friction. That tradeoff is real, especially in agentic systems where every step may trigger another decision point. There is no universal standard for this yet, but best practice is evolving toward per-task authorisation for high-risk actions and broader standing access only for low-risk retrieval tasks.

One common edge case is the shared agent service account used by multiple users or workflows. In that model, accountability becomes blurred unless the platform records who requested what, when the agent was authorised, and which data or system was affected. Another edge case is delegated action across tenants or environments, where the human may be allowed to ask for the task but not to execute it in production. In those cases, the organisation remains accountable for the delegation path it enabled, while the requester remains accountable for initiating the request.

For agentic systems, the more useful question is often not “who clicked the button” but “who was allowed to ask for this outcome, under what policy, and with what guardrails.” NHIMG’s OWASP NHI Top 10 highlights why delegated execution must be constrained, because the agent can become the real actor even when the human remains the source of intent.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent performs an unauthorized action after injection?
• Who is accountable when an AI agent performs an unauthorized action in a SaaS product?
• Who is accountable when an agent performs a sensitive action without adequate approval?
• Who is accountable when a delegated agent performs the wrong tool action?