SpendVeto

Die Spend-Governance-Ebene für KI-Agenten, die für Dinge bezahlen. Zahlungsschienen bewegen das Geld eines Agenten; SpendVeto entscheidet, ob der Agent es bewegen darf — Policy-Prüfungen, menschliche Genehmigung, delegierte Budgetobergrenzen und ein Kill-Switch für außer Kontrolle geratene Agenten, durchgesetzt bevor irgendeine Zahlung erfolgt.

Begonnen als „kleinster echter Test" aus dem web3-Forschungsbrief; durch zwei forschungsgetriebene Feature-Runden (GPT-Deep-Research + Live-Marktforschung) zu einem verwalteten x402- + MCP-Stack gewachsen. Funding-Positionierung und Marktzahlen stehen in PITCH.md.

Was das eigentlich ist

Ein Governance-Gate vor einem Katalog bezahlter Endpunkte, auf drei Wegen erreichbar — CLI, delegierte Child-Agenten und jeder MCP-Client:

agent (CLI / child wallet / Claude via MCP)
   → frozen? (manual kill switch, or auto-frozen by the runaway-burst detector)
   → policy check (per-call, hourly, rate, cascading delegation caps)
   → [maybe: human approval on the dashboard — fails closed on timeout]
   → pay $X USDC via x402 (simulate or Base Sepolia testnet)
   → GET /api/agent/<tool> → Claude does the task
   → everything lands in the ledger; blocked-spend dollars roll up on the dashboard

Related MCP server: Proofpane

Schnellstart

npm install
npm run server               # terminal 1 — :8402, dashboard at http://localhost:8402
npm run call                  # terminal 2 — pays for "review" ($0.01), auto-approved
npm run call -- summarize      # $0.02 — above the approval line: go approve/deny it on the dashboard
npm run call -- translate      # $0.005

npm run verify führt das Ganze headless aus — 264 End-to-End-Assertions: Katalog, Ablehnung gefälschter Signaturen, harte Policy-Blöcke, alle drei Genehmigungsergebnisse (genehmigt / abgelehnt / Timeout-fällt-geschlossen-aus), Delegationsobergrenzen einschließlich der n-stufigen Kaskade, Tool- + Chain-Scoping, Multichain-Settlement (chain-gescopte Signaturen, Balances pro Chain, Chain-Allowlists), Auto-Freeze bei Runaway-Bursts, der manuelle Kill-Switch, Verifikation signierter Belege, CSV-Export, Analytics pro Tool/pro Wallet/pro Chain, Webhook-Alerts, die tatsächlich bei einem Live-Empfänger ankommen, strukturierte selbstkorrigierende Ablehnungen, nebenwirkungsfreie Dry Runs, TTL-Grant-Ablauf, One-Click-Genehmigungslinks, der Stats-Endpunkt, AP2-Mandatsketten-Drift-Erkennung, Human-not-present-Autorität, verwaltete Bazaar-Erkennung, ACP-Shared-Payment-Token-Scope, Request-Integritätsbindung (einschließlich einer nach der Autorisierung ausgetauschten Payload), signierte Streitfall-Beweispakete und deren Manipulationserkennung, OpenTelemetry-Span-Export unter einem eingehenden traceparent und ein echter MCP-stdio-JSON-RPC-Roundtrip.

Zur Zahl: Ein frischer Clone führt 264 Assertions aus. Drei weitere testen eine echte projektübergreifende Integration gegen Basis und laufen nur, wenn ../prediction-copilot neben diesem Repo ausgecheckt ist — die Suite gibt (skipped: cross-project Basis integration test …) aus, wenn das nicht der Fall ist. Jede veröffentlichte Zahl ist die 264, die jeder reproduzieren kann.

Marketing-Website: npm run site liefert die deploy-fertige Landing Page (Three.js-Hero, animierter Produkt-Walkthrough) unter http://localhost:8403 — site/ ist vollständig statisch und eigenständig, einfach so auf Vercel/Netlify ablegen. Enthält einen interaktiven Playground (site/playground.html), der die echte Policy-Entscheidungslogik clientseitig ausführt — Budget setzen, Agent-Spend auslösen, zusehen wie es durchgeht/pausiert/blockiert — und eine Use-Cases-Seite, die auf realen Agent-Spend-Szenarien von 2026 basiert.

Der Katalog

Drei echte Claude-gestützte Tools zu drei Preisen (shared-config.js):

MCP: Governance, der sich das Modell nicht entziehen kann

mcp/server.js stellt den bezahlten Katalog jedem MCP-Client zur Verfügung. Der Agent sieht gewöhnliche Tools; jeder Aufruf führt still die vollständige verwaltete Pipeline aus (Policy → Genehmigung → x402-Zahlung), bevor die Aufgabe ausgeführt wird. Blockierte Aufrufe kommen als Tool-Fehler zurück, die erklären, welches Gate sie gestoppt hat und dass nichts ausgegeben wurde.

# Register with Claude Code (server must be running: npm run server)
claude mcp add spendveto -- node ~/Desktop/spendveto/mcp/server.js

Oder in der Konfiguration von Claude Desktop:

{ "mcpServers": { "spendveto": { "command": "node", "args": ["/Users/you/Desktop/spendveto/mcp/server.js"] } } }

Vier Tools erscheinen: review, summarize, translate (jedes mit Preis in der Beschreibung) und spendveto_status (kostenlos — Wallet, Balance, Policy, Ausgaben der letzten Stunde, ausstehende Genehmigungen, delegierte Budgets). Fragen Sie Claude „Wie ist der Budgetstatus meines Agenten?" und dann „führe das bezahlte summarize-Tool aus" und beobachten Sie, wie die Genehmigung im Dashboard erscheint.

Budget-Delegation („IAM für Geld")

Ein Parent-Wallet gewährt einem Child-Agenten-Wallet ein gedeckeltes Lifetime-Budget — und Kinder können weiter delegieren. Obergrenzen kaskadieren: Die Ausgaben eines Enkels zählen gegen seine eigene Obergrenze und die jedes Vorfahren, sodass ein ganzes Team von Sub-Agenten niemals das Budget an der Spitze seines Zweigs überschreiten kann. Die Durchsetzung läuft bei jedem Aufruf in der eigenen Policy-Prüfung des Aufrufers; das Dashboard zeigt die Hierarchie als Live-Spend-vs-Cap-Balken.

npm run delegate -- 0.015 "team lead"                 # main wallet grants $0.015
npm run delegate -- 0.05 "intern" --parent "team lead" # team lead grants onward
npm run call -- review --child=intern                  # fine — fits both caps
npm run call -- review --child=intern                  # BLOCKED … granted to ancestor "team lead"
npm run delegate -- 0.02 "translator" --tools translate # scope, not just size
npm run call -- review --child=translator               # BLOCKED … outside its delegated scope
npm run delegate -- 0.02 "base only" --chains base-sepolia  # pin the settlement chain too
npm run call -- review --child="base only" --chain=polygon   # BLOCKED … outside its delegated chain scope
npm run delegate -- 0.05 "flash task" --ttl 10m              # time-boxed budget: self-expires

Jederzeit widerrufbar: POST /api/delegations/:id/revoke — ein widerrufener Link tötet den gesamten Zweig darunter.

Belege, Exporte, Alerts, Analytics

Jedes Settlement im Simulate-Modus kommt ECDSA-signiert vom Server zurück (settlement.signature / signedBy / receiptId), sodass Belege unabhängig verifizierbar sind — und jetzt adressierbar: GET /api/receipts/:id schlägt einen nach, POST /api/receipts/verify prüft die Signatur jedes Belegs serverseitig (ein manipulierter Preis schlägt fehl — getestet). Setzen Sie alertSigningSecret in der Policy, und jede Webhook-Zustellung trägt einen X-SpendVeto-Signature-HMAC-Header, sodass Empfänger nachweisen können, dass ein Alert wirklich von Ihrem SpendVeto stammt. Das vollständige Ledger wird als CSV unter /api/export.csv exportiert; Rollups pro Tool und pro Wallet liegen unter /api/analytics; und wenn Sie alertWebhookUrl in data/policy.json setzen, werden Freezes, blockierte Aufrufe und ausstehende Genehmigungen in Echtzeit dorthin gepostet (z. B. auf einen Slack-Incoming-Webhook zeigen lassen).

Kill-Switch + Runaway-Erkennung

Jedes Wallet kann vom Dashboard aus eingefroren werden (oder POST /api/freezes), und ein Wallet, das Zahlungsversuche schneller feuert als der Burst-Schwellenwert der Policy (Standard: 10 Versuche in 10 Sekunden), wird automatisch eingefroren — eine außer Kontrolle geratene Agent-Schleife wird mitten im Burst erwischt, nicht erst auf der Rechnung des nächsten Monats. Eingefrorene Wallets werden in ihrer eigenen Policy-Prüfung blockiert und am Simulate-Zahlungsgate abgewiesen, selbst mit korrekt signierter Zahlung (403). Mit einem Klick wieder auftauen, sobald Sie herausgefunden haben, was der Agent getan hat.

Enforcement-Proxy — schlüssellose Agenten („SpendVeto auf dem Geldpfad")

npm run proxy (:8404) dreht das Vertrauensmodell um: Agenten halten überhaupt keine Schlüssel. Sie POSTen eine Ausgaben-Absicht; der Proxy hat die Verwahrung, führt die vollständige Pipeline aus (Freeze → Policy → kaskadierende Caps/Scopes → Genehmigung) und signiert und bezahlt erst dann. Ein bösartiger Agent kann seine Policy-Prüfung nicht überspringen, weil er nie etwas zum Signieren hatte.

curl -X POST localhost:8404/proxy/call -H 'Content-Type: application/json' \
  -d '{"tool":"review"}'                      # custody wallet
  -d '{"tool":"review","child":"intern"}'      # spend as a delegated child, by label

Abgewiesene Absichten kommen mit 403 zurück, mit dem Gate, dem Grund und einer strukturierten Ablehnung — nichts signiert, nichts bewegt. Senden Sie einen Idempotency-Key (Header oder Body), und eine wiederholte Absicht spielt die gespeicherte Antwort ab, statt doppelt zu zahlen — ein crash-loopender Agent kann nicht doppelt ausgeben (getestet: gleicher Schlüssel zweimal → ein Ledger-Eintrag).

Ablehnungen, auf die Agenten reagieren können, Dry Runs, zeitlich begrenzte Budgets

Drei Kontrollen aus der Forschungsrunde vom Juli 2026 (siehe launch/DEEP_RESEARCH_PROMPTS.md):

• Selbstkorrigierende Ablehnungen — jeder Block trägt einen maschinenlesbaren code (per_call_cap, chain_scope, hourly_usd_cap, delegation_expired, …) und einen konkreten suggestion („auf einer erlaubten Chain erneut versuchen: base-sepolia, base" / „verbleibendes Budget auf dieser Linie: $0.0050 — wählen Sie ein günstigeres Tool"). Das CLI gibt es als Fix:-Zeile aus, MCP-Fehler bei blockierten Tools enthalten es, sodass das Modell sich selbst korrigieren kann, statt in Retry-Schleifen zu laufen, und der Proxy gibt es im 403-Body zurück.

• Dry Runs — npm run call -- summarize --dry-run (oder {"dryRun": true} am Proxy) bewertet die gesamte Pipeline — Freeze, Chain-Regeln, Caps, Delegationslauf, Genehmigungsschwelle — und meldet würde zahlen / würde für Genehmigung pausieren / würde blockieren (mit dem Fix) mit null Nebenwirkungen: keine Zahlung, keine Genehmigungsanfrage, kein Ledger-Eintrag (getestet).

• Zeitlich begrenzte Budgets — --ttl 90 / --ttl 10m / --ttl 2h auf jedem Grant: nach expiresAt ist der Grant so tot wie ein widerrufener, und ein abgelaufener Vorfahr tötet seinen gesamten Zweig.

• One-Click-Genehmigungen — Genehmigungs-Webhooks tragen jetzt approveUrl / denyUrl; fügen Sie den Alert in Slack ein, und der Genehmiger entscheidet mit einem einzigen Klick aus dem Chat.

Eine API, jede Schiene (rails/)

Jede Zahlungsschiene steckt hinter demselben Vier-Zeilen-Vertrag — { id, name, status, pay({ tool, account, chain, baseUrl }) } — und die Governance-Pipeline erfährt nie, welche Schiene abgerechnet hat. Zwei Schienen sind heute live (x402-simulate, x402-live — letztere facilitator-adaptiv über alle Registry-Chains, die der Facilitator unterstützt); Google AP2, OpenAI ACP und Stripe Machine Payments sind deklarierte Adapter-Slots, die ehrlich ablehnen (not implemented yet — funded-roadmap slot), statt so zu tun als ob. GET /api/rails liefert das Registry; der Proxy bewirbt es in /proxy/health. Das ist die „Stripe für Agent-Ausgaben"-Form ohne die Money-Transmitter-Lizenz: eine Integration vor jeder Schiene, Governance darüber, Settlement darunter.

SDK, LangChain und nebenläufigkeitssichere Caps

Zwei Code-Ebene-Integrationsflächen neben CLI und MCP-Server, beide dependency-frei und beide in npm run verify end-to-end getestet, nicht nur geparst:

• sdk/ — ein Node-Client (SpendVeto-Klasse): .pay(), .dryRun(), .chat() (verwaltete LLM/API-Ausgaben), .registerAgent(), .catalog(). Ein blockierter Aufruf wirft einen typisierten SpendVetoDenialError{code, suggestion, stage}, statt still nichts zu tun.

• integrations/langchain.js — Katalog-Tools als LangChain-förmige { name, description, func }-Objekte, null harte Abhängigkeit von @langchain/core. Ablehnungen werfen mit eingebettetem strukturiertem Code, sodass der nächste Reasoning-Schritt eines Agenten sich selbst korrigieren kann.

• integrations/openai-agents.js — derselbe verwaltete Katalog als OpenAI-Agents-SDK-förmige { name, description, parameters, execute }-Tools (der Vertrag des tool()-Helpers), null harte Abhängigkeit von @openai/agents; es formt den LangChain-Adapter um, sodass beide eine Pipeline ausführen.

Beide rufen über den Enforcement-Proxy auf, der jetzt die Decide-and-Commit-Einheit jedes Wallets serialisiert (withWalletLock in client/pay.js) — damit wird eine echte Race geschlossen, bei der gleichzeitige Aufrufe gegen dasselbe Wallet jeweils denselben „bisher ausgegeben"-Snapshot lesen und gemeinsam ein für einen ausgelegtes Cap überschreiten konnten. Bewiesen mit 6 gleichzeitigen Aufrufen gegen ein Cap mit Platz für genau einen: genau einer gewinnt, bei jedem Lauf. Code-Beispiele: docs.html#sdk.

Agents-, Marketplace- & Report-Seiten (die Konsole, fertiggestellt)

Zwei Seiten schließen den Kreis zwischen dem, was die API bereits konnte, und dem, was ein Mensch anklicken kann: Agents mintet wallet-gebundene Identitätstoken und listet Marketplace-Tools aus Formularen (kein curl nötig), und Report beantwortet „Was hat uns das gekostet und was hat Governance gestoppt?" für ein rollierendes Fenster — GET /api/report?days=7 — mit einer einzeiligen Überschrift zum Einfügen in Slack, Aufschlüsselungen nach Kategorie und nach Chain sowie den häufigsten Gründen, warum Governance etwas blockiert hat.

Wettbewerbs-Paritätskontrollen (aus der Forschungslandkarte vom Juli 2026)

Vier Kontrollen, die die finanzierten Player ausliefern, ehrlich nachgebaut und getestet:

• Agent-Identitäten (Skyfire-Stil „Know your agent") – POST /proxy/agents {label, child} prägt ein Inhaber-Token, optional an eine Wallet gebunden. Offener Modus, solange keine existieren (Zero-Setup-Demos); sobald die erste Identität registriert ist, erfordern Proxy-Intents Authorization: Bearer …, und ein gebundenes Token kann nur als seine eigene Wallet ausgeben (getestet: ein child-Override im Body wird ignoriert). GET /proxy/agents/:id/credential ist die KYA-Anmeldeinformation selbst – ein Lesezugriff, der diese Identität mit dem Live-Vertrauensscore ihrer Wallet, dem Freeze-Status und dem Delegationsumfang (Cap/Tools/Chains/Payees) verbindet, sodass eine Gegenpartei prüfen kann, „was dieser Agent tatsächlich darf", ohne vier Endpunkte manuell abzugleichen.

• Kategorie-Caps (Ramp-Stil) – Tools tragen eine Ausgabenkategorie; "categoryCapsUSD": {"content": 5} in der Richtlinie begrenzt jede Kategorie pro Stunde, berechnet aus den eigenen Tags des Ledgers.

• N-Genehmiger-Regel (Safe-Stil) – "approversRequired": 2: Eine Ablehnung ist sofort und endgültig, aber die Genehmigung wird erst wirksam, wenn genügend Menschen geklickt haben (getestet: eine Genehmigung hält sie ausstehend).

• Handelszeiten-Fenster – "allowedHoursUTC": {"start": 13, "end": 21}: Außerhalb des Fensters gibt nichts aus. Die Kontrolle „Mein Bot hat um 3 Uhr morgens gehandelt", einschließlich Wrap-around-Fenstern.

Fünf weitere aus dem Konkurrenz-Re-Scan vom Juli 2026 (x402 Foundation Launch, AP2/Mastercard Agent Pay/Visa Trusted Agent gehen live)

• Pro-Agent-Ratenbegrenzung + Freeze (proxy/server.js) – Wallet-Level-Budget-Caps bleiben die Quelle der Wahrheit für Geld, aber mehrere Agent-Identitäten können sich eine Wallet teilen (agents.json), sodass ein einzelner fehlverhaltender oder schleifender Agent gestoppt werden kann, ohne jeden anderen Agenten auf dieser Wallet einzufrieren. Jede Identität erhält ihr eigenes Gleitfenster-Anruflimit (PER_AGENT_CALLS_PER_MIN, Standard 20); 3 aufeinanderfolgende Ratenbegrenzungs-Treffer frieren automatisch nur diese Identität ein (POST /proxy/agents/:id/freeze / /unfreeze auch für manuelle Steuerung) – unter Wiederverwendung des bestehenden Freeze-Speichers unter einem synthetischen agent:<id>-Schlüssel, sodass es weiterhin im Dashboard sichtbar und wie jeder andere Freeze alarmiert wird.

• Signierte Einwilligungsdatensätze (server/consents.js, Visa-Trusted-Agent-Protocol-Stil) – Das Gewähren oder Widerrufen einer Delegation schreibt jetzt auch einen ECDSA-signierten Einwilligungsdatensatz (mit demselben Server-Schlüssel, der Settlement-Belege und AP2-Urteile signiert) – GET /api/consent/:delegationId für den Verlauf, POST /api/consent/verify zur unabhängigen Prüfung der Signatur jedes Datensatzes, ohne der JSON-Datei zu vertrauen.

• Agentic Tokens (POST /api/agentic-token, Mastercard-Agent-Pay-Stil) – Ein schlankes, ehrliches Bündel über den beiden obigen Primitiven: eine Delegation, die auf genau einen Händler-Payee beschränkt ist, plus deren signierte Einwilligung, zurückgegeben als ein Objekt (GET /api/agentic-token/:id zum Nachschlagen). Die Durchsetzung ist dieselbe Payee-Allowlist + Cap-Prüfung, die jede Delegation bereits erhält.

• Verifiable-Credential-Export für AP2-Urteile (server/vc.js) – POST /api/ap2/evaluate?format=vc formt dasselbe signierte Urteil in einen W3C-VC-förmigen Umschlag um (AP2 selbst basiert auf Verifiable Credentials). Ehrlich gekennzeichnet: Der Beweistyp ist SpendVetos eigener, keine registrierte DID-Methode/Proof-Suite – aber proof.message + proof.proofValue sind exakt dieselbe ECDSA-Signatur, die der unverpackte Endpunkt bereits zurückgibt, unabhängig prüfbar mit verifyMessage oder jeder ECDSA-Bibliothek.

• Rail-übergreifende Beleg-Normalisierung (server/receipts.js) – GET /api/receipts/normalized projiziert jeden Ledger-Eintrag (x402-Krypto-Settlement, gemessene LLM/API-Ausgaben und welche Rail auch immer als Nächstes abwickelt) durch eine stabile Form, sodass ein Client nicht wissen muss, welche Rail welchen Eintrag erzeugt hat. proof wird nur für Einträge befüllt, die tatsächlich einen signierten Beleg haben – niemals für diejenigen erfunden, die keinen haben.

Drei weitere aus dem Re-Scan vom August 2026 (AP2 v0.2.0, x402 v2 Bazaar)

Zwei Protokollbewegungen seit der letzten Runde haben verändert, was eine Governance-Schicht abdecken muss, und beide öffnen eine Lücke, die ein Pro-Call-Ausgabenlimit strukturell nicht sehen kann.

• AP2-Mandatsketten – ist der Warenkorb noch die Absicht? (server/ap2.js, POST /api/ap2/mandate-chain) – AP2 modelliert einen Kauf als Kette: ein Intent-Mandat, das der Mensch signiert, dann ein Warenkorb-Mandat, das der Agent zusammenstellt. /api/ap2/evaluate beurteilt einen Betrag, kann also den Fehler nicht erkennen, den die Kette aufdecken soll – einen Warenkorb, der bequem im Budget liegt und dennoch nicht autorisiert ist. Dies prüft den Warenkorb gegen das Intent, von dem er behauptet, zu stammen: Gesamtsumme über der Obergrenze des Intents (cart_exceeds_intent), eine deklarierte Gesamtsumme, die ihren eigenen Positionen widerspricht (cart_total_mismatch – geprüft vor jedem Cap, da eine Summe, die der Warenkorb nicht rechtfertigen kann, nicht die Zahl ist, gegen die ein Cap geprüft werden sollte), ein Händler oder eine Kategorie, die das Intent nie autorisiert hat (merchant_drift / category_drift), eine Autorisierung, die auf mehr Verkäufer verteilt wird, als das Intent erlaubt (multi_merchant_spray – eine dokumentierte Signatur für Agenten-Kompromittierung), ein abgelaufenes Intent und ein Warenkorb, der mit einem Intent präsentiert wird, von dem er nicht abgeleitet wurde. Deterministisch und lokal; kein Modell beurteilt die Abweichung. Urteile sind ECDSA-signiert wie jede andere Entscheidung.

• Autorität ohne anwesenden Menschen (gleicher Endpunkt) – AP2 v0.2.0 hat Abläufe formalisiert, in denen der Agent ohne verfügbaren Menschen kauft. In diesen ist „Pause für Genehmigung" keine Pause, sondern eine unbeantwortbare Frage, und sie als solche zu behandeln, hängt entweder den Ablauf auf oder winkt ihn still durch. SpendVetos Regel: Das signierte Intent-Mandat ist die Vorabautorisierung des Menschen, also läuft der Anruf innerhalb seiner angegebenen Obergrenze fort (preAuthorizedByIntent: true, und das Urteil sagt das); darüber hinaus – oder wenn das Intent keine Obergrenze nennt – gibt es keine Autorität und niemanden, den man fragen könnte, also schlägt es fehl (hnp_no_authority). Nie wird eine Über-Intent-Ausgabe stillschweigend zu einer Erlaubnis aufgewertet.

• Governed Bazaar-Discovery (server/discovery.js) – Die Bazaar-Schicht von x402 v2 ermöglicht einem Agenten, einen Dienst zu entdecken und zu bezahlen, von dem er nie gehört hat, ohne vorgefertigte Integration. Das ist der Punkt, und es ist auch das Problem: Eine Payee-Allowlist, die beim Settlement konsultiert wird, erfährt vom gewählten Endpunkt eines prompt-injizierten Agenten viel zu spät, um zu helfen. GET /api/discovery/resources veröffentlicht SpendVetos eigenen Katalog im Bazaar-Schema (CAIP-2-Netzwerk, USDC-Basiseinheiten, als governed gekennzeichnet, damit ein Käufer weiß, dass der Preis eine Untergrenze ist). POST /api/discovery/govern läuft in die andere Richtung – es filtert einen entdeckten Katalog durch die Live-Richtlinie, bevor der Agent ihn sieht, sodass ein Dienst, den er nie bezahlen dürfte, nie in der Liste steht, aus der er wählt, wobei jede Entfernung die Regel benennt, die sie verursacht hat, und die geltende Richtlinienversion. Ein Vorfilter, der schrumpft, was ein kompromittierter Agent überhaupt benennen kann; was er auch immer wählt, durchläuft zur Anrufzeit weiterhin die volle Pipeline.

Vier weitere aus dem Konkurrenz-Tiefenscan vom August 2026 (Fireblocks/x402, ACP, Agent-Chargebacks, OTel)

Die Käuferseite wurde schnell voll: Fireblocks trat der x402 Foundation bei und trägt eine Sicherheitserweiterung für Anfrageintegrität und Ausgaben-Governance bei; AWS zeigte eine Vorschau auf Bedrock AgentCore Payments mit Ausgabenlimits; Cloudflare kündigte Account Wallets mit Ausgabenkontrollen an; eine CSA-Umfrage 2026 ergab, dass 65 % der Unternehmen mit Agenten in zwölf Monaten mindestens einen agentenbezogenen Vorfall hatten. Vier Lücken kamen aus diesem Scan, jede davon etwas, das ein Pro-Call-Cap strukturell nicht kann.

• Anfrageintegrität – „ist das die Ausgabe, die ich erlaubt habe?" (server/integrity.js, POST /api/integrity/bind → /api/integrity/verify) – jede Kontrolle hier beantwortet ist diese Ausgabe erlaubt. Keine beantwortete ist das die Ausgabe, die ich erlaubt habe. Die Richtlinie läuft auf einer beschriebenen Anfrage; etwas anderes führt aus. Dazwischen kann ein kompromittierter oder nur fehlerhafter Agent die Nutzlast ändern – gleicher Zahler, gleicher Preis, gleiche Genehmigung, anderer Händler oder andere Waren – und jede betragsbasierte Kontrolle besteht, weil sich der Betrag nie bewegt hat. Also: Die Anfrage kanonisch digerieren (rekursives sortiertes SHA-256, sodass die Schlüsselreihenfolge die Antwort nicht ändern kann), den Digest mit demselben Schlüssel signieren, der Belege und Urteile signiert, und bei der Ausführung ablehnen, wenn die Nutzlast nicht mehr übereinstimmt (request_integrity_mismatch). Bindungen sind Einmalnutzungen (binding_consumed – eine Autorisierung, die wiedergegeben werden kann, ist ein Gutschein, keine Bindung), TTL-begrenzt (binding_expired) und agentenbezogen (binding_agent_mismatch). Dies ist das Käuferseiten-Pendant zu dem, was Fireblocks zu x402 beiträgt.

• ACP Shared-Payment-Token-Umfang (server/acp.js, POST /api/acp/checkout) – Die Delegated Payments Spec von ACP gibt ein SPT aus: ein Inhaber-Credential, geprägt für einen Betrag, einen Händler und ein Zeitfenster, sodass ein Agent auschecken kann, ohne jemals die Karte des Käufers zu sehen. Der Händler validiert das Token. Niemand validiert den Einkauf – und ein Token, das auf 200 $ bei einem Händler beschränkt ist, wird bereitwillig 200 $ der falschen Waren abwickeln. Gleiche Form wie die AP2-Abweichung oben, also erhält es dieselbe Behandlung: spt_merchant_drift, session_exceeds_spt, spt_expired, spt_category_drift, session_total_mismatch (Arithmetik geprüft vor der Obergrenze, weil eine Summe, die die Positionen nicht rechtfertigen, nicht die Zahl ist, die gemessen werden sollte) und spt_currency_mismatch – SpendVeto weigert sich, eine Obergrenze in einer Währung mit einer Belastung in einer anderen zu vergleichen, anstatt einen Kurs zu raten. Eine erlaubte Sitzung bleibt an ihre eigenen Bytes gebunden; eine abgelehnte erhält keine Bindung.

• Streitfall-Beweispakete (server/disputes.js, GET /api/disputes/:entryHash/evidence) – Wenn ein Mensch eine Belastung anficht, verteidigt der Händler sie mit Geräte-Fingerabdruck, IP, Browsing-Sitzung, Lieferbestätigung. Ein Agentenkauf erzeugt nichts davon, also verlieren Agententransaktionen standardmäßig und der Händler zahlt. Visa TAP, Mastercard Agent Pay, AP2 und Amex' Agentenschutz beschreiben alle Autorisierung; keiner definiert bisher die nachträgliche Verteidigungsdatei. SpendVeto sitzt bereits darauf – nichts Neues wird erfasst. Ein Paket setzt den Ledger-Eintrag zusammen, der zwischen seinen Nachbar-Hashes gepinnt ist (das Anti-Rückdatierungs-Argument), den geltenden Richtlinien-Hash mit etwaiger Abweichung seitdem, offengelegt statt versteckt, den menschlichen Genehmigungsdatensatz und die signierten Einwilligungen für die Delegation, unter der der Zahler ausgegeben hat – dann signiert es das Bündel über seinen eigenen Digest, sodass ein unterwegs bearbeitetes Paket aufhört zu verifizieren (pack_tampered). Jedes Paket trägt eine doesNotEstablish-Liste innerhalb des Artefakts: Es impliziert nie Lieferung, Zufriedenheit oder dass die Richtlinie eine gute war – nur dass sie in Kraft war und angewendet wurde.

• OpenTelemetry-Entscheidungsspannen (server/otel.js, GET /api/otel/spans) – Agententeams verfolgen bereits Prompts, Tool-Aufrufe und Sub-Agenten, und die Anforderung, die in Agent-Governance-Bewertungen immer wieder auftaucht, ist OTel-native Sichtbarkeit: Die Ausgabenentscheidung muss als Span innerhalb der Trace, die sie verursacht hat, erscheinen, nicht in einem zweiten System, das jemand um 3 Uhr morgens per Zeitstempel korreliert. OTLP/HTTP ist JSON über POST, also ist dies dependency-frei – das OpenTelemetry-SDK in die eine Komponente zu ziehen, deren Aufgabe es ist, sich zu weigern, Dingen zu vertrauen, würde eine Supply-Chain-Oberfläche ohne Gewinn hinzufügen. Übergeben Sie ein W3C-traceparent und die Ablehnung landet unter dem Agentenlauf, der ausgeben wollte; Span-IDs leiten sich vom Eintrags-Hash ab, sodass Re-Export keine doppelten Spans im Backend erzeugt; ein fehlerhafter Header degradiert zu einer eigenständigen Trace, anstatt die Entscheidungsoberfläche zu brechen. Eine blockierte Ausgabe ist Status OK, nicht ERROR – das Tor hat seine Arbeit getan, und Ablehnungen rot zu färben trainiert ein Team darauf, die Farbe zu ignorieren, die zählt.

Marktplatz + Zulagen: das zweiseitige Schwungrad

Jeder kann ein kostenpflichtiges Tool hinter dem Tor listen – der Katalog ist Angebot, keine feste Demo:

curl -X POST localhost:8402/api/catalog/tools -H 'Content-Type: application/json' \
  -d '{"id":"haiku","price":0.008,"label":"Haiku writer","upstreamUrl":"https://your-api.example/haiku"}'
npm run call -- haiku        # any agent pays it through the full governed pipeline

Registrierte Tools erhalten das identische 402-Tor (kettenspezifische Signaturen, Belege, Ledger); mit einer upstreamUrl wird der kostenpflichtige Aufruf weitergeleitet, ohne eine antwortet es mit einem vorgefertigten Body. Verkäufer listen, Käufer verwalten – beide Seiten des agentischen Handels in einem Stack.

Budgets können Zulagen sein – Caps, die sich in einem rollierenden Fenster wieder auffüllen, statt für immer auszulaufen:

npm run delegate -- 5 "shopping agent" --every 7d    # $5 a week, self-refilling

Ausgaben innerhalb des Fensters zählen gegen das Limit; wenn sie auslaufen, füllt sich das Budget von selbst wieder auf (getestet mit einem 2-Sekunden-Fenster: Ausgabe → blockiert → automatische Auffüllung → gibt wieder aus). Das ist das „wöchentliches Taschengeld für deinen Agenten“-Primitiv — für Teams heute, für Verbraucher-Agenten morgen.

Simulierte Aufladungen: POST /api/balances/topup {address, chain, amount} lädt ein Guthaben pro Chain im Simulate-Modus auf (und nur dort — On-Chain-Guthaben stammen von echten Faucets, niemals von einer API).

Die API-Spend-Schiene: die Ausgaben regeln, die Agenten bereits verbrennen

Crypto ist Schiene Nr. 1, weil sie lokal verifizierbar war — aber dieselbe Pipeline regelt LLM/API-Ausgaben, wo jedes Agententeam heute Geld verliert:

curl -X POST localhost:8404/proxy/llm -H 'Content-Type: application/json' \
  -d '{"prompt":"summarize x402 in one line","maxTokens":200}'
  -d '{"prompt":"…","maxTokens":20000}'          # big estimate → pauses for human approval, FAILS CLOSED
  -d '{"prompt":"…","child":"intern"}'            # delegated budgets bind token spend too

Auth/Capture, wie bei echten Ausgabenplattformen: Die Worst-Case-Kosten werden im Voraus geschätzt (LLM_RATE_IN_PER_M / LLM_RATE_OUT_PER_M, USD pro Million Tokens — aus dem Preissheet deines Anbieters), die gesamte Pipeline läuft gegen die Schätzung (Freeze → Policy → kaskadierende Budgets → Genehmigung), der Upstream-Aufruf erfolgt nur, wenn er besteht, und die tatsächlichen gemessenen Kosten landen im selben Ledger — zusammengefasst als eigener api-Bucket neben den Chains. Mit gesetztem ANTHROPIC_API_KEY ist die Completion real; ohne ihn ist die Completion simuliert, aber Governance und Messung sind es nicht. Die Tokens eines Agenten, API-Aufrufe und USDC gehorchen einer einzigen Policy-Engine.

Multi-Chain: Chain-bewusste Governance, kein Logo-Streifen

Sieben Chains sind in shared-config.js registriert (jede mit ihrem kanonischen USDC-Vertrag und einem RPC), verfügbar unter /api/chains. Die Chain ist eine governed Dimension jeder Zahlung, Ende zu Ende:

• Chain-gebundene Signaturen — die Chain reist in der signierten Zahlungsnachricht mit, sodass eine für Polygon erstellte Autorisierung niemals gegen das Guthaben einer anderen Chain abgerechnet werden kann (getestet: eine für Polygon signierte Autorisierung wird auf Arbitrum abgelehnt).

• Guthaben pro Chain — jedes (wallet, chain)-Paar hat sein eigenes simuliertes USDC-Guthaben; eine Zahlung auf Polygon belastet nur Polygon.

• Chain-Allowlists — "allowedChains": ["base-sepolia", "base"] in data/policy.json blockiert Agenten daran, sich anderswo abzurechnen; die cautious- und production-Packs werden mit festgelegten Chains ausgeliefert.

• Chain-gebundene Delegation — --chains base-sepolia pinnt die Abrechnungs-Chains eines Kindes fest, und (wie Caps und Tool-Scopes) bindet der Chain-Scope jedes Vorfahren den gesamten Teilbaum.

• Überall — npm run call -- review --chain=polygon, Proxy-Intents ({"tool":"review","chain":"arbitrum"}), pro-Chain-Rollups unter /api/analytics, eine Chain-Spalte im CSV-Export, Chain-Tags im Dashboard-Ledger.

• Facilitator-adaptive Live-Abrechnung — im Testnet-Modus fragt das Gate beim Booten seinen konfigurierten Facilitator, was es abwickeln kann (GET /supported), und bringt jede registrierte Chain, die der Facilitator nennt, live: pro-Chain-Schema-Registrierung und ein Accepts-Eintrag pro Chain in jedem 402, bepreist als explizite atomare USDC-Beträge gegen den kanonischen Vertrag jeder Chain. Getestet gegen einen Mock-Facilitator in beide Richtungen: Werbung für alle sieben bringt alle sieben live; Werbung für eine bringt genau eine, wobei der Rest settlement: "ready" auf /api/chains meldet. Der öffentliche Facilitator wickelt heute Base Sepolia ab; wenn du SPENDVETO_FACILITATOR_URL auf einen CDP-Facilitator (mit API-Key) zeigst und eine Wallet finanzierst, schaltet das seine Mainnet-Chains mit null Codeänderungen live — die verbleibende Lücke zu echtem Mainnet-Spend ist ein Key, Guthaben und ein Sicherheitsaudit, keine Engineering-Arbeit.

On-Chain-Settlement ist heute live auf Base Sepolia über x402; jede registrierte Chain läuft die gesamte Pipeline im Simulate-Modus (echte Chain-gebundene Signaturen, lokales Settlement). Pro-Chain-Facilitator-Adapter sind das finanzierte Meilenstein — die Governance-Ebene ist bereits Chain-vollständig.

Evidenz-Oberflächen: SIEM-Events, Policy-Versionierung, signierte Verdicts, Billing

Die Forschungsrunde vom Juli 2026 sagte es deutlich: Rails loggen Zahlungen; Unternehmen brauchen Evidenz der Entscheidungen davor. Vier Oberflächen (alle getestet):

• Entscheidungs-Events — GET /api/events formt das Hash-verketten Ledger in ein stabiles Schema um (spendveto.decision.v1): Agent, Entscheidung, Betrag, Zahlungsempfänger, Ablehnungsgrund, Receipt-ID, Policy-Version, Chain-of-Custody-Hashes. GET /api/events/export gibt JSON Lines aus — eine Entscheidung pro Zeile, direkt in Splunk/Datadog/Elastic/jq, ohne Envelope-Parsing.

• Policy-Versionierung — jede Gate-Entscheidung ist mit policyHash gestempelt, dem SHA-256 der zu diesem Zeitpunkt geltenden Policy. „Welche Policy hat diese Ausgabe erlaubt?“ ist allein aus dem Ledger beantwortbar, nach beliebig vielen Policy-Änderungen.

• AP2-artige Mandatsbewertung — POST /api/ap2/evaluate führt die vollständige Policy-Pipeline gegen ein AP2-förmiges Mandat (Agent, Betrag, Zahlungsempfänger, Ablauf) aus und gibt das Verdict ECDSA-signiert mit dem Receipt-Key des Servers zurück: portable Evidenz, die jeder verifizieren kann. Abgelaufene Mandate verweigern mit mandate_expired. AP2-Settlement bleibt ein ehrlicher Roadmap-Slot — das ist die Governance-Hälfte, heute real.

• Governed Billing — ein Settlement pusht ein spendveto.usage.v1-Event (per Receipt-ID) an policy.billingWebhookUrl, optional HMAC-signiert: SpendVeto erzwingt Vorauszahlung; Lago/Orb/Metronome-artige Plattformen stellen nach Nutzung in Rechnung. Arbeitsteilung, keine Billing-Engine.

Das Kontrollinventar in CONTROLS.md ordnet all das (und jede andere Kontrolle) den Laufzeit-Erwartungen des EU AI Act / NIST AI RMF zu — jede Zeile zitiert die Verify-Assertion, die sie ausübt. Eine Selbstbewertung, ausdrücklich keine Zertifizierung.

Trust-Scores & Policy-Packs

GET /api/trust/:address komprimiert die Governance-Historie einer Wallet in einen Score von 0–100 mit einer Buchstabennote — bezahlte Historie bringt Vertrauen; Blöcke, Fehler und Freezes verbrennen es (eine außer Kontrolle geratene Wallet bekommt F bei Score 0). Der Score skaliert jetzt auf zwei Arten (beide getestet): GET /api/trust/graph baut den Trust-Graph — jede Wallet ein bewerteter Knoten, jede Delegation eine Kante, jede Delegationswurzel eine „Org“ mit einem bezahlvolumen-gewichteten Score über ihren gesamten Unterbaum — und GET /api/trust/payee/:address ist das Gegenpartei-Büro: der Ruf eines Empfängers, aggregiert über jede Wallet, die ihn je bezahlt hat (oder daran gehindert wurde), einschließlich des durchschnittlichen Governance-Scores seiner Zahler. Immer noch aus dem Ledger einer einzigen Bereitstellung berechnet — die organisationsübergreifende Föderation dieser Graphen ist die Roadmap, die das sät.

Governance wird als Presets ausgeliefert: npm run policy listet die Packs (cautious / standard / production), npm run policy -- apply cautious wendet eines an (vorherige Policy wird in .bak gespeichert). Teams können ihre eigenen Packs committen.

Human-in-the-Loop-Genehmigung

Preise über requireApprovalAboveUSD (in data/policy.json) pausieren den Aufruf und posten ihn in die Genehmigungswarteschlange des Dashboards — Approve / Deny-Buttons, live. Drei Ergebnisse, alle mit Gründen im Ledger: genehmigt → zahlt; abgelehnt → beendet ohne zu zahlen; keine Entscheidung in 30s → schließt fehlgeschlagen (gibt nie ohne Freigabe aus).

Zwei Modi, beide real

Nichts ist vorgetäuscht, um real zu wirken — der Simulate-Modus verifiziert echte Signaturen und lehnt gefälschte ab (getestet); er wickelt nur lokal ab. Der Testnet-Modus ist die tatsächlichen @x402/express/@x402/fetch v2-Pakete gegen den live öffentlichen Facilitator, pro Tool bis zur Faucet-Finanzierungsgrenze bestätigt (Browser + Captcha — der einzige nicht automatisierbare Schritt).

Dateien

shared-config.js         tool catalog (id/path/price), 7-chain registry (USDC contracts, RPCs), mode, port
server/
  index.js                Express app: catalog, ledger, stats, analytics, CSV export, policy, approvals, delegations, freezes APIs
  simulate.js              per-tool 402 gate factory: real signature verify, replay protection, freeze refusal, signed receipts
  agent.js                 the paid tasks — one Claude call per tool, canned fallback without a key
  ledger.js                JSON ledger + simulated balances
  approvals.js              in-memory pending-approval store
  delegations.js            durable budget-grant store (caps + tool scopes)
  freezes.js                durable kill-switch store
  anomaly.js                runaway-burst detector → auto-freeze
  alerts.js                 fire-and-forget webhook alerts (Slack-ready)
  ap2.js                    AP2 mandate chains: cart-vs-intent drift + human-not-present authority
  discovery.js              x402 v2 Bazaar: publish the catalog, and policy-filter a discovered one
  acp.js                    ACP shared-payment-token scope: is the session the purchase the token funds?
  integrity.js              request binding: is this the spend I allowed? (canonical digest, single-use)
  disputes.js               signed dispute evidence packs — the agent-chargeback defence file
  otel.js                   OTLP decision spans; adopts an inbound W3C traceparent, blocked ≠ ERROR
client/
  wallet.js                parent keypair + delegated child wallets (pick by label)
  policy.js                the governance wedge: freezes, hard limits, approval threshold, cascading caps
  pay.js                   shared governed pipeline: policy → approval → pay → log
  pay-and-call.js           CLI wrapper (--child, --child=<label-or-address>)
rails/
  index.js                 rail registry: one pay() contract, x402 live, AP2/ACP/MPP as honest slots
  x402-simulate.js         zero-setup rail: real ECDSA, chain-scoped, local settlement
  x402-testnet.js          real on-chain rail: Base Sepolia via the public facilitator
mcp/
  server.js                MCP middleware: paid catalog + spendveto_status over stdio
proxy/
  server.js                enforcement proxy: key custody, agents POST intents (:8404)
dashboard/                the Console: 8 pages (overview, approvals, budgets, ledger, chains, analytics, trust, policy) with create/edit/freeze/apply controls
scripts/
  delegate.mjs              grant a capped budget (--parent for deeper levels, --tools for scope)
  gen-wallets.mjs           one-time testnet wallet generation
  policy.mjs                list/apply policy packs
  site.mjs                  serves the marketing site on :8403
  verify.mjs                264 end-to-end assertions incl. MCP stdio round trip + multichain + auto-freeze
data/
  policy.json               editable spend rules incl. anomaly burst threshold + alertWebhookUrl
  policy-packs/             importable governance presets (cautious/standard/production)
  ledger/balances/delegations/children/freezes.json   runtime state (gitignored)
site/                     deploy-ready landing page (Three.js hero, fully static)
PITCH.md                  funding pitch: TAM/SAM/SOM, competition, accelerator targets (all cited)
launch/                   Show HN draft, 90-second demo script, ecosystem-listing blurbs
RESEARCH_PROMPT.md        the deep-research prompt behind feature round 2

Roadmap (was Finanzierung kauft — siehe PITCH.md)

• Gehostetes Backend (Postgres) ersetzt JSON-Datei-Speicher; Orgs, SSO, Audit-Exporte

• Reichhaltigere Anomalie-Signale (Preisabweichung, neuer Händler, außerhalb der Geschäftszeiten) + Webhook/Slack-Alerts bei Freeze

• Multi-Rail-Adapter: Google AP2, Stripe MPP, Mastercard AP4M — die Policy-Ebene sollte egal sein, welche Rail abwickelt

• Mainnet-Settlement über den CDP-Facilitator (x402 v2-Migration: erledigt) — braucht eine finanzierte Wallet + CDP-API-Key

• Framework-Hooks: CrewAI-Middleware, tiefere Claude-Code-Integration; einen echten Sentient-SDLC-Pipeline-Schritt gaten (LangChain: erledigt, siehe integrations/langchain.js)

Preise: Self-Hosting ist für immer kostenlos (dieses Repo ist das ganze Produkt). Gehostete Launch-Tiers — Desk $49/Monat, Team $199/Monat + 0,5 % der governed API-Ausgaben, Money Path bei 10–25 Basispunkten auf governed Volumen — sind auf der Preisseite hinter der Warteliste.

Apache-2.0-lizenziert — siehe LICENSE.