SAM Protocol : une enveloppe d'identité signée pour les marchands prêts pour les agents

Début 2026, un agent IA sait trouver un produit et le payer. Ce qu'il ne sait toujours pas faire de façon fiable, c'est répondre à une question plus élémentaire avant d'agir : qui est ce marchand, quelles surfaces destinées aux agents publie-t-il réellement, et jusqu'où ai-je le droit d'aller seul ? Les protocoles de découverte et de paiement sont muets sur l'identité et les bornes. En construisant un serveur marchand UCP pour des marchands de longue traîne, nous avons buté sur cette lacune, et nous proposons maintenant un standard petit et ciblé pour la combler : SAM — une enveloppe signée que le marchand publie une fois, qu'un agent peut vérifier avant de faire quoi que ce soit. Voici la première version.

La couche qui manque à la pile agentique

La pile de 2026 est dense mais cohérente. UCP décrit les capacités commerce d'un marchand, ACP expose le catalogue, MCP expose les outils, et AP2 porte l'autorisation de paiement de l'utilisateur. Chacun répond à une vraie question. Aucun ne répond à la première question qu'un agent autonome devrait poser : ce marchand est-il bien celui qu'il prétend être, l'information que je lis est-elle actuelle et authentique, et dans quelles limites puis-je transacter sans humain ? Aujourd'hui, un agent fait confiance à ce qu'il scrape, ou chaque plateforme invente son propre contrôle d'identité ad hoc. Les deux sont fragiles.

Ce que propose SAM

SAM n'est délibérément pas un protocole de commerce de plus. C'est un seul fichier signé — sam.json, publié sur /.well-known/ — qui fait trois choses : il déclare l'identité du marchand, il référence les autres surfaces qu'il publie (son document UCP, son endpoint AP2), et il déclare un mandat de politique : les bornes dans lesquelles un agent peut agir de façon autonome avant que la main ne revienne à un humain. L'enveloppe entière est signée en ed25519, pour qu'un agent puisse vérifier qu'elle est authentique et intacte avant de suivre la moindre référence.

La règle de conception, c'est la composition, pas le remplacement. SAM ne duplique pas ce que disent déjà UCP ou AP2 ; il pointe vers eux et rend le pointeur vérifiable. Un marchand déjà sous UCP ajoute SAM sans rien réécrire.

Un premier 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" } ] }
}

Trois parties portent l'essentiel. sam:identity dit qui. sam:signature rend le fichier infalsifiable et borné dans le temps — un agent qui lit une enveloppe au-delà de son validUntil la traite comme périmée. sam:mandate est la partie qui nous importe le plus : une déclaration explicite et lisible par machine de ce qu'un agent peut faire seul — ici, auto-exécuter des achats jusqu'à 200 EUR dans une fenêtre de validité — et sam:human est l'endroit où la main repasse quand ces bornes sont dépassées.

Signé, borné dans le temps, appliqué localement

Deux propriétés comptent. D'abord, la vérification est hors ligne : l'agent vérifie lui-même la signature ed25519, sans rappel vers le marchand ni un tiers, donc pas de nouvelle dépendance à l'exécution ni de fuite de données. Ensuite, le mandat est appliqué localement par l'agent contre les bornes signées — dépassez le maxAmount ou sortez de la fenêtre de validité et la transaction ne se poursuit pas en autonomie ; elle est escaladée vers le canal humain. Le marchand déclare les règles une fois ; chaque agent conforme les applique de la même façon.

C'est le même instinct que derrière notre travail sur UCP : trancher les cas limites dans un artefact signé et vérifiable plutôt que les laisser diverger entre implémentations. Notre proposition UCP mandate-evaluation le fait pour le moment où un mandat de paiement expire en plein checkout ; SAM le fait pour la question de l'identité du marchand et des bornes d'autonomie.

Pourquoi nous le proposons

Nous y sommes arrivés en construisant MerchantStamp, qui audite et structure les catalogues e-commerce pour que les agents IA puissent réellement les lire. Une fois le catalogue lisible, la question suivante de tout agent sérieux est de savoir si le marchand derrière est digne de confiance et jusqu'où — et il n'existe pas de réponse standard. SAM est notre proposition de réponse. Nous la rédigeons à ciel ouvert et l'implémenterons d'abord dans notre propre serveur marchand, pour qu'elle reste ancrée dans quelque chose qui doit fonctionner, pas seulement qui se lit bien dans une spec.

La suite

C'est une première version, et la grammaire du mandat évoluera au fil de nos tests. Si vous construisez des agents, de l'infrastructure marchande ou votre propre couche de confiance, nous préférons entendre vos objections maintenant plutôt qu'une fois le format figé. En attendant, la chose la plus utile pour la plupart des marchands est de réussir la couche du dessous : un catalogue qu'un agent peut lire. Lancez un audit MerchantStamp gratuit pour voir où en est le vôtre.