SAM Protocol vorgestellt: ein signierter Identitäts-Envelope für agentenbereite Händler

Anfang 2026 kann ein KI-Agent ein Produkt finden und bezahlen. Was er weiterhin nicht zuverlässig kann, ist eine grundlegendere Frage vor dem Handeln zu beantworten: Wer ist dieser Händler, welche agentengerichteten Oberflächen veröffentlicht er tatsächlich, und wie weit darf ich allein gehen? Die Discovery- und Zahlungsprotokolle schweigen zu Identität und Grenzen. Beim Bau eines UCP-Händlerservers für Long-Tail-Händler stießen wir immer wieder auf diese Lücke und schlagen nun einen kleinen, fokussierten Standard vor, um sie zu schließen: SAM — ein signierter Envelope, den ein Händler einmal veröffentlicht und den ein Agent prüfen kann, bevor er irgendetwas tut. Dies ist der erste Entwurf.

Die Ebene, die dem Agentic-Stack fehlt

Der Stack von 2026 ist dicht, aber kohärent. UCP beschreibt die Commerce-Fähigkeiten eines Händlers, ACP legt den Katalog offen, MCP die Werkzeuge, und AP2 trägt die Zahlungsautorisierung des Nutzers. Jedes beantwortet eine echte Frage. Keines beantwortet die erste Frage, die ein autonomer Agent stellen sollte: Ist dieser Händler der, der er zu sein behauptet, sind die Informationen, die ich lese, aktuell und echt, und in welchen Grenzen darf ich ohne Menschen transagieren? Heute vertraut ein Agent entweder dem, was er scrapt, oder jede Plattform erfindet ihre eigene Ad-hoc-Identitätsprüfung. Beides ist brüchig.

Was SAM vorschlägt

SAM ist bewusst kein weiteres Commerce-Protokoll. Es ist eine einzige signierte Datei — sam.json, veröffentlicht unter /.well-known/ —, die drei Dinge tut: Sie nennt die Identität des Händlers, sie referenziert die anderen Oberflächen, die er veröffentlicht (sein UCP-Dokument, seinen AP2-Endpunkt), und sie deklariert ein Policy-Mandat: die Grenzen, in denen ein Agent autonom handeln darf, bevor die Kontrolle an einen Menschen zurückgeht. Der gesamte Envelope ist mit ed25519 signiert, sodass ein Agent prüfen kann, dass er echt und unverändert ist, bevor er einer einzigen Referenz folgt.

Die Entwurfsregel ist Komposition, nicht Ersatz. SAM dupliziert nicht, was UCP oder AP2 bereits sagen; es zeigt auf sie und macht den Zeiger verifizierbar. Ein Händler, der bereits UCP nutzt, ergänzt SAM, ohne irgendetwas neu zu schreiben.

Eine erste 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" } ] }
}

Drei Teile tragen das Gewicht. sam:identity sagt, wer. sam:signature macht die Datei manipulationssicher und zeitlich begrenzt — ein Agent, der einen Envelope nach seinem validUntil liest, behandelt ihn als veraltet. sam:mandate ist der Teil, der uns am wichtigsten ist: eine explizite, maschinenlesbare Erklärung dessen, was ein Agent allein tun darf — hier Käufe bis 200 EUR innerhalb eines Gültigkeitsfensters automatisch ausführen — und sam:human ist der Ort, an den die Kontrolle geht, wenn diese Grenzen überschritten werden.

Signiert, zeitlich begrenzt, lokal durchgesetzt

Zwei Eigenschaften zählen. Erstens ist die Prüfung offline: Der Agent prüft die ed25519-Signatur selbst, ohne Rückruf zum Händler oder zu Dritten — also keine neue Laufzeitabhängigkeit und kein Datenabfluss. Zweitens wird das Mandat lokal vom Agenten gegen die signierten Grenzen durchgesetzt — überschreiten Sie den maxAmount oder fallen Sie aus dem Gültigkeitsfenster, läuft die Transaktion nicht autonom weiter; sie wird an den menschlichen Kanal eskaliert. Der Händler deklariert die Regeln einmal; jeder konforme Agent wendet sie gleich an.

Das ist derselbe Instinkt wie hinter unserer UCP-Arbeit: Grenzfälle in einem signierten, verifizierbaren Artefakt festlegen, statt sie zwischen Implementierungen auseinanderlaufen zu lassen. Unser UCP-mandate-evaluation-Vorschlag tut das für den Moment, in dem ein Zahlungsmandat mitten im Checkout abläuft; SAM tut es für die Frage der Händleridentität und der autonomen Grenzen.

Warum wir es vorschlagen

Wir stießen darauf beim Bau von MerchantStamp, das E-Commerce-Kataloge auditiert und strukturiert, damit KI-Agenten sie tatsächlich lesen können. Ist ein Katalog erst lesbar, lautet die nächste Frage jedes ernsthaften Agenten, ob der Händler dahinter vertrauenswürdig ist und wie weit — und es gibt keine Standardantwort. SAM ist unser Vorschlag für diese Antwort. Wir entwerfen es offen und implementieren es zuerst in unserem eigenen Händlerserver, damit es in etwas verankert bleibt, das funktionieren muss, nicht nur in einer Spezifikation gut klingt.

Wie es weitergeht

Dies ist ein früher Entwurf, und die Grammatik des Mandats wird sich beim Testen ändern. Wenn Sie Agenten, Händlerinfrastruktur oder Ihre eigene Vertrauensebene bauen, hören wir Ihre Einwände lieber jetzt als nach dem Festschreiben des Formats. In der Zwischenzeit ist das Nützlichste für die meisten Händler, die darunterliegende Ebene richtig zu machen: ein Katalog, den ein Agent lesen kann. Starten Sie ein kostenloses MerchantStamp-Audit, um zu sehen, wo Ihrer steht.