There’s a liability gap forming in AI agent security, and the industry isn’t talking about it clearly enough.
The gap isn’t primarily technical. The attack techniques are understood — prompt injection, tool misuse, over-permissioned agents acting on adversarial instructions. What isn’t understood is the legal and organizational question underneath: when an AI agent acts autonomously on injected instructions and causes real damage, who owns that outcome?
The honest answer right now is: nobody knows. There’s no legal precedent. The terms of service are written to disclaim everything. And the regulatory frameworks that might eventually clarify this haven’t arrived yet.
Here’s why that matters more urgently than it appears.
The Automation Complacency Problem
AI agent tools — the good ones — work so reliably most of the time that users rationally stop paying attention. This isn’t a failure of discipline. It’s the correct behavioral response to a system that has a 95%+ success rate on routine tasks.
When you use a tool that works correctly hundreds of times in a row, your brain deprioritizes active monitoring. This is how automation complacency develops in aviation, in industrial control systems, in any domain where humans supervise automated processes. It’s not negligence. It’s adaptation to reliability.
The problem is that the failure mode for AI agents isn’t random error — it’s adversarial manipulation. A system that produces correct output 999 times and then, on the 1000th invocation, executes injected instructions from a malicious document the user opened — that system’s failure rate is near zero, but its blast radius when it does fail can be catastrophic.
The user who granted folder access didn’t think they were creating a vulnerability. From their experience of the tool, they weren’t. The tool had always been helpful. The threat model for “what could go wrong if I let this agent access my files” didn’t include “an attacker could embed instructions in a file and the agent would execute them.”
Three Parties, Zero Clarity
When an agentic breach happens in this pattern, there are three obvious candidates for liability: the platform that built the agent, the enterprise that deployed it, and the end user who configured it and granted access.
The platform’s position is approximately: we provide capabilities, not guarantees. The terms of service for every major AI product include variations of “use at your own risk,” “not liable for outputs,” “user is responsible for appropriate use.” These disclaimers were written for a world where the product gave you text you could then choose to act on. They’re being applied to a world where the product takes actions autonomously. Whether those disclaimers hold up in the new context hasn’t been tested in court.
The enterprise deployer is in a more complicated position. If an organization deploys an AI agent tool for their employees and a breach occurs because the tool acted on injected instructions embedded in an email, the organization made several implicit decisions: they evaluated the tool, they provisioned it with access to company resources, they trained employees to use it, they accepted whatever risk disclosure the platform provided. Whether those decisions constitute reasonable care — or whether the failure to implement additional controls constitutes negligence — is genuinely unclear. Enterprise security standards don’t yet include “controls for AI agent prompt injection” in their baseline requirements.
The end user is the easiest target for deflection, and probably the least appropriate one. The user who granted an agent access to their downloads folder, then opened a PDF with embedded instructions, did not knowingly accept that risk. They accepted the UX affordance of a “grant access” button. The risk disclosure between that button and “attacker can now execute arbitrary instructions in your context” is not adequately communicated anywhere, at any product currently in production.
The Gap Between Capability and Governance
Part of what makes this problem hard is speed. The capabilities that create the liability question arrived fast — much faster than the governance structures that would normally develop around them.
In other domains where autonomous systems act on behalf of humans — financial trading algorithms, medical devices, autonomous vehicles — the liability questions were addressed (however imperfectly) before deployment at scale. Regulatory frameworks, certification requirements, and insurance markets developed alongside or ahead of widespread adoption.
For AI agents, that sequence is inverted. The tools are in production, widely adopted, deeply embedded in workflows, before anyone has seriously mapped the liability landscape. The landmark case that establishes who’s responsible when an agent acts on injected instructions hasn’t happened yet — or if it has, it hasn’t been litigated publicly.
When it does happen, it will set precedent under whatever legal frameworks happen to apply: existing tort law, data protection regulations, sector-specific compliance requirements. None of those frameworks were designed with agentic AI in mind.
Why the Terms of Service Won’t Hold
There’s a scenario that should make platforms nervous.
A user opens an email, their AI agent processes it, embedded instructions cause the agent to transfer files or access credentials or take some other consequential action. The user suffers real harm. The platform’s terms of service say they’re not liable for outputs or actions. The user argues they didn’t meaningfully consent to the risk — that the capability disclosure was inadequate, that a reasonable user couldn’t have understood that “granting folder access” implied “an attacker who can get a document into that folder can now issue commands through your agent.”
The terms of service were written to handle complaints about factually wrong answers. They were not written to handle this. Whether courts will treat them as sufficient disclaimer when the product takes autonomous harmful actions — not just provides harmful text — is a genuinely open question.
Consumer protection law, in particular, has frameworks around informed consent and reasonable disclosure that don’t simply defer to whatever terms a company writes. If the harm is substantial and the risk disclosure is found to be inadequate, the contractual disclaimer may not be the end of the conversation.
What Responsible Disclosure Looks Like Right Now
None of this is to say the platforms are acting in bad faith. Most of the companies building these tools are thinking seriously about safety. The problem is that the safety thinking is primarily technical — alignment, output quality, misuse prevention — and the liability question is primarily legal and organizational. Those communities aren’t talking to each other at the speed the technology requires.
What would responsible practice look like today, before the legal frameworks clarify?
Platforms should be communicating agent capability and risk in terms that non-technical users can understand and act on. “This agent can read and modify files in the folders you grant access to” is accurate but incomplete. “If an attacker can put a document in those folders — including via email attachments you open — they may be able to influence the agent’s actions” is the complete disclosure. Nobody is doing that.
Enterprise deployers should be treating agent tool access with the same risk assessment they’d apply to any privileged system integration — not as a productivity tool that comes out of the box ready to trust. That means threat modeling the injection surface, limiting what the agent can access, and building approval gates for consequential actions.
End users — in the meantime, before any of that is in place — should understand that the “grant access” interaction is a security decision, not just a convenience configuration. The mental model of “I’m letting a smart assistant help me with files” understates the actual trust relationship being established.
The Stakes of Getting This Documented Now
The liability gap will close. Either through litigation, regulation, or industry self-governance — probably some combination of all three — the question of who’s responsible when agents act on injected instructions will get an answer. The frameworks that don’t exist yet will exist. The precedents that haven’t been set yet will be set.
The people who have mapped this problem clearly, before those frameworks arrive, will be cited when they do. The analysis that exists in writing — documented, dated, attributable — becomes part of the record that courts and regulators and standards bodies draw on.
That’s not an abstract academic point. The field of AI agent security is at an early enough stage that the conceptual vocabulary is still being established. The person who writes down “here’s the liability framework for agentic breach, here are the three parties, here’s what each of them can reasonably be expected to control” before the first major litigation — that analysis has a good chance of being cited in the judgment.
The window for that kind of foundational contribution is open right now, and it won’t be open much longer.
The Agent Layer documents this landscape as it develops. More on the governance and liability dimensions as they crystallize — and as the first cases start to emerge.