When an agent's action causes harm, who's actually on the hook? 2026's answer is forming
As agents take more autonomous actions in production, 2026 is producing real legal answers on accountability. Log every action and treat it as compliance.
By Gabriel Lara, Developer Relations, Norbelys
Founder-reviewed ·How we research and correct articles
Gartner’s projection that 40% of enterprise apps will embed task-specific agents by the end of 2026 has mostly been discussed as an adoption story. The question that matters more, and that 2026 has actually started producing real answers to, is what happens when one of those agents does something wrong — approves a refund it shouldn’t have, sends an email it shouldn’t have sent, deletes a record it shouldn’t have touched — and who is on the hook for it.
That’s not a hypothetical anymore. It’s showing up in statutes, executive orders, and at least one real court case in 2026, and the direction all of them point is more consistent than the “who knows, it’s new territory” framing that dominated the discussion a year ago.
Where the accountability actually lands, according to 2026’s legal record
Baker McKenzie’s June 2026 analysis of the US legal landscape summarizes a pattern worth knowing even outside a legal team: the emerging position across statutes, executive action, and case law is that accountability runs to the humans and organizations that built or deployed the agent — not to the agent as some independent actor. A California statute now specifically forecloses a defendant from arguing that “the AI autonomously caused the harm” as a defense in an action alleging AI-caused harm. A June 2026 presidential executive order directs the Department of Justice to prioritize enforcement against AI-enabled unlawful access to data. And in an early, concrete test case, a major online marketplace sued the developer of an AI browser agent, alleging the agent accessed password-protected areas of the marketplace’s site and disguised automated activity as ordinary human browsing — a court preliminarily enjoined the agent, finding the marketplace likely to succeed on federal computer-fraud claims.
Put together, the message is blunt: “the agent decided to do it” is not shaping up to be a viable defense anywhere it’s been tested. Deploying the agent is the decision that carries the liability, the same way deploying any other automated system has always carried liability for what it does.
Regulators are formalizing the same answer, not just courts
Singapore’s IMDA published a Model AI Governance Framework for Agentic AI in January 2026 — described as the first comprehensive governance framework specifically for autonomous agents — and it doesn’t stop at the general principle. It gets specific: organizations deploying agentic AI are expected to maintain a verifiable digital identity for each agent and an audit trail of which agent acted under whose authorization, structured around bounding the risk, ensuring meaningful human accountability, implementing technical controls, and enabling end-user responsibility. That framework isn’t binding outside Singapore, but it’s a concrete preview of where guidance elsewhere is likely headed — “we’ll figure out accountability if something goes wrong” is being replaced, in at least one jurisdiction, by “show us the audit trail before anything goes wrong.”
The practical takeaway if you’re the one deploying an agent
If accountability runs to you as the deployer, the only real defense available — legally and operationally — is being able to show what the agent actually did and why, after the fact. That’s not a new idea; it’s the same logic as any other audit requirement. What’s new is the scale: a system making autonomous decisions at agent speed generates far more “why did it do that” moments than a human-operated process ever did, and a log built for occasional human review usually isn’t built to answer that question at that volume.
Concretely, that means treating audit logging as a compliance requirement now, not a nice-to-have you’ll add once regulation forces the issue:
- Log the input, not just the action. “Agent sent email to contact_id=4521” is a record of what happened. It doesn’t tell you why — what prompt, what data, what tool response led the agent to that decision. Capture enough of that chain to reconstruct the reasoning, not just the outcome.
- Tie every action to a specific credential and, where possible, a specific human who authorized that credential’s existence. Singapore’s “which agent acted under whose authorization” framing is the right question to be able to answer for any consequential action your systems take. A platform like Norbelys makes this concrete rather than aspirational: every API call, whether it comes from your own script or an agent working through Norbelys’s MCP server, runs under a specific, revocable API key — so “which credential sent this” is never a reconstruction exercise after the fact.
- Keep the log somewhere that survives the incident it would explain. A log that lives only in the agent’s own runtime, or that rotates out in days, doesn’t help you six weeks after an incident when a customer, a regulator, or your own leadership asks what happened.
- Treat this as a launch requirement for any new agent-embedded feature, not a retrofit. Given how fast the legal and regulatory record above is forming, building the audit trail in from day one is cheaper than reconstructing one under pressure once something’s already gone wrong.
Agent accountability FAQ
Is there a global standard yet for who's liable when an AI agent causes harm?
No single global standard exists as of mid-2026, but the direction across US case law, US statutes and executive action, and Singapore's IMDA framework is consistent: accountability runs to the organization that deployed and configured the agent, not to the agent or the underlying model as an independent actor.
Can "the AI decided on its own" work as a legal defense?
The trend so far says no. A California statute specifically forecloses that argument in actions alleging AI-caused harm, and Baker McKenzie's 2026 analysis describes the broader US legal pattern moving the same direction.
What's the single most useful thing to build before shipping an agent-embedded feature?
An audit trail with enough context to reconstruct why the agent took a given action, not just that it took one — tied to the specific credential and, where possible, the human who authorized it. Every governance framework referenced in this post names that as a core control.
None of this is specific to any one platform — it’s the same discipline regardless of what an agent is calling. If you’re building or operating an agent that touches Norbelys on a customer’s behalf, the credential-scoping and server-to-server auth mechanics that make an attributable audit trail possible in the first place are covered in scoping the API key you hand an agent — worth pairing with whatever logging your own agent framework produces, since the platform can tell you which credential acted, but only your own system can tell you why it decided to.