Who should be accountable when an agent makes a risky tool call?

Accountability should follow the human delegator, the sponsoring team, and the policy owner, not just the agent credential. The useful audit question is which approved delegation path enabled the call and which runtime control allowed it. That structure makes agent behaviour governable instead of anonymous.

Why This Matters for Security Teams

A risky tool call is not just a technical event. It is a delegated action that can move data, trigger side effects, or widen access in ways that look normal at runtime but create security and compliance exposure later. For that reason, accountability cannot stop at the agent credential. It must map back to the human delegator, the sponsoring team, and the policy owner who allowed the action path.

This is where agentic AI differs from standard service-account governance. A human can be warned, trained, and bounded by procedure. An agent can chain tools, retry, escalate context, and make decisions that were never enumerated in a static role design. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward traceable decision paths, not anonymous execution.

NHIMG research shows the scale of the problem: in the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, which means risky calls often succeed because overbroad access already exists. In practice, many security teams discover accountability gaps only after the tool call has already caused data movement or privilege expansion, rather than through intentional control design.

How It Works in Practice

Accountability should be assigned through the delegation chain, not the runtime token alone. The useful audit trail answers four questions: who approved the agent’s purpose, which team sponsored the workload, what policy permitted the call, and which runtime control evaluated the request. That is consistent with the direction of both OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize policy-aware control of autonomous behavior.

In practice, a strong model uses three layers:

• Human delegator: authorises the agent’s mission, data scope, and tool boundaries.

• Sponsoring team: owns the workload, receives alerts, and is accountable for safe operating conditions.

• Policy owner: defines the rules for tool use, escalation, logging, and revocation.

At runtime, the agent should operate under workload identity, short-lived credentials, and request-time policy evaluation. That means a tool call is approved because the current intent, context, and destination match policy, not because the agent has a broad standing role. This is also where implementation patterns such as identity-bound tokens, scoped delegation, and revocable JIT access become useful. When teams need a threat-oriented lens for what can go wrong, OWASP NHI Top 10 and MITRE ATLAS adversarial AI threat matrix help frame escalation, misuse, and chaining risk.

That structure makes post-incident review practical: if the call was allowed, the question becomes whether the delegation path was appropriate; if it was not allowed, the question becomes why policy failed open. These controls tend to break down in multi-agent systems with shared tool brokers because ownership, intent, and execution context become difficult to attribute cleanly.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance traceability against developer velocity and incident response speed. That tradeoff is real, especially when agents are embedded in customer support, code generation, or SecOps workflows where tool calls are frequent and time-sensitive.

There is no universal standard for agent accountability yet, so current guidance suggests treating the most specific accountable party as the one who created the approved delegation path, while preserving secondary responsibility for the team that allowed the workload to run. In regulated environments, that may need to be extended into formal approval records, change management, and evidence retention.

Edge cases matter. For shared agents used by multiple business units, the sponsoring team may not be the same as the policy owner. For externally hosted agents, the organisation still owns the delegated outcome if it approved the mission and exposed its data or systems. For autonomous workflows that trigger financial, legal, or production-impacting actions, accountability should also include explicit kill-switch ownership and revocation authority. The safest reading of current best practice is to avoid “the agent did it” as a blame boundary, because that hides the real control failure and slows remediation. The lesson is reinforced by NHIMG’s Top 10 NHI Issues, where overprivilege and weak governance repeatedly turn routine identity failures into business incidents.

Related resources from NHI Mgmt Group

• Who should be accountable when an agent makes a high-risk decision?
• Who is accountable when an AI agent makes a risky decision?
• Who is accountable when an employee-facing AI agent makes a risky action?
• Who should be accountable for risky MCP actions in enterprise environments?