Agentenökonomie und Interoperabilitätsprotokolle

Autorisiert von Agenten initiierte Käufe über eine Kette kryptografisch signierter Mandate in Form überprüfbarer Nachweise (verifiable credentials), anstatt einem Agenten die rohen Kartendaten zu übergeben. Ein Intent Mandate erfasst die im Voraus festgelegten Vorgaben des Nutzers (Höchstpreis, zugelassene Händler, Gültigkeitsdauer), sodass der Agent auch in Abwesenheit des Nutzers einkaufen kann; ein Cart Mandate wird vom Händler signiert und vom Nutzer gegengezeichnet und bezieht sich auf die genauen Artikel und den genauen Preis, sodass gilt: Was du siehst, ist, was du zahlst; und ein Payment Mandate wird mit dem Zahlungsnetzwerk geteilt. Die signierte Kette bildet einen nicht abstreitbaren Prüfpfad, der Autorisierung, Authentizität und Rechenschaftspflicht für autonome Ausgaben klärt, und sie ist schienenunabhängig (rail-agnostic) mit einem A2A-x402-Profil für Krypto-Rails. Abzugrenzen von authenticated-delegation: Dieses Muster verleiht einem Agenten eine begrenzte Handlungsbefugnis, während AP2 jeden einzelnen Kauf an eine signierte Mandatskette bindet, die ein Zahlungsnetzwerk unabhängig überprüfen kann.

Offener Standard, gemeinsam von Stripe und OpenAI entwickelt (Apache-2.0, September 2025), um einen Kauf bei einem Händler abzuschließen, der Merchant of Record bleibt. Der Händler stellt agentenseitige REST- oder MCP-Endpunkte bereit (Checkout erstellen, aktualisieren, abschließen und abbrechen) auf Basis eines Produkt-Feeds; der Agent zahlt mit einem von Stripe ausgestellten Shared Payment Token, der auf einen einzelnen Händler und die Warenkorbsumme beschränkt ist, sodass der Agent die Kartendaten des Käufers nie zu sehen bekommt. Er startete als der Standard hinter ChatGPT Instant Checkout mit Etsy-Verkäufern und Shopify-Händlern. Abzugrenzen von `model-context-protocol`: MCP ist ein allgemeiner Transport für Tool-Aufrufe, während ACP ein spezifischer Checkout-Vertrag ist, der über MCP oder einfaches REST laufen kann.

Ein offener Zahlungsstandard, 2025 von Coinbase geschaffen und nun von der x402 Foundation unter dem Dach der Linux Foundation betreut, der den brachliegenden Statuscode HTTP 402 Payment Required als Bezahl-pro-Anfrage-Schiene wiederbelebt. Ein Server antwortet mit 402 und maschinenlesbaren Zahlungsanforderungen; der Client (Mensch oder Agent) sendet eine signierte Stablecoin-Zahlung in einem HTTP-Header zurück; ein Facilitator prüft die Nutzlast und wickelt den Transfer on-chain ab (EVM-Chains, Solana und weitere): alles innerhalb einer einzigen Anfrage, ohne Konten, Sitzungen oder API-Schlüssel. Es ist eine native Schiene für schlüssellose Agent-zu-Service-Mikrozahlungen im Sub-Cent-Bereich sowie für nutzungsabhängigen Tool- oder Datenzugriff und zugleich das Krypto-Profil, auf das sich die A2A-x402-Erweiterung von AP2 bezieht. Abzugrenzen von `agentic-commerce-protocol`: ACP ist ein kartenbasierter Einzelhandels-Checkout über einen Merchant of Record, während x402 eine maschinelle Zahlung pro Aufruf ist, die on-chain abgewickelt wird.

Die Discovery-Schicht, die es Agenten und Tool-Servern ermöglicht, sich zur Laufzeit gegenseitig zu finden, statt über eine fest verdrahtete Konfiguration. Drei zusammenlaufende Mechanismen machen das möglich: A2A Agent Cards, ein selbstbeschreibendes JSON-Manifest, das unter /.well-known/agent-card.json (RFC 8615) bereitgestellt wird und die Fähigkeiten, Endpunkte, Auth-Schemata und Streaming-Fähigkeiten eines Agenten bekannt gibt; die offizielle MCP Registry (Vorschau September 2025), ein föderierter öffentlicher Katalog und eine API zum Veröffentlichen und Auffinden von MCP-Servern, erweiterbar um private Unternehmens-Subregistries; und dezentrale Naming-Vorschläge wie MIT Project NANDA, dessen NANDA Index kryptografisch überprüfbare AgentFacts-Einträge zu Endpunkten auflöst und als DNS für Agenten positioniert ist. Das gängige Muster lautet: einen signierten Capability-Eintrag veröffentlichen, ihn dann per Well-Known-URI oder Registry-Abfrage auflösen, die angegebenen Auth-Schemata validieren und den Agenten dynamisch einbinden. Abzugrenzen von `a2a-protocol`: Dieses deckt den Nachrichtentransport ab, sobald ein Peer bekannt ist, während es hier darum geht, den Peer überhaupt erst zu finden und zu prüfen.

Angebotsseitige Verträge, die den Inhalt einer Website direkt für Agenten zugänglich machen, anstatt sie zu zwingen, das gerenderte HTML auszulesen. llms.txt (Jeremy Howard, 2024) ist ein kuratierter Markdown-Index unter /llms.txt samt .md-Schattenseiten, die einem LLM zur Inferenzzeit hochdichte, navigationsfreie Inhalte liefern. Microsoft NLWeb (2025, geleitet von R.V. Guha, Mitbegründer von Schema.org) geht mit einem /ask-Endpunkt in natürlicher Sprache noch weiter, der strukturiertes JSON zurückgibt, das in den eigenen Schema.org-Daten der Website verankert ist, wobei jede NLWeb-Instanz zugleich als MCP-Server fungiert. Zusammen definieren sie die agentenlesbare Website: das leseseitige Gegenstück zu robots.txt für das agentische Web.

Ein aufkommender Standard im IETF-Entwurfsstadium (Cloudflare und Google), der es einem Agenten ermöglicht, seine Identität gegenüber einer Website mithilfe der HTTP Message Signatures aus RFC 9421 kryptografisch nachzuweisen. Der Agent signiert jede ausgehende Anfrage mit einem Ed25519-Schlüssel, veröffentlicht seine öffentlichen Schlüssel als JWKS-Schlüsselverzeichnis unter /.well-known/http-message-signatures-directory und verweist darauf mit einem Signature-Agent-Header; der Origin ruft das Verzeichnis ab, prüft die Signatur und entscheidet, ob der Datenverkehr zugelassen, abgelehnt, ratenbegrenzt oder bepreist wird. Er ersetzt brüchige Allowlists auf Basis von IP-Bereichen und User-Agent, und Cloudflares Signed Agents machen ihn am Edge zum Produkt. Abzugrenzen von authenticated-delegation: Dieses weist die Autorität vom Nutzer zum Agenten nach, während Web Bot Auth das Umgekehrte ist: ein Agent, der einer Website seine Herkunft nachweist.

Aufkommende, größtenteils im Entwurfsstadium befindliche Standards dafür, wie ein Agent das Kontrahentenrisiko gegenüber einem unbekannten Agenten ohne zentralen Gatekeeper bepreist. Der Entwurf des EIP ERC-8004 „Trustless Agents“ definiert drei On-Chain-Registries: Identity (ein ERC-721-Handle, das auf Off-Chain-Agentenmetadaten verweist), Reputation (signierte Feedback-Signale) und Validation (Attestierungen von Validator-Contracts wie einsatzgesicherte Re-Ausführung oder TEE-Oracles), wobei Zahlungen und Anwendungslogik bewusst off-chain gehalten werden. Eine begleitende Taxonomie von Vertrauensmodellen ordnet die Mechanismen in sechs Kategorien ein (brief, claim, proof, stake, reputation und constraint) und argumentiert, dass kein einzelner Mechanismus ausreicht und gestufte Kombinationen nötig sind. Das Feld ist noch jung und unausgereift: ERC-8004 ist ein EIP-Entwurf, und ein Großteil des Toolings steckt in den Anfängen. Abzugrenzen von authenticated-delegation: Dabei geht es um delegierte Autorität und Identität, während es hier um reputationsbasiertes Vertrauen geht, das zwischen wirtschaftlichen Peers bepreist wird.