Compliance & Privacy · 2026-04-22
The Liability Gap in Agentic Commerce: Responsibility When an Agent Commits Fraud
By J. W. Bouckaert
Suppose an AI purchasing agent with a corporate card on file buys inventory from a seller that turns out to be fraudulent. The agent acted within the permissions it was given, the card payment cleared, and the loss is found weeks later. The question is who pays.
No jurisdiction treats an AI agent as a legal person, so liability lands on a human or corporate party. Which party depends on the legal regime, the facts, and above all the evidence available afterwards: who granted the agent what authority, and whether anyone checked that authority before the transaction went through.
This article sets out the main legal frameworks that apply, explains why the evidence question sits at the identity layer, and describes what PasskeyBridge's agent delegation and audit features record today. It is not legal advice.
Changes that agent transactions bring
Software has executed transactions without per-transaction human approval for years, in trading systems, ad bidding and supply-chain replenishment. Agents built on large language models add two things:
- Open-ended behavior. An LLM agent plans and improvises. The set of actions it might take is not fixed in advance.
- Cross-party settlement. Agents transact with counterparties whose own systems run under different owners and policies, with no shared trust authority.
Machine-speed decisions also rule out human review of each transaction. Either authority is checked automatically at the moment of the action or it is not checked.
The legal frameworks
| Framework | Source | Who it points to | What it needs as evidence |
|---|---|---|---|
| Agency law (U.S. common law) | Restatement (Third) of Agency §§ 1.01, 7.07 | The principal who authorized the act | Actual or apparent authority for the act |
| EU AI Act, providers | Regulation (EU) 2024/1689, Art. 16 | Providers of high-risk AI systems | Risk management, technical documentation, logging capability |
| EU AI Act, deployers | Regulation (EU) 2024/1689, Art. 26 | Deployers of high-risk AI systems | Use as instructed, monitoring, logs kept at least six months |
| EU Product Liability Directive | Directive (EU) 2024/2853 | The manufacturer of a defective product, including software | Defect, damage and causation, with presumptions in some cases |
| NIST AI RMF 1.0 (voluntary) | NIST AI 100-1 | Roles the organization assigns itself | Documented Govern, Map, Measure and Manage practices |
These can apply together. A U.S. company with EU counterparties may face EU rules, U.S. agency principles in a contract dispute, and its own NIST-based governance commitments, all on the same facts. Each asks some version of the same question: who authorized what, and can it be shown.
Agency law
Restatement (Third) of Agency § 1.01 defines agency as the fiduciary relationship that arises when a principal manifests assent to an agent that the agent shall act on the principal's behalf and subject to the principal's control, and the agent manifests assent or otherwise consents. Two parts of that definition fit software poorly.
The first is that the agent is a person who can consent and owe fiduciary duties. Software cannot. The practical result is that the software is treated as the principal's instrument, and the person or company deploying it carries the consequences of what it does.
The second is control. Agency law assumes the principal can instruct, supervise and recall the agent. With an agent acting faster than any human can review, control comes down to the limits set before the agent acts and the record of whether those limits were checked. A dated, verifiable record of the authority granted is the most direct evidence on both points.
The EU AI Act
The AI Act separates providers from deployers. Article 3 defines a provider as the party that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer is a party using an AI system under its authority, except for personal non-professional use.
The obligations most relevant to fraud apply to high-risk AI systems, the categories listed in the Act and its Annex III. Article 16 sets provider obligations for high-risk systems. Article 26(6) requires deployers of high-risk systems to keep the logs the system generates automatically, to the extent those logs are under their control, for a period appropriate to the system's purpose and at least six months, unless other EU or national law, in particular data protection law, provides otherwise. Many purchasing agents will not fall into a high-risk category, in which case these specific duties do not apply, but the logging model is still a useful benchmark for what a deployer should be able to produce.
The Product Liability Directive
Directive (EU) 2024/2853 replaces the 1985 directive. It entered into force on 8 December 2024, Member States must transpose it by 9 December 2026, and it applies to products placed on the market after that date. Three points matter here:
- Software is a product. The directive expressly includes software, including AI systems, in the definition of product.
- Data loss counts as damage. Recoverable damage includes destruction or corruption of data not used for professional purposes. Pure economic loss is outside its scope, which limits its reach for business fraud losses.
- Disclosure and presumptions. Courts can order a defendant to disclose relevant evidence, and a defendant that fails to do so can be presumed to have supplied a defective product.
NIST AI RMF
NIST AI RMF 1.0 is voluntary. It organizes AI risk management into four functions: Govern, Map, Measure and Manage. It assigns responsibility through roles the organization defines rather than through legal categories. On 7 April 2026 NIST published a concept note for an AI RMF profile on trustworthy AI in critical infrastructure, which indicates more sector-specific guidance is coming.
Electronic personhood
The European Parliament's 2017 resolution on Civil Law Rules on Robotics raised the idea of a specific legal status for advanced autonomous robots. The AI Act did not adopt it and neither did the new Product Liability Directive. Without legal personhood, liability stays with the parties who build, deploy and authorize the system.
The evidence question is an identity question
Across these frameworks the decisive facts are: which agent acted, which principal authorized it, what limits applied, and whether those limits were checked at the time. Without a record made at the time, those facts are rebuilt later from server logs and testimony. A record that ties each agent action to a specific, scoped grant of authority, written to a log that cannot be edited without detection, answers them directly.
PasskeyBridge records today
PasskeyBridge provides agent delegates and an audit trail. What they do, as implemented:
- Delegates are created by tenant admins. Each delegate gets a token with the
pb_agent_prefix. PasskeyBridge stores only a SHA-256 hash of the token, never the token itself. - Scopes and expiry. A delegate can carry up to 20 scopes and an optional expiry of up to one year.
- Verification on each action. A relying party calls the verify endpoint with the token and the scope it is about to exercise. The call fails if the delegate is unknown, revoked or expired, or does not hold that scope.
- Every check is recorded. Successful verifications and refusals (expired token, scope violation) are both written to the delegate's activity record.
- Hash-chained audit log. Audit entries form a hash chain. Every five minutes a checkpoint over the chain heads is signed with a hybrid HMAC-SHA-256 and ML-DSA-65 signature, so later edits to the log are detectable.
- Agent-to-agent negotiation. PasskeyBridge's A2A trust negotiation signs each step with the same hybrid signature, and a hard identity threat signal revokes active negotiations.
What it does not do: delegates are not signed by the principal's passkey, are not bound to hardware attestation of the agent's key, and carry no spending limits or vendor allowlists. Those controls, if a deployment needs them, belong in the payment or procurement system that the agent calls.
A defensible setup
Using the controls above, a deployer can put itself in a position to answer the evidence question:
- Give each agent its own delegate with only the scopes it needs and a short expiry.
- Have every relying system verify the delegate and scope before acting, and refuse the action if verification fails.
- Keep the audit log and its signed checkpoints for at least as long as any applicable retention rule, such as the six months in AI Act Article 26(6) where it applies.
- Revoke delegates as soon as an agent is retired or misbehaves.
Summary
No framework treats an AI agent as a liable party. Agency law, the EU AI Act and the EU Product Liability Directive each point liability at a human or corporate party, and each turns on evidence of who authorized what. Scoped, verified delegation and a tamper-evident audit log are how that evidence gets produced at the time of the action instead of reconstructed afterwards.
Read the PasskeyBridge solutions overview for the agent delegation features, or the A2A trust negotiation article for agent-to-agent checks.