Is a prompt injection incident a reportable data breach?

It depends on outcome, not on mechanism, and that is what catches teams out. Most breach definitions turn on unauthorized acquisition of or access to personal information. If an injected agent read a customer record it was permitted to read and then transmitted it to an attacker-controlled destination, the acquisition by the attacker is unauthorized even though every individual system access was authorized. The analysis lands in the same place as an insider-misuse case, so treat it as a potential notifiable event and document the reasoning rather than assuming that the absence of an intrusion ends the question.

Does our cyber insurance cover an AI agent that was manipulated?

Read the triggers before you need them. Network security and privacy liability coverage generally responds to unauthorized access or a failure of security, and an insurer may argue that an agent using its own valid credentials is neither. Social engineering and funds-transfer-fraud endorsements are often a closer fit for the transactional cases, but those endorsements typically carry low sublimits and some require that a human was deceived. Ask your broker in writing how the policy responds when the deceived party is software.

If our vendor's model was injected, is the vendor liable?

Usually not under the contract you signed. Model vendors disclaim output accuracy, cap liability at fees paid over some recent period, and place responsibility for deployment configuration on the customer. Since the exploitable surface is generally your system prompt, your retrieval sources and your tool grants, the allocation is not obviously wrong — but it means the loss stops with you by default. If you resell an agent to your own customers, you are the vendor in that chain and the same logic runs against you.

Can we disclaim liability for what our agent does to a customer?

Partially, and less than most terms of service assume. A disclaimer of accuracy for informational output is ordinary and generally effective. A disclaimer covering actions your agent takes inside a customer's account is a different thing: the customer granted authority to a system you operate, and clauses purporting to eliminate all responsibility for its consequential acts face consumer-protection and unconscionability pressure. The more durable position is a scoped authority — narrow permissions, confirmation gates on consequential actions, and a stated remediation path — rather than a broad exclusion.

What is the single most effective control?

Reduce the blast radius rather than trying to make the model unpersuadable. Prompt injection has no complete technical fix today, so the controls that survive scrutiny are structural: least-privilege tool grants scoped per session, a hard separation between content the model reads and instructions it obeys, a human confirmation gate on anything irreversible or financial, egress restrictions on where data can be sent, and logging detailed enough to reconstruct which retrieved content carried the instruction.

Who Pays When an AI Agent Is Talked Into It? Prompt Injection Liability in 2026

The Confused Deputy Now Has a Corporate Card

The security literature has a name for this shape: a confused deputy, a privileged component tricked into misusing its authority on someone else's behalf. What changed in 2026 is not the concept but the deputy. It reads email, browses pages, opens attachments, calls internal APIs, and in a growing number of deployments it can move money, change records or send messages on your behalf — all with credentials you deliberately issued it.

An indirect prompt injection exploits exactly that. Instructions are planted in content the agent will read — a support ticket, an invoice PDF, a calendar invite, a web page, a code comment — and the model, which has no reliable way to distinguish data it was given from instructions it was issued, follows them. Afterwards your logs show a well-behaved agent doing permitted things in the correct order. There is no intrusion to point at.

Why the Usual Instruments Miss

Each of the four documents you would rely on assumes an attacker who obtained access they should not have had. None of them describes what actually happened.

What the Documents Assume

•An attacker acquired credentials or exploited a flaw
•A control failed and can be identified
•Access was outside the granted permission set
•A human was deceived, or a system was penetrated
•The affected data left through an unapproved path

What Actually Happened

•The agent used its own valid credentials
•Every control worked exactly as configured
•Access was inside the granted permission set
•The deceived party was a model, not a person
•Data left through a path the agent was allowed to use

This is not an argument that you escape liability. It is the opposite. When no document allocates the loss, it stays where it landed — with whoever operated the agent — and it gets litigated under ordinary negligence and contract principles rather than under a clean, capped, insured framework.

Four Scenarios and Where the Loss Lands

The Agent Exfiltrates Another Tenant's Data

Injected content instructs the agent to summarize retrieved context into a reply that reaches the attacker. Outcome-wise this is indistinguishable from a data breach, and notification analysis should proceed on that basis. The defensible position is not "our systems were not compromised" — it is a record showing retrieval was scoped, egress was constrained, and the specific failure was identified and closed.

The Agent Executes a Transaction

A payment, a refund, a purchase order, a wire instruction change. Here the closest legal analogy is business email compromise, and the useful question is whether the agent had apparent authority to bind you. If you gave a customer-facing agent the power to issue credits and it issued one to an attacker, the loss is yours in almost every framing. Funds-transfer-fraud coverage may respond; check whether the endorsement requires a deceived employee.

The Agent Acts Inside a Customer's Account

You sold an agent that operates in your customer's environment, and injected content in their data caused it to delete, send or change something. Your terms cap liability and disclaim output accuracy; neither clause is squarely about actions. Expect the customer to argue that a capped fee refund is not a remedy for destroyed records, and expect a court to look at what authority you asked for and what gates you built.

The Agent Publishes Something Defamatory

Injection is a reliable way to make a model assert a damaging falsehood about a named party, and if your product then publishes it under your brand, the intermediary protections people reflexively invoke are a poor fit for content your own system generated. This is the scenario with the least contractual coverage and the most reputational tail.

The Terms Worth Adding Before the Incident

Allocation is cheap to negotiate in advance and impossible to negotiate afterwards. Six items, whether you are buying an agent or selling one.

Define agent actions separately from output. An accuracy disclaimer should not silently swallow the consequences of an action taken in a live system.
State the authority granted. Enumerate the tools and permission scopes the agent holds, and make expansion a change requiring consent, not a product update.
Name a confirmation boundary. Write down which classes of action require a human approval, and treat crossing that line without approval as a defined failure.
Extend the security-incident definition. Add manipulation of an AI system into unintended action, so notification duties do not hinge on whether anyone "accessed" anything.
Carve actions out of the fee cap. Or set a separate, higher sublimit for them. A cap at twelve months of fees is not a remedy for a deleted production dataset.
Require log retention and cooperation. Reconstructing which retrieved document carried the instruction is the whole investigation, and the logs are often on the other party's side.

Frequently Asked Questions

Can we just filter injected instructions out of the input?

Not reliably, and building your risk posture on the assumption that you can is the mistake. Instruction detection is a classification problem with an adversary on the other side, and the attacker rewrites until something passes. Filtering is worth deploying as one layer; it is not a control you can represent to a customer as preventing the failure.

Does keeping a human in the loop solve it?

It solves the transactional cases and helps far less than expected on the informational ones. A person approving a payment will catch an unfamiliar recipient. A person skimming forty agent-drafted replies an hour will not catch the one with an extra sentence in it. Place the gate where the consequence is irreversible and the review is genuinely possible, and be honest about which approvals are real.

We are the buyer. What should we ask a vendor?

Four questions: what tools and scopes does the agent hold in our tenancy, what actions are gated by human confirmation, what happens to your obligations if injected content causes an action, and can you show a red team record covering indirect injection specifically. A vendor who has never been asked the third question will tell you so by the quality of the answer.

Is any of this regulated yet, or is it all contract?

Both, unevenly. Sector regulators already expect controls over systems that take consequential action, and general AI governance frameworks treat manipulation resistance as an expected risk control rather than an optional one. But no widely applicable statute today says who pays for an injected agent's transaction. That silence is exactly why the contract terms are doing the work.

How do we explain this to an executive who hears 'we were not breached'?

Use the employee analogy. If a new hire with legitimate system access were talked into wiring money by a convincing email, nobody would say the company was fine because no server was compromised. The agent is that hire, it has more access, it never gets suspicious, and it will follow the same instruction ten thousand times.

Decide Now Who Pays

Prompt injection does not have a fix you can buy, so the question worth answering this quarter is not how to prevent it. It is what your contracts, your policy and your permission scopes say happens when it works.

Three of those four answers are currently "unspecified" at most companies shipping agents, and unspecified resolves against whoever operated the system.

This article is general information about liability allocation for AI agent incidents, not legal advice or an interpretation of any specific policy. Breach-notification analysis, insurance triggers and enforceability of limitation clauses vary by jurisdiction and wording — review your own contracts and policy with counsel and your broker.