Who should be accountable when an agent makes a high-risk decision?

Accountability should sit with the governance chain that approved the agent, the intent, and the scope, not with the agent alone. High-risk actions need a traceable delegation record that links the human approver, the allowed action, and the policy version in force when the step was taken.

Why Accountability Cannot Stop at the Agent

High-risk decisions made by an agent are not equivalent to human error because the agent acts through delegated authority, tool access, and runtime context. The real accountability question is who approved the delegation, what scope was granted, and which controls were active at the moment of execution. That is why current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 treats governance, traceability, and oversight as design requirements rather than after-the-fact documentation.

NHI Management Group research shows why this matters operationally: in the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, which means an agent’s decision can quickly become a privilege-use event with broad blast radius. In practice, many security teams discover accountability gaps only after an agent has already taken the action, rather than through intentional delegation review.

How Accountability Should Be Assigned in Practice

Accountability should be mapped to the governance chain, not to the software entity acting on behalf of that chain. A practical model is: product or business owner defines the use case, security or risk approves the policy, the human approver signs off on the agent’s allowed scope, and the platform records the policy version, runtime context, and action outcome. For agentic systems, this is closer to intent-based governance than classic RBAC, because the question is not only who can act, but under what conditions the agent may act.

That is why implementation usually combines workload identity, just-in-time credentials, and policy-as-code. The identity layer should prove what the agent is at runtime, while the authorisation layer evaluates what it is trying to do. Runtime controls should reference the approved intent, the action boundary, and the current risk state, then record an immutable audit trail. The CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix both reinforce the need to treat agent decisions as security-relevant events, not ordinary application transactions.

• Require named human owners for each agent and each high-risk workflow.
• Bind approval to a specific intent, scope, and expiry window.
• Issue task-scoped credentials or tokens with short TTLs.
• Log the policy version and context for every privileged action.
• Escalate to human review when the agent exceeds its approved decision boundary.

For practitioners, the decisive control is not “who pressed deploy” but “who retained decision authority when the agent acted.” These controls tend to break down when agents chain tools across multiple systems because the original approver rarely sees the full downstream impact.

Where the Model Breaks Down and What to Watch For

Tighter accountability often increases operational overhead, requiring organisations to balance faster automation against stronger review and evidence retention. There is no universal standard for this yet, especially for multi-agent workflows, but best practice is evolving toward explicit delegation records and continuous policy evaluation. The hard edge case is exception handling: if a human can override policy informally, then accountability becomes ambiguous unless the override is itself logged, approved, and time-bounded.

Another common gap appears when teams treat all agent actions as equivalent. Low-risk retrieval can often be governed with lighter controls, while payment approvals, infrastructure changes, or customer-impacting actions need stronger gating and pre-authorisation review. NHI security issues such as exposed credentials and long-lived secrets amplify the problem, which is why the OWASP NHI Top 10 and the NIST Cybersecurity Framework 2.0 remain useful for anchoring ownership, logging, and recovery expectations.

In regulated environments, the safest rule is simple: the agent may execute, but only a governed human chain can be accountable for the authorisation and the risk acceptance. This is especially important when autonomous systems operate on stale credentials or inherit access from legacy service accounts.

Related resources from NHI Mgmt Group

• What makes idle secrets such a serious NHI risk?
• When should organisations treat an NHI as a high-priority risk?
• Who is accountable when an AI agent makes a risky decision?
• Who is accountable when a spawned agent makes an unauthorized downstream decision?