Introducing SAM Protocol: A Signed Identity Envelope for Agent-Ready Merchants

By early 2026 an AI agent can find a product and pay for it. What it still cannot do reliably is answer a more basic question before it acts: who is this merchant, what agent-facing surfaces do they actually publish, and how far am I allowed to go on my own? The discovery and payment protocols are silent on identity and bounds. We have been building a UCP merchant server for long-tail merchants, kept hitting that gap, and are now proposing a small, focused standard to close it: SAM — a signed envelope a merchant publishes once, that an agent can verify before it does anything. This is the first draft.

The layer the agentic stack is missing

The 2026 stack is crowded but coherent. UCP describes a merchant's commerce capabilities, ACP exposes the catalog, MCP exposes tools, and AP2 carries the user's payment authorization. Each answers a real question. None answers the first question an autonomous agent should ask: is this merchant who they claim to be, is the information I am reading current and genuine, and within which limits may I transact without a human? Today an agent either trusts whatever it scrapes, or every platform invents its own ad-hoc identity check. Both are fragile.

What SAM proposes

SAM is deliberately not another commerce protocol. It is one signed file — sam.json, published at /.well-known/ — that does three things: it states the merchant's identity, it references the other surfaces they publish (their UCP document, their AP2 endpoint), and it declares a policy mandate: the bounds within which an agent may act autonomously before control returns to a human. The whole envelope is signed with ed25519, so an agent can verify it is genuine and unaltered before following a single reference.

The design rule is composition, not replacement. SAM does not duplicate what UCP or AP2 already say; it points at them and makes the pointer verifiable. A merchant already on UCP adds SAM without rewriting anything.

A first sam.json

{
  "sam:version": "1",
  "sam:identity": { "domain": "example.com", "legalName": "Example Inc." },
  "sam:signature": {
    "alg": "ed25519",
    "validUntil": "2026-04-15T00:00:00Z",
    "value": "base64(...)"
  },
  "sam:composes": {
    "ucp": { "href": "/.well-known/ucp", "version": "1.0" },
    "ap2": { "supported": true, "endpoint": "/ap2/checkout" }
  },
  "sam:mandate": {
    "autoExecute": true,
    "maxAmount": { "value": 200, "currency": "EUR" },
    "validityWindow": {
      "notBefore": "2026-01-15T00:00:00Z",
      "notAfter": "2026-04-15T00:00:00Z"
    }
  },
  "sam:human": { "channels": [ { "type": "email", "value": "agents@example.com" } ] }
}

Three parts carry the weight. sam:identity says who. sam:signature makes the file tamper-evident and time-bounded — an agent that reads an envelope past its validUntil treats it as stale. sam:mandate is the part we care most about: an explicit, machine-readable statement of what an agent may do on its own — here, auto-execute purchases up to 200 EUR inside a validity window — and sam:human is where control goes when those bounds are exceeded.

Signed, time-bounded, locally enforced

Two properties matter. First, verification is offline: the agent checks the ed25519 signature itself, with no callback to the merchant or a third party, so there is no new runtime dependency and no privacy leak. Second, the mandate is enforced locally by the agent against the signed bounds — exceed the maxAmount or fall outside the validity window and the transaction does not proceed autonomously; it escalates to the human channel. The merchant declares the rules once; every conformant agent applies them the same way.

This is the same instinct behind our work on UCP: pin the edge cases down in a signed, verifiable artifact rather than leave them to diverge across implementations. Our UCP mandate-evaluation proposal does it for the moment a payment mandate expires mid-checkout; SAM does it for the question of merchant identity and autonomous bounds.

Why we are proposing this

We hit this building MerchantStamp, which audits and structures e-commerce catalogs so AI agents can actually read them. Once a catalog is legible, the next question from any serious agent is whether the merchant behind it is trustworthy and how far it can be trusted — and there is no standard answer. SAM is our proposal for that answer. We are drafting it in the open and will implement it first in our own merchant server, so it stays grounded in something that has to work, not just something that reads well in a spec.

What is next

This is an early draft and the grammar of the mandate will change as we test it. If you are building agents, merchant infrastructure, or a trust layer of your own, we would rather hear your objections now than after the format sets. In the meantime, the most useful thing most merchants can do is get the layer underneath right: a catalog an agent can read. Run a free MerchantStamp audit to see where yours stands.