Agent identity and delegated access: how AI agents act for people
08
Deep dive: who pays when an agent acts
5 min read · Chapter 8 of 10
Who pays when an agent acts: what's real
My view as of October 2026: when an agent does something its person didn't want, the loss stays with that person or their company, because every layer that could move it (payment rules, vendor terms, courts, insurance) either hasn't addressed agents or caps what can move. The weakest evidence is on cost: no company published a dollar loss for any incident I found, and settlements may be confidential.
The liability gap: "authorized by instruction"
Payment protections cover payments nobody authorized. US Reg E defines an unauthorized transfer as one started by someone "without actual authority", and its official interpretation says a consumer who gives someone an access device stays liable for what that person does with it, even beyond the authority given, until the consumer tells the bank the authority has ended. Reg Z's $50 cap on card liability uses the same test. An agent the user told to buy something probably has that authority, so on my reading a wrong purchase is likely "authorized" and the protections for unauthorized use may not apply. No regulator or court has said so, and I found no CFPB statement on agents. EU and UK rules have the same shape, and a UK payments lawyer argues the 2017 regulations' consent rule fits agents badly.
The card networks haven't filled the gap. Neither Visa nor Mastercard has published a dispute rule for agent-initiated purchases. Worldpay, which processes card payments, says liability is "still being negotiated": the issuer carries fraud risk where the agent authenticated and the token was issued correctly, and a non-fraud dispute (wrong item, misread instruction) has no owner yet. American Express announced in April 2026 that it would cover eligible card members for agent errors when the agent is registered and the purchase intent authenticated, with the registry still "coming soon".
Two rules soften this at the edges. Under UETA, the US model law on electronic transactions, a consumer can undo a transaction made with an automated agent if they had no chance to correct the error, and the Future of Privacy Forum argues terms can't take that away. California's 2025 law bars a developer or user of AI from arguing that the AI acted autonomously.
What the vendors' terms say
The agent makers' terms put the agent's actions on the user and cap the rest:
| Terms | Who answers for the agent's actions | Cap |
|---|---|---|
| Anthropic consumer terms (October 2025) | The user is "responsible for all Inputs" and all "Actions" | The greater of 6 months' fees or $100 |
| Anthropic commercial terms (June 2025) | The customer, for account activity and judging outputs | 12 months' fees |
| Google Gemini API additional terms | The customer is "solely responsible" for the service's actions and tasks | Not on that page |
| Microsoft Services Agreement | The user, for third-party claims | One month's fee, or $10 if free |
| Perplexity terms and Comet terms | Dealings with third parties are between the user and them | The greater of $100 or 6 months' fees |
| Replit terms (August 2026) | The user, including "managing access permissions" | No dollar cap stated; lost data excluded |
I couldn't read OpenAI's terms directly, so they're not in the table. Identity vendors follow the same pattern: Okta's and Clerk's terms, read for the login guide, cap liability at 12 months of fees with no separate cap for security incidents.
Amazon v. Perplexity: who may say no to an agent
Amazon sued Perplexity over its Comet browser agent, which signed in to shoppers' Amazon accounts at their request while presenting Chrome's user agent, after a cease-and-desist on October 31, 2025. On March 9, 2026, the federal court in Northern California granted a preliminary injunction, finding Comet reached password-protected accounts "with the user's consent, but without Amazon's authorization". On August 4, 2026, the Ninth Circuit vacated it, reasoning that "it is the user who 'accesses' Amazon's computers", and said its ruling was limited to the record and set no broader principle. As of October 2026 the case is back in the district court.
The open question is who authorizes an agent at a site: the user who sent it, or the site it visits. Until a court settles it, a site that wants to refuse agents should say so in its terms and enforce it technically, and an agent maker should expect objections to an agent that hides what it is.
Salesforce's lawsuits over Drift
Drift's tokens were stolen from Drift's own environment, yet Salesforce, whose customers' data was exported, faced at least 15 lawsuits in federal court in Northern California within about five weeks, some also naming Salesforce customers whose data was taken. Salesforce says its platform wasn't compromised, and I found no ruling. Ten months later the same pattern hit Klue's customers, and Salesforce disabled the Klue integration.
What I take from it: when a token holder is breached, plaintiffs go after the platform with the most money, whatever the root cause, so I'd expect platforms to push integrators toward short-lived, sender-constrained tokens and to delist faster.
Insurance is moving both ways
Silent cover is shrinking: Verisk's optional generative-AI exclusions took effect on January 1, 2026, and Berkley introduced an absolute AI exclusion for management liability policies in 2025. Specialist cover is growing: one Lloyd's-backed insurer says it offers up to $25 million per organization including agent mistakes, and a startup that certifies agents and sells insurance raised $40 million in September 2026. Check how your cyber policy treats an agent's actions under a valid token.
What to put in your own terms
If agents act on your platform, or your product is an agent, I'd write these down, with a lawyer:
- Whose actions they are: actions an agent takes with a customer's grant count as the customer's; say what your product does to keep grants narrow.
- Supported paths: name the ways in you support, and say that shared credentials and personal keys used by agents are at the customer's risk.
- Logs and revocation: commit to recording the person and the agent on each action, to handing customers that log after an incident, and to a time for revoking a single agent.
- Approvals: list the actions that always ask a human (payments, bank details, deletions, bulk exports), and keep a way for consumers to correct an agent's error, since UETA may give them that right anyway.
- Tokens you hold for others: if you store other companies' tokens, you're in Drift's position; say how they're protected and how your cap treats a breach of that store.
- Agents on your site: if you want to refuse or charge some agents, say so in the site terms and back it with technical controls.