Gemini Spark KI-Agent braucht eine Wallet, keine Karte
Google hat am 19. Mai 2026 Gemini Spark vorgestellt: einen rund um die Uhr aktiven agentischen Assistenten, der deine Gmail-E-Mails liest, Antworten entwirft, Termine bucht und weiterarbeitet, auch wenn du den Laptop zugeklappt hast. Das Versprechen: ein dauerhaft aktiver agentischer Assistent, der die langweilige Hälfte deines Posteingangs erledigt, während du schläfst.
Unter den Gmail-Demos verbirgt sich ein Problem, das auf der Bühne niemand laut aussprechen wollte. In dem Moment, in dem ein Agent ohne deine aktive Anwesenheit handelt, brechen alle Annahmen zusammen, die Kartenzahlungen zugrunde liegen. Kein Mensch, der auf "Bestätigen" tippt. Kein Telefon, das den 3-D-Secure-Code empfängt. Keine Karte vorhanden, kein Karteninhaber anwesend, keine Sitzung.
Ich glaube, das ist die eigentliche Geschichte des Gemini-3.5-Launches, und sie hat fast nichts mit E-Mail zu tun.
Warum ein dauerhaft aktiver agentischer Assistent deine Karte nicht nutzen kann
Kartensysteme setzen einen Menschen voraus. Der gesamte Anti-Betrugs-Stack, CVV, 3-D Secure, der kleine SMS-Code, die Frequenzprüfungen, existiert, um zu bestätigen, dass ein Mensch hinter der Transaktion steckt. Spark ist das genaue Gegenteil davon. Es ist ein Prozess in Googles Cloud, der um 3 Uhr morgens aufwacht, um einen stornierten Flug umzubuchen.
Wenn man einen autonomen Agenten auf Visas Kartensystem loslässt, stößt man schnell gegen eine Wand:
- Transaktionen ohne Kartenpräsenz von einer Rechenzentrum-IP werden markiert oder abgelehnt.
- 3-D-Secure-Abfragen gehen an einen Menschen, der schläft.
- Die Haftung für Rückbuchungen liegt beim Händler für einen Kauf, den kein Mensch autorisiert hat.
- Es gibt keine saubere Möglichkeit, einem Agenten ein tägliches Ausgabelimit von 40 Dollar zu geben, das sich täglich zurücksetzt und nicht leergeräumt werden kann.
Googles eigene AI-Ultra-Positionierung setzt genau deshalb auf Abo-Bündelung, weil Zahlungen pro Aktion ungelöst sind. Du zahlst Google eine monatliche Pauschale, Google trägt die Kosten des Agenten, und niemand muss herausfinden, wie der Agent einen Dritten bezahlt. Das funktioniert, solange der Agent nichts außerhalb von Googles eigenem Ökosystem kaufen muss.
Die Nachfrageseite ist endlich aufgetaucht
Zwei Jahre lang haben die Akteure im Bereich Agentenzahlungen Schienen für einen Kunden gebaut, den es noch nicht gab. Ich habe über diese Lücke in AI Agent Payments: Anvita, x402, and Who Owns the Rail geschrieben, die Technik war bereit, die autonomen Käufer nicht.
Spark verändert die Ausgangslage. Google wird demnächst Dutzende Millionen dauerhaft aktiver Agenten ausliefern, die früher oder später Transaktionen durchführen müssen. Das ist die Nachfrage, auf die die Schienen gewartet haben.
Der entstandene Stack ist auf die richtige Art unspektakulär:
- x402 reaktiviert den schlummernden HTTP-Statuscode 402 "Payment Required", damit ein Server einen Preis nennen und ein Agent ihn inline, in Stablecoins, innerhalb einer einzigen Anfrage bezahlen kann.
- AWS AgentCore hat einen Zahlungspfad hinzugefügt, damit Agenten in Amazons Cloud abrechnen können, ohne dass ein Mensch jede Zahlung genehmigen muss.
- Pay.sh und ähnliche Tools verpacken USDC-on-Base so, dass ein Agent es wie jede andere API aufrufen kann.
Der gemeinsame Nenner: USDC on Base. Günstige Finalität, Gebühren unter einem Cent und ein Stablecoin, den eine Unternehmenskasse tatsächlich halten kann, ohne dass die Compliance-Abteilung eine einstweilige Verfügung einreicht.
Warum USDC on Base, konkret
Agentenzahlungen sind Mikrozahlungen. Ein Agent zahlt vielleicht 0,003 Dollar für eine Wetter-API-Abfrage oder 2 Dollar für einen Datensatz. Ethereum-Mainnet-Gas würde die Zahlung selbst übersteigen. Base hat in diesem Zyklus täglich über 1 Mrd. Dollar DEX-Volumen abgewickelt, und seine Gebühren liegen im Bruchteil eines Cents, was das einzige Gebührenregime ist, bei dem maschinengeschwindige Mikrozahlungen Sinn ergeben.
Stablecoins sind wichtiger als die Chain. Ein Agent kann keinen volatilen Vermögenswert halten; eine Preisschwankung von 4 % zwischen Autorisierung und Abwicklung einer Zahlung ist inakzeptabel. USDC ist auf Dollar denominiert, einlösbar und von einer regulierten Einheit ausgegeben. Nachdem das GENIUS Act AML-Regelwerk Stablecoin-Emittenten in ein bankähnliches Aufsichtsregime gezogen hat, kann ein CFO USDC in einer Weise billigen, die bei einem ungedeckten Token nie möglich gewesen wäre.
Diese regulatorische Klarheit ist der Schlüssel, nicht der Durchsatz. Ich habe erlebt, wie institutionelle Deals genau an dieser Frage gescheitert sind: "Wer haftet, und ist der Emittent beaufsichtigt?"
Das Schwierige sind nicht die Zahlungen. Es ist die Autorität.
Einem Agenten eine Wallet zu geben, ist die einfachen 20 %. Die anderen 80 % sind Governance:
- Ausgabelimits, die halten. Eine Agenten-Wallet braucht eine harte Obergrenze, die on-chain durchgesetzt wird, kein weiches Limit im Anwendungscode, das sich durch eine Prompt-Injection umgehen lässt.
- Widerrufliche Delegation. Du autorisierst den Agenten für Lebensmittelbestellungen, nicht dafür, deine Ersparnisse zu verschieben. Diese Abgrenzung muss kryptografisch sein, nicht ein Häkchen in einer Checkbox.
- Nachvollziehbarkeit. Jede Agentenzahlung muss auf eine Richtlinie zurückführbar sein, die ein Mensch festgelegt hat. "Die KI hat entschieden" ist keine Antwort, die ein Regulierer akzeptiert.
Hier wird das Prompt-Injection-Risiko real. Wir haben bereits gesehen, was ein einziger gestohlener Schlüssel anrichten kann, siehe den Polymarket-Exploit. Stell dir jetzt vor, dass dieser Schlüssel in einem Agenten liegt, der den ganzen Tag nicht vertrauenswürdige E-Mails liest und Geld ausgeben kann. Die Angriffsfläche ist der gesamte Posteingang.
Was ich als Nächstes beobachten würde
Google wird USDC nicht dieses Jahr in Spark integrieren. Die erste Version wird alles über Google Pay und Googles eigene Abrechnung abwickeln, weil das kontrollierbar ist und weil Google lieber die Schiene besitzt, als sie zu mieten.
Aber der Agent, der um 3 Uhr morgens deinen Flug bucht, wird irgendwann einen Anbieter bezahlen wollen, mit dem Google keine Abrechnungsbeziehung hat. Wenn das passiert, ist der günstigste Weg eine Stablecoin-Zahlung über ein offenes Protokoll, keine maßgeschneiderte Kartenintegration pro Händler. Die Schiene, die gewinnt, ist die, die ein Agent nutzen kann, ohne bei einem Zahlungsgiganten um Erlaubnis zu fragen.
Die Wallet kommt für den Agenten. Die einzige offene Frage ist, ob es ein geschlossenes Ledger innerhalb von Google oder ein offenes ist, gegen das jeder entwickeln kann. Meine Wette gilt dem offenen, aus demselben Grund, aus dem das Web AOL besiegt hat.