Loop bekommt einen Reisepass und eine Geldbörse: Loop Engineering trifft auf das metrische Web

Dieser Blog hat Loop-Engineering bereits zweimal als nach innen gerichtete Disziplin behandelt: unser erster Beitrag zum Loop-Engineering argumentierte, dass der sich selbst fortsetzende Loop in eine kontrollierte Laufzeitumgebung gehört, und unser Beitrag zur Fleet-Runtime weitete dieses Argument von einem Loop auf viele aus. Ein damit verbundenes Problem nach außen hin wurde zwischen Ende 2025 und Mitte 2026 konkreter. Im Oktober 2025 gründete die IETF die Arbeitsgruppe Web Bot Auth, um kryptografische Authentifizierungsmethoden für automatisierte Clients zu entwickeln, die auf primär für Menschen konzipierte Websites zugreifen (aktueller Protokollentwurf; Arbeitsgruppen- Gründungsbekanntmachung, genehmigte Charta). Am 2. April 2026 startete die Linux Foundation die x402 Foundation, um das offene x402-Protokoll für HTTP-native Zahlungen zu verwalten – als „ein offenes, von der Community gesteuertes Zuhause“ für das Protokoll, wie es Jim Zemlin, CEO der Linux Foundation, beim Start formulierte (linuxfoundation.org). Und am 1. Juli 2026 eröffnete Cloudflare die Warteliste für sein angekündigtes Monetization Gateway – das Kunden ermöglichen soll, jeden Aufrufer, explizit einschließlich KI-Agenten, für Seiten, Datensätze, APIs oder MCP-Tools hinter seinem Netzwerk zur Kasse zu bitten, abgewickelt über x402 – mit der klaren Aussage, dass „Agenten für die benötigten Inputs bezahlen sollten“ (blog.cloudflare.com). Zusammengenommen – und diese Zusammenschau ist die redaktionelle Synthese dieses Beitrags – beginnen einige Ursprünge und Dienste, automatisierten Clients explizite Identitäts- oder Zahlungsbedingungen aufzuerlegen: weisen Sie sich aus, und zahlen Sie nach VerbrauchAgent-Schleifen, die planen, agieren, verifizieren und fortfahren, stoßen an ihren ausgehenden Schnittstellen zunehmend auf solche Schranken und Zähler. Das verleiht dem Loop-Engineering eine dritte Disziplin, neben der Laufzeit innerhalb der Schleife und der Flotte um sie herum: Egress – die kontrollierte Verwaltung der Identität, der Ausgaben und des Verhaltens einer Schleife in Netzwerken, die das Unternehmen nicht selbst kontrolliert.

Amara, eine Plattform-Ingenieurin in einem forschungsintensiven Unternehmen, bemerkte das Problem in der Lücke zwischen zwei Protokollen. Die Competitive-Intelligence-Schleife ihres Teams – ein geplanter Agent, der eine Forschungsfrage entwirft, Quellen abruft, Behauptungen anhand dieser verifiziert und so lange fortfährt, bis seine Checkliste abgearbeitet ist – hatte begonnen, selbstbewusste Zusammenfassungen mit seltsam dünnen Quellenverzeichnissen zu liefern. Die Trace-Daten des Agenten selbst zeigten keine Fehler: Er plante, er rief ab, er schrieb. Das Egress-Protokoll erzählte die andere Hälfte der Geschichte: Ein wachsender Teil der Abrufe kehrte mit einem 403-Fehler von Websites zurück, die ihre Bot-Richtlinien verschärft hatten, und einige wenige kamen mit einem 402-Fehler von der neu mit einer Gebühr belegten API eines Partners zurück – ein Statuscode, den ihre Wiederholungslogik als vorübergehend einstufte. Die Schleife hatte also höflich elfmal dieselbe kostenpflichtige Ressource angefragt, bevor sie aufgab und die Lücke einfach ignorierte. Nichts stürzte ab. Nichts löste einen Alarm aus. Die Schleife wurde einfach stiller, verbrauchte durch ihre Wiederholungsversuche zusätzliche Modell- und Orchestrierungsressourcen und lieferte Ergebnisse, die weniger vollständig und weniger gut belegt waren. Amaras einzeilige Zusammenfassung des Vorfalls ist die These dieses Beitrags: das Innere der Schleife war kontrolliert; das Äußere nicht. (Amara ist eine illustrative Kunstfigur; es geht um die Fehlermodi.)

1. Die veraltete Wende: Das Web stellt Bedingungen

Die einzelnen Entwicklungen haben jeweils ihren eigenen Geltungsbereich und jede ist es wert, präzise benannt zu werden. x402 erhielt ein neutrales Governance-Zuhause. Am 2. April 2026 startete die Linux Foundation die x402 Foundation – das Leitungsgremium für das x402-Protokoll, das ursprünglich von Coinbase, Cloudflare und Stripe entwickelt wurde, wobei Google, Visa, Microsoft und etwa zwanzig weitere Technologie- und Zahlungsunternehmen ihre anfängliche Unterstützung bekundeten (linuxfoundation.org). Der Mechanismus des Protokolls belebt den lange ruhenden HTTP-Statuscode 402 wieder: Ein Client fordert eine zahlungspflichtige Ressource an; der Server antwortet mit einem Preis und Zahlungsanweisungen; der Client zahlt und wiederholt die Anfrage mit beigefügtem Nachweis. Die nutzungsabhängige Abrechnung entwickelte sich vom Experiment zum Produkt. Cloudflares „Pay Per Crawl“ startete im Juli 2025 als privates Beta-Experiment, um KI-Crawler für Inhalte zur Kasse zu bitten (blog.cloudflare.com); am 1. Juli 2026 öffnete das Unternehmen die Warteliste für sein angekündigtes Monetization Gateway, das die anfragebasierte Preisgestaltung von Crawlern auf jeden Aufrufer und von Seiten auf Datensätze, APIs und – was für diese Serie besonders wichtig ist – MCP-Tools ausweiten soll (Ankündigung). Cloudflare gibt an, dass Websites in seinem Netzwerk täglich mehr als eine Milliarde HTTP-402-Antworten an Bots und Crawler senden, die versuchen, auf Inhalte und kommerzielle Angebote zuzugreifen (blog.cloudflare.com). Dabei handelt es sich um zahlungspflichtige Antworten, nicht um abgeschlossene Transaktionen. Unabhängig davon kündigte Cloudflare an, dass ab dem 15. September 2026 bei neu hinzugefügten Domains die Kategorien „Training“ und „Agent“ auf Seiten mit Werbeeinblendungen standardmäßig blockiert werden, während die Suche weiterhin standardmäßig erlaubt bleibt und Kunden die Konfiguration anpassen können (blog.cloudflare.com). Zudem wurde Web Bot Auth in einen IETF-Standardisierungsprozess aufgenommen. Web Bot Auth – Cloudflares Vorschlag aus dem Jahr 2025, wonach Bots und Agenten Anfragen kryptografisch signieren sollen – führte im Oktober 2025 zur Gründung einer IETF-Arbeitsgruppe. Ein Entwurf für ein „Signature Agent Card“-Verzeichnis wurde erstmals 2025 veröffentlicht und im Mai sowie Juni 2026 unter Beteiligung eines Co-Autors von Amazon überarbeitet. Zudem gibt es laut den Entwürfen und der Berichterstattung in Abschnitt 2 erste produktive Signaturverfahren von großen KI-Anbietern. Keiner dieser Schritte allein verändert das Web. Zusammen beschreiben sie jedoch Ursprünge und Dienste, die damit begonnen haben, bestimmte Kategorien von maschinellem Datenverkehr mit expliziteren Zugangs- und Zahlungsrichtlinien zu verknüpfen – unter den Bedingungen: wer bist du und wer bezahlt?

Ein Hinweis zum Geltungsbereich, der sich durch diesen Beitrag zieht: Die beiden Ansätze bilden kein einheitliches System. Gemäß seiner IETF-Charta befasst sich Web Bot Auth mit der kryptografischen Identifizierung automatisierter Clients, die auf vorwiegend für Menschen bestimmte Websites zugreifen – es schließt HTTP-APIs, Agent-zu-Agent-Schnittstellen sowie die Identifizierung des Endnutzers hinter einem Agenten explizit aus. Unabhängig davon werden Zahlungssysteme nach dem x402-Prinzip auf ein breiteres Spektrum von HTTP-adressierbaren Ressourcen angewendet, darunter Seiten, Datensätze, APIs und MCP-Tools. Dieser Beitrag wertet beides als Indiz dafür, dass der Loop-Egress zunehmend auf explizite Identitäts- oder Zahlungsrichtlinien stoßen könnte, erkennt jedoch an, dass beide Bemühungen unterschiedliche Schwerpunkte haben.

2. Der Reisepass: Web Bot Auth und der identifizierte Loop

Dreißig Jahre lang wurde die Frage „Welcher Bot ist das?“ durch einen User-Agent-String beantwortet, den jeder eingeben konnte, und einen IP-Bereich, den sich jeder ausleihen konnte. Web Bot Auth ergänzt diese Mutmaßungen um kryptografische Nachweise: Nach dem aktuellen Protokollentwurf signiert ein automatisierter Client jede Anfrage mit einem privaten Schlüssel (HTTP Message Signatures, RFC 9421), kündigt sich über einen Signature-Agent-Header an und veröffentlicht seine öffentlichen Schlüssel in einem bekannten Verzeichnis (key-directory draft), sodass jeder Ursprung die Signatur unabhängig verifizieren kann (current protocol draft; Referenzimplementierung unter github.com/cloudflare/web-bot-auth). Die dazugehörige Infrastruktur reifte im Zeitraum 2025–2026: Cloudflare integrierte Nachrichtensignaturen im Juli 2025 in sein „Verified Bots“-Programm (blog.cloudflare.com) und startete im August desselben Jahres einen Track für signierte Agenten (blog.cloudflare.com), und ein Entwurf für ein Signature Agent Card-Register – das die Identität eines Agenten, den Betreiber, die erwarteten Anfrageraten und Schlüssel enthält – wurde erstmals 2025 veröffentlicht und im Mai sowie Juni 2026 überarbeitet, wobei ein Amazon-Co-Autor zu den Cloudflare-Autoren stieß; es bleibt ein sich entwickelnder Internet-Draft (aktueller Entwurf). Die Einführung ist noch früh und ungleichmäßig – Cloudflare gibt an, dass der ChatGPT-Agent von OpenAI Anfragen mittels Web Bot Auth signiert (Quelle), Amazon bietet Signaturunterstützung in einer AgentCore Browser-Vorschau an (AWS-Dokumentation) und Vercel unterstützt die Verifizierung von Web Bot Auth-Datenverkehr (Vercel-Changelog) – es handelt sich um Implementierungen, nicht um eine flächendeckende Abdeckung; die Richtung ist wichtiger als die Bestandsaufnahme: Ursprünge erhalten eine zuverlässige Möglichkeit, die von ihnen gewählten Agenten zuzulassen und den Rest abzuweisen. Für eine Schleife ist die Auswirkung struktureller Natur. Wenn ein Agent oder eine Orchestrierungsebene Zugriffsfehler verschluckt, schlägt eine Schleife ohne vorzeigbare Identität im geschützten Web möglicherweise nicht lautstark fehl; unsignierte oder abgelehnte Anfragen können zu einer unvollständigen Beschaffung führen, anstatt zu einem sichtbaren, endgültigen Fehler. Dies verlagert den Schaden genau dorthin, wo die Branche bereits eine messbare Schwachstelle hat: die Verifizierung. Eine identifizierte Schleife hingegen ist eine Schleife, die das Web bedienen kann – sie trägt nicht nur eine Signatur, sondern eine verantwortliche Herkunft: kryptografische Nachweise darüber, welcher signierende Client mit welchem Betreiber verknüpft ist. Die Endbenutzerautorität bleibt eine separate Unternehmensidentität und Delegationskontrolle, die außerhalb des Aufgabenbereichs von Web Bot Auth liegt.

3. Das Wallet: HTTP 402 und die neue Entscheidung der Schleife

Die Zahlungsseite verändert den Kontrollfluss der Schleife grundlegender, da sie direkt in den elementarsten Reflex der Schleife eingreift: den Wiederholungsversuch. In einem x402-fähigen Austausch kann eine 402-Antwort als strukturierte Zahlungsaufforderung fungieren und nicht als gewöhnlicher Fehler. MPP definiert einen verwandten, aber eigenständigen Ablauf – ein Dienst gibt eine Zahlungsaufforderung zurück und der Agent autorisiert die Zahlung, bevor er die Ressource erhält; die öffentliche Beschreibung von Stripe charakterisiert diesen Ablauf nicht als HTTP 402-basiert. Bei x402 nennt der Server einen Preis und Zahlungsdetails; der Client entscheidet, ob er zahlen möchte, und wiederholt nach der Autorisierung die Anfrage mit dem Zahlungsnachweis. Integriert man dies in eine sich selbst fortsetzende Schleife, ergeben sich daraus mehrere Konsequenzen. Der Preis wird zu einem Signal auf Schritt-Ebene. Wenn eine Schleife auf Kosten stößt, muss sie möglicherweise mitten im Prozess abwägen, ob ein bestimmter Abruf, ein API-Aufruf oder ein MCP-Tool-Aufruf den Preis im Verhältnis zum verbleibenden Budget der Aufgabe wert ist – eine Entscheidung, die bisher nur zum Zeitpunkt der Rechnungsstellung existierte, wenn überhaupt. Die Fehlermodi kehren sich um. Amaras elf höfliche Wiederholungsversuche bei einem kostenpflichtigen Endpunkt veranschaulichen die harmlose Variante; die teure Variante tritt ein, wenn eine automatische Zahlungsrichtlinie wiederholte oder unterschiedliche Anfragen ohne ausreichende Idempotenz, Deduplizierung oder Budgetprüfungen autorisiert – ein Client, der lediglich eine unbezahlte 402-Anfrage wiederholt, verschwendet Aufrufe, ohne etwas zu kaufen, aber eine Richtlinie, die jedes neue Angebot erneut autorisiert, vervielfacht die Ausgaben. Das ist die Fan-out-Ökonomie, die unser Flotten-Beitrag untersuchte, nun mit einem Zähler an jedem Zweig. Caching wird zur Einkaufsstrategie. Das erneute Kaufen dessen, was das Unternehmen bereits gekauft hat, ist das neue erneute Berechnen dessen, was es bereits berechnet hat; eine bezahlte Antwort ist ein Vermögenswert, den es sich zu merken lohnt – sofern Frische, Lizenzierung, Datenschutz und Autorisierungsbeschränkungen dies zulassen. Und Belege werden Teil der operativen Rechenschaftspflicht. Wenn ein Zahlungsdatensatz kryptografisch und operativ an die Anfrage und die Identität des Aufrufers gebunden ist, kann er als Audit-Trail dienen, der die angeforderte Ressource, den autorisierten Betrag sowie den Status des Abrechnungsversuchs oder -abschlusses aufzeigt. Er beweist für sich genommen jedoch weder eine erfolgreiche Zustellung noch die Qualität der Quelle oder die Korrektheit des Ergebnisses. Dieser Datensatz gehört in denselben Trace pro Schritt wie die zugehörigen Tool-Aufrufe – sowohl für die Finanzbuchhaltung als auch für die Kosten- und Zugriffsprotokolle, die für die operative Verantwortlichkeit erforderlich sind. Nichts davon setzt voraus, dass man sich auf ein bestimmtes Abrechnungsmodell festlegen muss. Es erfordert lediglich die Erkenntnis, dass die ausgehende Kante einer Schleife Transaktionssemantik annehmen kann und dass Transaktionssemantik ohne Governance der Grund dafür ist, warum aus Pilotprojekten Rechnungen werden.

4. Egress: Die dritte Disziplin des Loop-Engineerings

In unserem ersten Beitrag zum Thema „Loop“ argumentierten wir, dass ein Loop zu einer Laufzeitumgebung gehört – mit Sandbox, Anmeldedaten, Gates und Protokollen. In unserem Beitrag über „Fleet“ führten wir aus, dass diese Laufzeitumgebung auf viele Loops skalieren muss, ohne die Kontrollmechanismen zu vervielfachen. Beide Ansätze sind nach innen gerichtet. Das „Metered Web“ fügt dem eine nach außen gerichtete Komponente hinzu, die kohärent genug ist, um sie als eigene Disziplin zu bezeichnen – wobei wir dies, wie auch unsere Frameworks, als redaktionelle Synthese und nicht als feststehende Lehrmeinung verstehen. Egress-Engineering ist die gesteuerte Verwaltung aller Aktivitäten eines Loops außerhalb der Unternehmensgrenzen, wobei die Komponenten in befriedigender Symmetrie die internen Prozesse widerspiegeln. Identität: der Loop weist aus, wer er ist – durch signierte Anfragen, sofern das System dies unterstützt, aber grundlegender durch eine Identität, die pro Agent vermittelt wird, mit einer Delegierung pro Benutzer im Hintergrund, sodass die Frage „Wer hat das getan?“ eine fundiertere Antwort erhält als nur einen Schlüssel. Richtlinien: was der Loop kaufen darf, von wem und bis zu welcher Obergrenze – das Gegenstück zur Allowlist für Tools im ausgehenden Datenverkehr. Durchsetzung: Ausgaben werden direkt im Anfragepfad begrenzt, statt sie erst nach Monatsabschluss abzugleichen – mit Warnmodi für die Erkennung, strikten Modi für die Produktion und Schwellenwerten, die noch vor Erreichen der Obergrenzen greifen. Protokollierung: Belege und Zugriffsentscheidungen werden mit dem Trace des Loops pro Schritt verknüpft, sodass Kosten, Quellen und Berechtigungen eines Vorgangs zentral nachvollziehbar sind. Die Symmetrie ist das Argument: Unternehmen haben keine ungeregelten Anmeldedaten innerhalb des Loops akzeptiert, und es gibt keinen Grund, ungeregelte Identitäten und Ausgaben an dessen Schnittstellen zu akzeptieren – erst recht nicht, da teilnehmende Schnittstellen nun pro Anfrage abrechnen können.

5. Wo TrueFoundry hier ansetzt

Zunächst eine präzise Anmerkung, da diese Serie ihre Produktabschnitte durch klare Abgrenzung rechtfertigt: Das Funktionsspektrum von TrueFoundry umfasst keine x402-Abrechnung oder Web-Bot-Auth-Anfragesignierung, wie Sie der aktuellen Dokumentation entnehmen können. Der Punkt ist enger gefasst und struktureller Natur. Unabhängig davon, welche Systeme sich durchsetzen: Ein Governance-Muster, das mit zunehmendem bezahltem oder identitätsgeschütztem Maschinenzugriff an Bedeutung gewinnt – Identitätsvermittlung pro Agent, Ausgabenbegrenzung im Pfad, Aktivitäten auditierbar pro Schritt – entspricht genau der dokumentierten Form der Gateway-Ebene, die TrueFoundry heute bereitstellt. Identität und Delegierung: Agenten arbeiten mit vermittelten Anmeldedaten statt mit eingebetteten Schlüsseln, nutzen RBAC gegenüber dem Identitätsanbieter des Unternehmens sowie eine Delegierung pro Benutzer, wobei für sensible Aktionen Genehmigungs-Gates verfügbar sind (Agent Harness-Dokumentation; MCP-Gateway-Authentifizierung & Sicherheit). Budgetkontrolle: Budgets, die nach Mandant oder Team gegliedert und nach Benutzern, Modellen, virtuellen Konten und Metadaten partitioniert werden können, sowie Ratenbegrenzungen pro Benutzer, Modell und Anwendung — Agenten und Umgebungen können durch virtuelle Konten oder Metadaten abgebildet werden, sofern das Unternehmen dieses Mapping nutzt, inklusive Warn- und Sperrmodi sowie Budget-Meilenstein-Benachrichtigungen (Budget-Dokumentation) — ein Governance-Muster im Datenfluss, das bei einer breiten Einführung von nutzungsbasierten Abrechnungsmodellen (Pay-per-Request) immer wichtiger wird. Protokollierung: Kosten-, Token- und Latenzzuordnung pro Anfrage; schrittweise Nachverfolgung von Agenten-Ausführungen mit OpenTelemetry-Export; revisionssichere Protokolle der Agenten- und Tool-Aktivitäten (Gateway-Dokumentation). Eine Entwicklung aus Abschnitt 1 betrifft direkt eine bestehende Schnittstelle: Cloudflares angekündigte Monetization-Gateway-Pläne sollen es Kunden ermöglichen, MCP-Tool-Aufrufe in Rechnung zu stellen. Sollte sich der kostenpflichtige Tool-Zugriff ausweiten, könnte ein MCP-Gateway zu einem zentralen Governance-Punkt werden, um zu entscheiden, welche Tools eine Flotte aufrufen darf, unter welchen Identitäten und Budgets sowie mit welcher Protokollierung. Das bestehende MCP-Gateway von TrueFoundry bietet die Registry-, Authentifizierungs-, Zugriffskontroll- und Observability-Ebene, auf der eine solche Governance aufgebaut werden kann. Während das Innere des Kreislaufs in Abschnitt 5 unseres ersten Beitrags und die Kontrollmechanismen der Flotte im zweiten behandelt wurden, laufen die oben genannten Egress-Komponenten auf derselben Ebene zusammen — bereitstellbar für Unternehmen, deren Antwort auf die Frage „Wo läuft das?“ strikt ist: in einer VPC, On-Premises oder in einer Air-Gapped-Umgebung (Bereitstellungsmodell).

6. Grenzen

Fünf, damit das Argument im Rahmen seiner Belege bleibt. Der Reifegrad variiert je nach Komponente. Das Monetization Gateway befindet sich auf der Warteliste, Pay Per Crawl bleibt ein Beta-Projekt und Chainalysis verzeichnete im ersten Quartal 2026 mehr als 100 Millionen x402-Transaktionen auf Base, wobei angemerkt wurde, dass ein Großteil des anfänglichen Anstiegs durch spekulative Aktivitäten getrieben war und eine Massenadoption noch in weiter Ferne lag (chainalysis.com). Das Rennen um die Standards ist noch nicht entschieden. Konkurrierende Protokolle existieren bereits: ein Machine Payments Protocol, das gemeinsam von Stripe und Tempo (einem von Stripe und Paradigm inkubierten Zahlungsnetzwerk) entwickelt wurde. Die Argumentation dieses Beitrags ist bewusst protokollunabhängig, Leser sollten daraus jedoch keinen Sieger ableiten. Die Einführung von Identitätslösungen steht noch am Anfang. Die Arbeitsgruppe für Web Bot Auth, Registerentwürfe und erste produktive Signer sind real; eine flächendeckende Verbreitung ist es noch nicht. Und das Framework stammt von uns. „Egress Engineering“, das Passport-und-Wallet-Konzept sowie das Symmetrie-Argument sind die redaktionelle Synthese von TrueFoundry und werden mit Quellen belegt, damit Sie diese selbst bewerten können; die Leistungsbeschreibungen von TrueFoundry spiegeln die zum Zeitpunkt der Veröffentlichung öffentliche Dokumentation wider, und Amara ist ein illustratives Beispiel.

Die Sicherheit von Zahlungsprotokollen befindet sich noch in der Entwicklung. Aktuelle Untersuchungen haben potenzielle Fehlerquellen bei Replay-Attacken, Autorisierungsbindungen, Nebenläufigkeit sowie „bezahlt, aber verweigert“-Szenarien in x402-Implementierungen identifiziert (arXiv-Preprint); diese Ergebnisse sollten als neue Forschungsergebnisse und nicht als abschließende, ökosystemweite Schlussfolgerungen betrachtet werden.

Fazit

Loop Engineering hat seinen Namen dadurch verdient, dass wir den Loop als Arbeitseinheit ernst nehmen: Unser erster Beitrag befasste sich mit seinem Inneren, unser zweiter skalierte ihn über eine ganze Flotte hinweg. Teile des Webs beginnen, automatisierten Zugriffen explizitere Identitäts- oder Zahlungsbedingungen zuzuordnen. Für Unternehmen, die Agenten-Loops betreiben, wirft dies eine praktische Designfrage auf: Kann jeder Loop die zwei neuen Fragen der Außenwelt beantworten, ohne improvisieren zu müssen – „Das bin ich“ und „Das ist das Budget, in dessen Rahmen ich agiere“? Beide Antworten sind Governance-Artefakte. Beide gehören auf eine Ebene, nicht in einen Prompt. Und beide lassen sich vor der ersten Rechnung leichter implementieren als danach.

Referenzen

• Zahlungen – Linux Foundation, Start der x402 Foundation, 2. April 2026 (Leitungsgremium Coinbase/Cloudflare/Stripe; Google, Visa, Microsoft unter den mehr als 20 Unternehmen, die ihre anfängliche Unterstützung bekundet haben; das Zemlin-Zitat): linuxfoundation.org; Cloudflare Monetization Gateway Warteliste, 1. Juli 2026 (die Aussage „Agenten sollten für die Inputs bezahlen, die sie benötigen“, geplante MCP-Tool-Preisgestaltung): blog.cloudflare.com; Private Beta für Pay Per Crawl, Juli 2025: blog.cloudflare.com; 402-Volumen, primär (über 1 Mrd. tägliche Antworten an Bots und Crawler): blog.cloudflare.com/x402; Crawler-Kategorie-Standardeinstellungen zum 15. September, primär: blog.cloudflare.com; x402-Transaktionsvolumen (über 100 Mio. auf Base bis Q1 2026, Hinweise zur Einführung): chainalysis.com; Machine Payments Protocol (Co-Autoren Stripe und Tempo): stripe.com.
• Identität — Web-Bot-Authentifizierung aktueller Protokollentwurf; Entwurf für das Verzeichnis von HTTP-Nachrichtensignaturen; Arbeitsgruppe Gründungsbekanntmachung und Charta; Entwurf für das Signature Agent Card-Register; Cloudflare Prinzipien für verantwortungsvolle KI-Bots und Nachweise zur Implementierung und signed-agents Ankündigungen; Dokumentation zur AWS AgentCore Browser-Vorschau; Ankündigung zur Vercel Web Bot Auth-Verifizierung; Cloudflare-Referenzimplementierung
• TrueFoundry-Dokumentation — Agent Harness, MCP Gateway-Authentifizierung & Sicherheit, Budgetbegrenzung (nur Warnung, strikte Durchsetzung, Meilenstein-Benachrichtigungen), AI Gateway, MCP-Gateway, Bereitstellungsstrategie.
• Begleitende Serien – Loop-Engineering auf Unternehmensebene (die Laufzeit des Loops), Loop-Engineering für die Flotte (der Loop in großem Maßstab), Die agentische Konvergenz (das Zeitfenster Mitte 2026), KI-FinOps, semantisches Caching, Governance für agentisches Handeln.

Amara und ihr Forschungs-Loop sind ein illustratives Komposit und stellen keine spezifische Person, Organisation oder einen konkreten Vorfall dar. Alle Statistiken und Zitate entsprechen den Angaben der verlinkten Quellen zum jeweiligen Datum; zitierte Fragmente unter fünfzehn Wörtern sind als solche gekennzeichnet. „Egress Engineering“ sowie die Analogie von Pass und Wallet sind redaktionelle Synthesen von TrueFoundry. Die Funktionen von TrueFoundry sind Paraphrasen der zum Zeitpunkt der Erstellung öffentlichen Dokumentation – bitte prüfen Sie diese anhand der aktuellen Dokumentation; die Dokumentation von TrueFoundry beschreibt keine Unterstützung für x402 oder Web Bot Auth, und eine solche wird auch nicht beansprucht. TrueFoundry ist nicht mit Cloudflare, der Linux Foundation, der IETF, Amazon oder den zitierten Publikationen verbunden.

‍