The Legal Context Protocol: Agentic Commerce Finally Gets Its Legal Layer

When a person buys something online, a good deal of legal machinery operates quietly in the background. The shopper accepts the terms, the retailer records that acceptance, and if the order goes wrong there is a receipt, a returns policy, and an identifiable party to hold responsible. Hand that same purchase to an AI agent and the mechanism falls away. The agent locates the product, accepts the terms and completes payment with no person overseeing it. If the item never arrives, or the terms prove different from what the agent understood, it becomes unclear who agreed to what, under which jurisdiction, and through what channel a complaint would be resolved. For most of the past year, agentic commerce has had no clean answer.

On 24 June 2026, a coalition led by the American Arbitration Association, the century-old institution for commercial dispute resolution, and Integra Ledger launched the Legal Context Protocol (LCP) to provide one. LCP is an open standard that allows an AI agent to locate a merchant’s legal terms, record its acceptance of them, and establish in advance how a dispute would be resolved, all in a form another machine can read and later verify. In effect, it gives an agent-led transaction the evidentiary trail a human checkout produces, so there is a definite record of what was agreed and what follows if something goes wrong. The founding contributors carry weight. They include Google, IBM, Circle and Wayfair, alongside a range of blockchain and identity firms. Separately, the standard is designed to work with the major agentic-commerce protocols already in motion, among them Visa’s Trusted Agent Protocol and Mastercard’s Verifiable Intent.

The timing is deliberate. Gartner projects that by 2028, 90% of B2B buying will be intermediated by AI agents, pushing more than $15 trillion of spend through AI agent exchanges. The industry has advanced quickly on the components that let an agent pay, namely the payment rails and the identity checks. The legal layer, the record of what was agreed and the route to resolving a dispute, has not kept pace. On a single $30 order, a missing record is immaterial. Across trillions of dollars of automated transactions, it is the kind of gap that can hold the entire model back. LCP is an attempt to close it before that volume arrives.

Key takeaways

• LCP is an open standard that lets an AI agent discover a service’s legal terms, consent and dispute-resolution process in a machine-readable form.
• The normative core is tiny: one JSON file at a fixed location, with a single required field. No blockchain, no API and no cryptography required.
• Four optional trust levels let the assurance scale with the transaction, from a discoverable terms file to hash-verified, digitally signed, dispute-ready agreements.
• It is built to sit alongside payment and identity protocols, including Visa’s TAP, completing the stack: payment says what was paid, identity says who acted, LCP says under what terms.

What LCP actually is

Strip away the coalition and the framing and the standard is remarkably small. A service that wants to be legible to agents publishes a single JSON file at a well-known location: /.well-known/legal-context.json, served over HTTPS. The file has exactly one required field, a link to the terms:

{

  "terms": "https://example.com/terms/v3.md"

}

That is the entire mandatory requirement. The terms have to be a standalone, downloadable document rather than a section of a web page, so an agent can fetch and parse them in one request. The spec recommends machine-readable formats like Markdown, JSON or plain text over PDF and Word, since layout formats cannot be parsed reliably by a machine. There is no blockchain, no API, no cryptography and no third-party service required, and the whole thing is published under the permissive Apache 2.0 licence. A solo developer and a bank adopt it the same way: write a JSON file, put it on a server.

It is worth keeping the maturity in perspective. Adoption is voluntary, and governance is still set to pass to a neutral foundation, so this is a proposed standard gathering momentum, not an established one. But the design is deliberately easy to say yes to, which is usually how standards win.

Four levels of trust

The one required field is Level 1. From there the standard defines four levels of trust assurance, each one optional and each adding evidentiary weight for both sides of a transaction rather than favouring the seller.

• Level 1, Informational. The agent finds the terms, and proceeding counts as implicit consent. This is the browsewrap model of today, but with a standard location. It suits low-value, high-volume transactions like API calls or commodity purchases.
• Level 2, Provable. The file adds an atrHash, a SHA-256 hash of the terms document, known as the Agentic Transaction Record. It proves exactly which document was in force and that it has not been altered after the fact. This matters wherever a dispute about what the terms were is plausible, such as B2B procurement.
• Level 3, Signed. An acceptanceRequired flag plus a digital signature prove explicit intent, for regulated industries and high-value contracts where the law expects a signature.
• Level 4, Integrated. Fields for dispute resolution and an API hook the transaction into real legal infrastructure: escrow, compliance gating, and an identified path to recourse.

The governing principle is proportionality. A few-cents data lookup and a six-figure supplier contract clearly should not carry the same overhead, so the assurance is meant to scale with what is at stake.

How it works at transaction time

The runtime flow is deliberately mundane. Before completing a purchase, the agent requests /.well-known/legal-context.json from the merchant’s domain, reads the terms field, and fetches the terms document it points to. At Level 1 that is enough: the agent has the terms, and proceeding records consent. At Level 2 it goes one step further, recomputing the SHA-256 hash of the document it just downloaded and comparing it to the atrHash in the discovery file. If the two match, the agent has cryptographic proof that the terms it read are the exact terms the merchant published, unaltered. At Levels 3 and 4, a digital signature and an API call add explicit acceptance and a route into dispute resolution. There are no new rails and no plugin to install: an ordinary HTTPS request, plus an optional hash comparison the agent can run locally.

Where it sits in the stack

LCP does not compete with the payment and identity work already underway. It is built to complete it. The launch frames the layers cleanly: payment protocols such as x402 and the Trusted Agent Protocol answer what was paid; identity and coordination frameworks answer who acted; LCP answers under what terms, governed by what law, and with what recourse.

This is where it meets ground we have covered before. Visa’s TAP, which recently went live across Europe, verifies that an agent at a merchant’s door is a trusted one. It answers who the agent is. It says nothing about the terms of the deal that agent then strikes. LCP is the piece that names those terms and makes them verifiable, and the standard already documents how the two are meant to work together. Identity gets the agent in. Terms define what it agreed to.

Why this matters for pricing

Here is the part a pricing team should sit up for. In an agent-mediated market, a price is never really a number on its own. It is a number under terms: the returns policy, the cancellation window, the delivery guarantee, the recourse if the item never arrives. A human skims that fine print occasionally. An agent reads all of it, every time, and once LCP is in play it reads the terms in the same machine-readable pass as everything else. Price becomes one field in a structured, verifiable offer, weighed against the terms attached to it.

That has two consequences for how prices are set and defended.

First, price and terms have to be coherent. If your pricing logic and your published terms disagree, an agent comparing structured offers will catch it, and the inconsistency becomes a reason to route around you rather than a detail no one reads.

Second, provability starts to matter at the price level, not just the terms level. Dynamic prices move constantly, so when an agent buys at 14:32 and a dispute follows, the question is what the price and the terms were at that precise moment. LCP answers the terms half: its atrHash freezes the exact terms document in force at the point of sale, verifiable long after the fact. The price half has no such standard, so it has to come from your side. That means holding a timestamped, reconstructable record of the price that was live at 14:32 and the signals that produced it. Put plainly, a hash-verified terms record on one side needs an audit-verified price record on the other. Auditable pricing stops being a compliance nicety and becomes the structural counterpart to what LCP introduces.

The stack is filling in fast. Payment says what was paid. Identity says who acted. LCP says under what terms. The question each retailer answers for itself is whether its prices can stand in that record, clearly and provably, at the moment an agent decides.

Frequently Asked Questions