They shift to the deployer because the deployer chooses the tools, defines the policies, grants the credentials, and decides what can auto-approve. Once those choices shape the action path, liability follows the operating context, not just the model output. Vendors remain relevant for model defects, but deployer governance becomes the primary evidence target.
Why deployer choices usually dominate the liability analysis
The liability question usually shifts to the deployer because the deployer turns a general-purpose model into an operational system with real authority. Tool selection, approval thresholds, credential scope, and workflow design determine whether the system can merely suggest actions or can actually cause loss. That makes the deployer’s governance choices easier to test, document, and assign than the model’s raw output.
Courts, insurers, and internal investigators tend to focus on who set the operating conditions that made the event possible. If the deployer allowed an agent to reach production systems, consume privileged tokens, or auto-approve risky actions, those decisions often become the most concrete evidence of control. Vendor responsibility does not disappear, but it is usually narrower unless a product defect or misleading representation is central.
In practice, the deployer is the party that can explain why a particular action was allowed, why a policy was permissive, and why a safer control was not used. That is why the liability analysis often follows the governance trail rather than the model architecture alone.
What makes deployer governance the evidence target
Liability disputes usually turn on provenance, scope, and control. The relevant facts are often found in system prompts, policy logic, approval workflows, tool catalogs, credential assignments, logs, and change records, because those artifacts show whether the deployer bounded the agent’s authority or let it operate with excessive freedom.
That evidence matters because it connects a model’s output to an actionable path. If the deployer configured the agent to take side effects automatically, the debate is less about “what did the model say” and more about “who authorized that action path.” For a practical treatment of how to scope agent authority, see AI Agent Authorisation Guide, which focuses on task-scoped access, per-action policy decisions, and approval gates.
When the dispute involves whether the agent should have been able to reach a system at all, identity and privilege decisions become central. The most useful question is not whether the model was “smart enough,” but whether the deployer gave it standing access that was broader than the task required. Zero Trust for AI Agents is relevant here because it treats verification, least privilege, and per-action enforcement as the core design constraints.
If the issue is how actions are attributed after the fact, logging and incident response become part of the liability record. A deployer that cannot reconstruct which tool was called, which credential was used, or which approval was bypassed will struggle to defend its operating model. For that reason, AI Agent Observability, Audit and Incident Response Guide is useful for understanding the evidence trail that tends to matter once a dispute turns adversarial.
How vendor defects and deployer decisions split the blame
Vendor liability usually becomes more important when the product itself is defective in a way that ordinary deployment choices would not reasonably anticipate. That can include unsafe defaults, misleading controls, broken isolation, or a defect that causes the system to behave outside the documented design. But even then, the deployer still has to show it used the product within a defensible operating model.
The split is therefore contextual. If the deployer gave an agent broad tool access, connected it to sensitive systems, and allowed automatic execution, a vendor defense that “the model output was only advisory” will not carry much weight. If the vendor shipped a defect that undermined the promised control boundary, the deployer may still face scrutiny, but the defect can shift part of the causal chain back to the supplier.
That is also why procurement and architecture decisions matter before an incident, not after one. A deployer that cannot distinguish between model capability, integration choice, and delegated authority will have trouble assigning responsibility when something goes wrong. The strongest governance story is the one that can show what the agent was allowed to do, why it was allowed to do it, and who approved that design.
Risk and Threat Considerations
AI agents create risk when a deployer grants them enough authority to convert a model error into a real-world action. The exposure is not just hallucination, but side effects, overbroad credentials, and automated approval paths that let a bad decision become a financial, operational, or security event.
Failure mechanism: The deployer assigns tools, tokens, and permissions that exceed the task, then the agent uses that authority to reach systems, approve requests, or trigger actions that should have required human review.
Impact: The organisation inherits the consequences of an unsafe operating context, including unauthorized changes, data exposure, service disruption, and a weaker defence if it cannot show that authority was bounded and monitored.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent liability turns on who granted authority and tool access. |
| Recommendation — Enforce per-action authorization and minimize agent privileges before deployment. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Deployers grant and govern non-human access used by external agent services. |
| AC-6 — Least Privilege | Liability shifts where deployer-granted access exceeds the task boundary. | |
| AU-2 — Event Logging | Disputes depend on logs showing what the agent was allowed to do. | |
| Recommendation — Require strong authentication for agent-to-system access and constrain credential use. Limit each agent to the minimum access needed for the approved workflow. Log agent approvals, tool calls, and privileged actions with enough detail to attribute decisions. | ||
Practitioner Guidance
What to verify: Confirm whether the agent could act only within a narrowly scoped workflow, or whether it had reusable access to systems beyond the task. The key test is whether a single bad output could still be contained.
Decision rule: If the agent can reach production systems, sensitive data, or approval functions, treat deployer governance as the primary control issue and review the access path before debating model quality.
What practitioners underestimate: Liability arguments rarely fail on the model text alone, they fail on the surrounding operational choices. The more autonomy the deployer permits, the more the deployer must be able to defend the policy, approval, and credential design.
Practitioner takeaway: The safest liability posture is to make every high-impact agent action attributable, bounded, and explicitly authorised, so responsibility follows documented control rather than post-incident interpretation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org