Who is accountable when a misconfigured agent performs an unauthorised action?

Accountability should rest with the organisation operating the agent, not the agent itself. Teams need clear ownership for configuration approval, access assignment, monitoring, and incident response. If an agent can act autonomously, governance must document who authorized the capability, who reviews changes, and who is responsible when the agent exceeds its intended scope.

Why This Matters for Security Teams

Accountability questions become urgent when an agent can execute actions faster, broader, and less predictably than a human operator. A misconfigured agent is usually not a single “bad click”; it is a breakdown across configuration approval, scope definition, and monitoring. The operating organisation remains responsible because the agent is acting under delegated authority, not as an independent actor. That is why governance must treat agent behaviour as a controllable system risk, not an excuses-based incident after the fact.

This is especially relevant for agentic workflows that can chain tools, reuse tokens, and make runtime decisions outside the narrow intent of the original setup. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward explicit oversight, traceability, and bounded authority. NHIMG research shows why that matters in practice: 97% of NHIs carry excessive privileges, and 73% of vaults are misconfigured, creating the exact conditions where agent actions exceed intended scope.

In practice, many security teams discover accountability gaps only after the agent has already taken an unauthorised action, rather than through intentional access review and change control.

How It Works in Practice

The practical answer is to map accountability to the control plane around the agent, not to the agent as a moral or legal actor. The organisation should define who approved the agent’s capability set, who owns the secrets and workload identity behind it, who reviews changes, and who receives alerts when runtime behaviour deviates. For autonomous systems, static RBAC alone is not enough because the agent’s next action may depend on live context, not a fixed role catalog.

Operationally, mature teams combine workload identity, short-lived credentials, and runtime policy evaluation. That means the agent authenticates as a distinct workload, receives only the minimum task-specific privilege, and is constrained by policy-as-code at request time. The point is not just to issue access, but to continuously decide whether the specific action is allowed in the current context. This aligns with implementation patterns discussed by the CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix.

In NHIMG analysis of agentic risk, the same pattern appears across incidents such as the CoPhish OAuth Token Theft via Copilot Studio and the Replit AI Tool Database Deletion, where the issue was not “agent blame” but weak guardrails, overbroad access, and insufficient oversight.

• Assign a human owner for every agent capability and every connected tool.
• Use just-in-time, ephemeral credentials instead of long-lived static secrets.
• Log prompt, tool, and privilege decisions so reviews can reconstruct what happened.
• Revoke or downscope access automatically when the task, session, or context ends.

These controls tend to break down in legacy environments where service accounts are shared across workflows and the agent inherits broad standing access from older automation.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring organisations to balance agility against approval burden and monitoring cost. That tradeoff becomes most visible in high-change environments, where teams want autonomous execution but still need defensible accountability when something goes wrong. Best practice is evolving, and there is no universal standard for how much independence a production agent should have.

One edge case is a supervised agent that only drafts actions for human approval. In that model, accountability usually remains clearer because a person or team explicitly approves the final step. Another is a multi-agent pipeline where several systems share tool access. Here, responsibility can fragment unless the organisation defines a single accountable owner for each stage and for the overall workflow. This is where current guidance from the OWASP NHI Top 10 and the NIST AI Risk Management Framework is most useful: define ownership, constrain authority, and review exceptions as part of normal operations.

NHIMG’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for zero trust, which is a strong signal that agent accountability cannot be separated from identity governance. The practical takeaway is simple: if the organisation deploys the agent, it owns the outcome, even when the agent’s action was unintended.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent delegation chain causes an unauthorised action?
• 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?