Who is accountable when an AI agent runs a query on behalf of a user?

Why This Matters for Security Teams

When an AI agent runs a query on behalf of a user, the security question is not just “who clicked submit?” It is who authorised the agent, which identity minted the token, and what policy allowed that runtime action. That matters because autonomous systems can chain tools, repeat actions, and continue working long after the original user context has faded. In the AI Agents: The New Attack Surface report, SailPoint found that 80% of organisations said their AI agents had already acted beyond intended scope, including unauthorised access and credential exposure.

Current guidance suggests accountability must follow the identity chain, not the interface event alone. That aligns with NIST AI Risk Management Framework principles and the OWASP Agentic AI Top 10, both of which emphasise governance, traceability, and runtime control for agentic systems. In practice, many security teams discover missing audit links only after an agent has already accessed data or invoked tools that were never intended for that user session.

How It Works in Practice

For agentic workloads, accountability should be built from three traceable layers: human delegation, workload identity, and runtime authorisation. The human provides intent, the platform issues an identity-bearing token to the agent, and the policy engine decides whether the specific query, tool call, or data access is allowed at that moment. This is where static RBAC breaks down: an agent does not have a fixed, human-like job pattern. Its behaviour is goal-driven, dynamic, and often unpredictable.

Practitioners are moving toward intent-based authorisation, JIT credential provisioning, and short-lived secrets. That means the agent receives only the credentials needed for the current task, with automatic revocation on completion. In mature deployments, the agent’s workload identity is the primary proof of what the agent is, while the user’s delegation record proves why it was allowed to act. Technologies such as SPIFFE/SPIRE and OIDC-backed workload tokens are commonly used to support this pattern, although there is no universal standard for implementation detail yet. Guidance from the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework both point toward policy evaluation at request time, not just at onboarding.

The operational record should also show the query, the delegated scope, the tool invoked, the policy decision, and the resource touched. That is the minimum evidence chain needed to explain accountability. NHIMG has repeatedly noted that agentic systems are a new attack surface; the OWASP NHI Top 10 and the AI LLM hijack breach analysis both reinforce why runtime controls and auditability have to move with the agent. These controls tend to break down when agents are allowed to operate across loosely integrated tools without a shared identity and policy plane because the evidence chain fragments across systems.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations must balance speed against audit depth. That tradeoff becomes sharper when an agent acts across multiple business units, because the delegated intent may be clear to one owner but opaque to another. Best practice is evolving, but current guidance suggests each material query should be linked to a human sponsor, a workload identity, and a decision log.

Edge cases appear when the agent uses embedded credentials, shared service accounts, or long-lived API keys. Those patterns blur accountability and make it difficult to prove whether a query was a legitimate delegation or a misuse of standing privilege. The same risk shows up in breach research: the Moltbook AI agent keys breach and the DeepSeek breach both illustrate how exposed secrets can collapse the trust chain around an agent. The OWASP Top 10 for Agentic Applications 2026 and MITRE ATLAS adversarial AI threat matrix are useful references when teams need to map these failure modes to concrete controls.

There is also no universal standard yet for whether final accountability sits with the application owner, the model operator, or the business user in every scenario. What is consistent is that organisations should preserve a verifiable chain from intent to token to action, and they should revoke the agent’s access the moment that chain can no longer be defended. This matters most in multi-agent pipelines and tool-rich environments, where one agent can trigger another and the original actor becomes difficult to reconstruct.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• When do AI agent credentials create more risk than they reduce?