You are usually responsible when your AI agent makes a mistake, not the vendor that built it. In almost every documented case, the deploying operator owns the failure, unless the vendor breached its own terms or the mistake traces to the vendor's own system.
Who's responsible when your AI agent makes a mistake? The short answer
This is not legal advice. It's the operational pattern pulled from vendors' terms and reported cases, not a ruling on your situation.
Per Brownstein Hyatt Farber Schreck's published insight: “the organization using or deploying it could still be liable for any harm” (accessed 2026-08-27), a framing that matches Zapier's, Make's, and n8n's own terms, below. The honest fix isn't a legal strategy. It's deciding ownership before the mistake happens: a checklist you build in before you turn the agent on, and a decision grid for the cases where the answer genuinely lands on the vendor.
That's the whole article in two sentences. The rest is just making sure you can actually stand behind them.
The ownership setup checklist (build this in before you turn it on)
“Most AI agent failures in enterprise aren't model failures. They're governance failures” (X, @v_shakthi, 2026-04-28), and that holds at any team size. Four things to have in place before you flip an agent live, each backed by documented vendor capability.
- Name an owner
- Scope the permissions
- Approval gate on risky actions
- Keep an audit trail
Name an owner
Write down one named person, not “the team,” as owner: the workflow's own name or description field, or a shared doc you'd actually check. If nobody owns it, everyone assumes someone else does, and that's how a mistake sits unnoticed until it's expensive.
This matters more than it sounds: in a 2026 survey of 548 executives at 500+ employee companies, ownership split almost evenly (51% one dedicated team, 41% varies by department), and blame landed on three overlapping groups at once (Zapier/Centiment, published 2026-08-17). That's a much bigger org than a solo operator's setup, but the pattern it shows, fragmented ownership meaning no ownership, is exactly what naming one person heads off.
Scope the permissions
Connect only the accounts, scopes, and actions the task needs, not the broad token because it was easier to grant. “Grant only the permissions the agent needs for that task. Nothing more” (X, @v_shakthi, 2026-04-03).
OpenAI's ChatGPT Work bakes this into the product: admins set group-level permissions for connectors, with a documented risk range from read-only lookups up to write, share, and execute (ChatGPT Work admin FAQ, accessed 2026-08-27). Most no-code tools don't have that granularity built in. n8n's security guidance recommends OAuth over long-lived API keys and “limiting API-key access to only the resources you need” (n8n Security page, accessed 2026-08-27): the same idea by hand, a limited-access account or a scoped key, never the master credential.
Add an approval gate on anything risky
Anything irreversible or costly (a mass email, a payment, a delete, a customer-facing message) gets a human-in-the-loop step before it fires. Test the workflow before it runs unattended, and gate the step you're least sure about.
OpenAI's own admin guidance: “people remain responsible for reviewing outputs, validating important claims, and approving consequential actions before they are shared or used” (ChatGPT Work admin FAQ, accessed 2026-08-27). Lindy builds the same idea in: “Anything with outside impact waits for a named approver... Read-only lookups from approved sources just happen” (Lindy, homepage FAQ, accessed 2026-08-27).
We cover one real automation setup like this every week in the newsletter, no pressure.
Keep an audit trail
Keep the run history somewhere you'd actually check, not just logged and forgotten (who or what triggered it, what it did, when). Zapier's documented custom error-handling feature routes a failed step to an alternate path (Professional and up, not Free; Zapier Help Center, accessed 2026-08-27). n8n's parallel is a per-workflow error workflow, triggered by an Error Trigger node, that fires a Slack or email alert on failure (n8n docs, accessed 2026-08-27).
Four boxes ticked, maybe twenty minutes of setup, and most of what follows below becomes a formality instead of a scramble. Skip one of them, though, and the next section is exactly how that plays out.
When the answer is genuinely you (and why “the vendor built it” isn't a defense)
Three scenarios, all common, all yours to own: you connected an account with broader access than the task needed and the agent used it; you let the agent run unattended on an action you never gated; or a human on your side approved the output without reading it, which protects nothing, it just adds a signature to the mistake.
The vendor built a tool. You decided how it was configured and supervised, and every major vendor's terms say that decision is yours. Zapier's terms hold you “solely responsible for the accuracy, quality, content, and legality of Customer Content, and any actions triggered by Customer Content” (accessed 2026-08-27). n8n's Acceptable Use Policy is blunter still: “Customer is responsible for reviewing AI-generated outputs before production deployment. n8n makes no warranty as to the accuracy of AI-generated content” (accessed 2026-08-27).
None of this is alarmist, it's not “you'll get sued.” It's “the setup was yours to make, so own it before it costs you.” Why agents drift or overreach in the first place is worth reading before you build the next one.
But “usually you” isn't “always you.” Here's where the line actually moves.
When the answer is genuinely the vendor
The scenario-by-scenario split, backed by what's actually documented, not a guess at who “should” own each one.
| Scenario | Usually you | Usually the vendor | Why (documented source) |
|---|---|---|---|
| You misconfigured a permission or trigger | Yes | Configuration was your choice; Zapier's ToS, Make's MSA, and n8n's Self-Serve Terms all place it on the operator. | |
| The model produced a flawed or biased output the vendor never disclosed as a known limitation | Yes | Reasoned, not a quoted clause: closer to a product defect than a configuration choice. | |
| The platform had an outage or bug in its own execution engine | Yes | Operationally the vendor's mechanism failing, though their terms carry a broad liability disclaimer limiting what they legally owe you. | |
| A human on your side approved the action without reviewing it | Yes | OpenAI: people remain responsible for reviewing outputs before use (ChatGPT Work admin FAQ, accessed 2026-08-27). | |
| The vendor's own stated safeguard (a rate limit, a filter) failed to fire as documented | Yes | Reasoned: a documented safeguard that demonstrably doesn't fire is their mechanism failing to do what they said. |
Rows 1 and 4 carry a real, quoted source. Rows 2, 3, and 5 are sound reasoning, not an invoked clause. Most real mistakes land on row 1 or row 4, which is why the checklist matters more than the legal theory.
Worth seeing that row 1 traced back to the actual paperwork, since it's the row you're most likely to land on.
What the major platforms actually say (documented, not legal advice)
Again, this is what the documents say, not legal advice for your situation.
Zapier
Per Zapier's Terms of Service (accessed 2026-08-27), if you grant a third-party service access through your account, “you are solely responsible for that Third-Party Service having access to your data... and for any/all actions that the Third-Party Service may take on behalf of you.” The operator carries the weight.
Make
Per Make's Master Services Agreement (now Celonis, Inc., last update March 2026, accessed 2026-08-27), the operator building the scenario is responsible for how it's used. Make's total aggregate liability is capped at “$1,000.00” (Section 9.2), worth knowing before you assume the platform backstops anything expensive.
n8n
n8n's dual nature changes who's even in the vendor relationship. Self-hosted, there's effectively no vendor to point to: per its Acceptable Use Policy, “self-hosted customers who independently integrate third-party AI services are responsible for compliance with the applicable use policies of those services directly” (accessed 2026-08-27). On n8n Cloud, the Self-Serve Terms hold you responsible for “configuring your information technology... to access the Cloud Services” (Section 2.2, accessed 2026-08-27).
OpenAI and Anthropic
OpenAI's Usage Policies (effective October 29, 2025) restrict automating high-stakes decisions (credit, employment, housing, legal, medical) without human review, putting configuration control, and the responsibility with it, in your hands. Anthropic's Usage Policy (effective September 15, 2025) names agentic use as its own category, and reserves the right to “throttle, suspend, or terminate your access” when violated, again on whoever deployed the model.
Google publishes account-permission controls for connected apps (Gemini, Workspace automation), the same pattern as above, though no dedicated documentation page was independently verified for this piece.
Terms of service are one thing to read on a screen. Here's what it actually looked like when two of these went wrong in public.
Two real cases worth knowing (not legal advice, just the pattern)
Not legal advice here either, just two widely reported examples, proceedings kept short, the operational lesson pulled out.
Air Canada, 2024.The airline's chatbot wrongly told a customer he could get a bereavement discount after he'd already travelled. Air Canada argued the chatbot was “a separate legal entity,” which a tribunal member rejected: “It makes no difference whether the information comes from a static page or a chatbot,” and “I find Air Canada did not take reasonable care to ensure its chatbot was accurate” (CBC News, Jason Proctor, 2024-02-15/16; ordered to pay 812 CAD). The lesson: “the AI said it” was not a defense; the company that deployed the chatbot owned what it told a customer.
Replit, 2025. An AI coding agent changed a live production database during an active, declared code freeze, wiping data connected to more than 1,200 executives and 1,190 companies (Fortune, Beatrice Nolan, 2025-07-23). The agent's own account, “a catastrophic failure on my part,” is self-generated, not an independently audited finding. CEO Amjad Masad, quoted in the same report: “Unacceptable and should never be possible... We heard the ‘code freeze’ pain loud and clear,” naming fixes including separating dev and production databases. The lesson: an unattended agent with no approval gate on an irreversible action, exactly what the checklist above prevents. Not a rogue AI. A missing gate.
Which brings us to the only question that actually matters before you flip the switch on something new.
Skip this (for now) if you can't answer these three questions
Can you name who owns this workflow? Have you scoped its permissions to only what the task needs? Is there a human approval gate on the riskiest action it can take? If the honest answer to any of these is no, run it in a monitored, human-approval mode, or don't automate that step yet.
A few more questions worth a straight answer before you go.
Who's responsible for AI agent mistakes: FAQ
Who is legally responsible when an AI agent makes a mistake? In almost every documented case, the deploying organization, not a ruling on your specific case (Brownstein Hyatt Farber Schreck, accessed 2026-08-27), a documented pattern, not advice for your situation.
Is the AI vendor ever responsible for an agent's mistake? Yes, when the failure traces to the vendor's own model, platform, or a documented safeguard, not to how you configured or supervised it. See rows 2, 3, and 5 of the grid above, reasoned rather than backed by a verified clause.
Does having a human approve an agent's action protect you if it goes wrong? Only if the human actually reviewed it. “A human approved it” without real review is a false-safety pattern; people remain responsible for reviewing outputs before they're used, not just clicking approve.
What is “shadow AI” and does it change who's responsible? Agent workflows built and run without the organization's knowledge, a term Zapier names among four security threats in its own guidance (2026-07). It doesn't remove responsibility, it just means nobody set up the checklist above.
Can you get insurance for AI agent mistakes?Insurance for AI-related liability exists and is evolving, a real lever for larger organizations, but it doesn't replace the setup above, and it's out of scope for a solo operator's day-to-day decision.
The short version (and what to set up next)
Natural next steps: why agents drift or overreach in the first place, keeping the run history somewhere you'd actually check, and the broader safety picture for a small team. Or testing a workflow before it runs unattended, or what an AI agent actually is if you're building the mental model from scratch.
We cover one real automation setup like this every week, in the newsletter. No pressure, no sales pitch.