De Loop Krijgt een Paspoort en een Portemonnee: Loop Engineering Ontmoet het Betaalde Web

Ditzelfde blog heeft loop engineering al twee keer benaderd als een interne discipline: onze eerste loop-engineering post stelde dat de zelfvoorziende loop thuishoort in een beheerde runtime, en onze fleet-runtime post breidde dat argument uit van één loop naar vele. Een gerelateerd extern probleem werd van eind 2025 tot midden 2026 steeds concreter. In oktober 2025 richtte de IETF de Web Bot Auth-werkgroep op om cryptografische authenticatiemethoden te ontwikkelen voor geautomatiseerde clients die voornamelijk mensgerichte websites bezoeken (huidige concept-protocol; aankondiging van werkgroepoprichting, goedgekeurd charter). Op 2 april 2026 lanceerde de Linux Foundation de x402 Foundation om het open x402-protocol voor HTTP-native betalingen te beheren — als "een open, door de community beheerde thuisbasis" voor het protocol, in de woorden van Linux Foundation-CEO Jim Zemlin bij de lancering (linuxfoundation.org). En op 1 juli 2026 opende Cloudflare de wachtlijst voor zijn aangekondigde Monetization Gateway — die klanten wil laten betalen voor elke requester, expliciet inclusief AI-agents, voor pagina's, datasets, API's of MCP-tools achter hun netwerk, afgerekend via x402 — waarbij glashelder werd gesteld dat "agents moeten betalen voor de inputs die ze nodig hebben" (blog.cloudflare.com). Samen gelezen — en deze samenschouwing vormt de redactionele synthese van dit artikel — beginnen sommige origins en diensten geautomatiseerde clients te voorzien van expliciete identiteits- of betalingsvoorwaarden: identificeer jezelf, en betaal naar gebruik. Sommige agent loops die plannen, handelen, verifiëren en doorgaan, zullen aan hun uitgaande rand steeds vaker deze poorten en meters tegenkomen. Dat geeft loop engineering een derde discipline, na de runtime in de loop en de fleet eromheen: egress — het gecontroleerde beheer van de identiteit, uitgaven en het gedrag van een loop op netwerken die niet onder controle van de onderneming vallen.

Amara, een platform engineer bij een enterprise met een sterke onderzoeksfocus, bemerkte het probleem in de kloof tussen twee logbestanden. De competitive-intelligence loop van haar team — een ingeplande agent die een onderzoeksvraag plant, bronnen ophaalt, beweringen daartegen verifieert en doorgaat totdat de checklist is afgevinkt — gaf ineens zelfverzekerde samenvattingen terug met opvallend dunne bronnenlijsten. De eigen trace van de agent vertoonde geen enkele fout: hij plande, haalde op en schreef. Het egress-logbestand vertelde de andere helft van het verhaal: een groeiend deel van de fetches kwam terug met een 403-status van sites die hun bot-beleid hadden aangescherpt, en een handvol kwam terug met 402 van een nieuw geprijsde API van een partner — een statuscode die de retry-logica als tijdelijk beschouwde, waardoor de loop beleefd elf keer dezelfde betaalde bron opnieuw opvroeg voordat hij het opgaf en om het gat heen schreef. Er crashte niets. Geen enkel alarm ging af. De loop werd simpelweg stiller, verbruikte extra model- en orchestratieresources door zijn retries, en leverde resultaten op die minder compleet en minder goed onderbouwd waren. Amara's incident-samenvatting van één regel vormt de stelling van deze post: de binnenkant van de loop was beheerd; de buitenkant niet. (Amara is een illustratief profiel; de foutmodi zijn waar het om gaat.)

1. De Gemarkeerde Omslag: Het Web Stelt Voorwaarden

De afzonderlijke ontwikkelingen hebben elk hun eigen reikwijdte, en het is de moeite waard ze precies te benoemen. x402 kreeg een neutrale governance-thuisbasis. Op 2 april 2026 lanceerde de Linux Foundation de x402 Foundation — het bestuursorgaan voor het x402-protocol, dat aanvankelijk werd ontwikkeld door Coinbase, Cloudflare en Stripe, waarbij Google, Visa, Microsoft en zo'n twintig andere technologie- en betalingsorganisaties hun initiële steun uitspraken (linuxfoundation.org). Het mechanisme van het protocol blaast de lang slapende HTTP 402-statuscode nieuw leven in: een client vraagt een bron op die achter een betaalmuur zit; de server antwoordt met een prijs en betalingsinstructies; de client betaalt en herhaalt het verzoek met het betalingsbewijs bijgevoegd. Het meten van gebruik verschoof van experiment naar product. Cloudflare's Pay Per Crawl werd in juli 2025 gelanceerd als een besloten beta-experiment om AI-crawlers te laten betalen voor content (blog.cloudflare.com); op 1 juli 2026 opende het bedrijf de wachtlijst voor zijn aangekondigde Monetization Gateway, die van plan is de prijsstelling per verzoek uit te breiden van crawlers naar elke requester en van pagina's naar datasets, API's en — opvallend voor deze reeks — MCP-tools (aankondiging). Cloudflare geeft aan dat sites op hun netwerk dagelijks meer dan één miljard HTTP 402-responsen sturen naar bots en crawlers die toegang proberen te krijgen tot content en e-commerce-omgevingen (blog.cloudflare.com). Dit zijn verzoeken om betaling, geen voltooide transacties. Los daarvan kondigde Cloudflare aan dat vanaf 15 september 2026 nieuw aangemelde domeinen standaard de categorieën Training en Agent blokkeren op pagina's die advertenties tonen, terwijl Search standaard toegestaan blijft en klanten de configuratie kunnen aanpassen (blog.cloudflare.com). En Web Bot Auth trad toe tot een IETF-standaardisatieproces. Web Bot Auth — het voorstel van Cloudflare uit 2025 waarin bots en agents verzoeken cryptografisch ondertekenen — bracht in oktober 2025 een IETF-werkgroep op de been, een concept-register voor Signature Agent Cards dat voor het eerst in 2025 werd gepubliceerd en in mei en juni 2026 werd herzien met een co-auteur van Amazon, en vroege ondertekening in productie door grote AI-providers, volgens de concepten en verslaglegging in Sectie 2. Geen van deze ontwikkelingen verandert op zichzelf het web. Samen beschrijven ze origins en diensten die zijn begonnen met het koppelen van explicieter toegangs- en betalingsbeleid aan bepaalde categorieën geautomatiseerd verkeer — met duidelijke voorwaarden: wie ben je, en wie betaalt er?

Een kanttekening bij de reikwijdte die in deze post wordt gehanteerd: de twee kanalen vormen geen geïntegreerd systeem. Volgens het IETF-charter richt Web Bot Auth zich op de cryptografische identificatie van geautomatiseerde clients die toegang zoeken tot voornamelijk mensgerichte websites — HTTP API's, agent-to-agent interfaces en de identificatie van de eindgebruiker achter een agent worden expliciet uitgesloten. Los daarvan worden betalingssystemen in de stijl van x402 toegepast op een bredere set van via HTTP bereikbare bronnen, waaronder pagina's, datasets, API's en MCP-tools. Dit artikel ziet beide als bewijs dat de egress van loops steeds vaker te maken kan krijgen met expliciet identiteits- of betalingsbeleid, waarbij wordt erkend dat de twee initiatieven een verschillende reikwijdte hebben.

2. Het Paspoort: Web Bot Auth en de Geïdentificeerde Loop

Dertig jaar lang werd de vraag "welke bot is dit?" beantwoord met een user-agent string die iedereen kon typen en een IP-bereik dat door iedereen binnen dat netwerk gebruikt kon worden. Web Bot Auth voegt daar cryptografisch bewijs aan toe dat verder gaat dan gissingen: onder het huidige concept-protocol ondertekent een geautomatiseerde client elk verzoek met een privésleutel (HTTP Message Signatures, RFC 9421), maakt hij zichzelf kenbaar via een Signature-Agent header en publiceert hij zijn publieke sleutels in een bekende directory (concept-directory van sleutels) zodat elke origin de handtekening onafhankelijk kan verifiëren (huidige concept-protocol; referentie-implementatie op github.com/cloudflare/web-bot-auth). De ondersteunende infrastructuur rijpte gedurende 2025–2026: Cloudflare integreerde berichtondertekeningen in juli 2025 in het Verified Bots-programma (blog.cloudflare.com), lanceerde die augustus een traject voor ondertekende agents (blog.cloudflare.com), en een concept-register voor Signature Agent Cards — met daarin de identiteit van een agent, de exploitant, de verwachte verwerkingssnelheid en sleutels — werd voor het eerst gepubliceerd in 2025 en herzien in mei en juni 2026, waarbij een co-auteur van Amazon zich aansloot bij de auteurs van Cloudflare; het blijft een Internet-Draft in ontwikkeling (huidig concept). De adoptie staat nog in de kinderschoenen en is wisselvallig — Cloudflare meldt dat de ChatGPT-agent van OpenAI verzoeken ondertekent met Web Bot Auth (bron), Amazon biedt ondersteuning voor ondertekening in een AgentCore Browser-preview (AWS-documentatie), en Vercel ondersteunt verificatie van Web Bot Auth-verkeer (Vercel changelog) — dit zijn specifieke implementaties, geen universele dekking; de richting is belangrijker dan het huidige aantal: origins krijgen een betrouwbare manier om de agents toe te laten die ze kiezen en de rest te weigeren. Voor een loop is de implicatie van structurele aard. Wanneer een agent of orchestratielaag toegangsfouten stilzwijgend opvangt, zal een loop zonder toonbare identiteit op een afgeschermd web wellicht niet met luide foutmeldingen falen; niet-ondertekende of geweigerde verzoeken kunnen leiden tot onvolledige bronvermelding in plaats van een duidelijke fatale fout. Dat richt de schade precies aan op het punt waar de sector nu al een aantoonbare zwakheid heeft: verificatie. Een geïdentificeerde loop daarentegen is een loop die door het web geaccepteerd kan worden — voorzien van niet alleen een handtekening, maar van een herleidbare oorsprong: cryptografisch bewijs dat laat zien welke ondertekenende client gekoppeld is aan welke exploitant. De autorisatie van de eindgebruiker blijft een afzonderlijk mechanisme voor enterprise-identiteit en delegatie, dat buiten de reikwijdte van Web Bot Auth valt.

3. De Portemonnee: HTTP 402 en de Nieuwe Keuze van de Loop

Het betalingsgedeelte verandert de control flow van de loop op een fundamenteler niveau, omdat het ingrijpt op het meest elementaire mechanisme van de loop: de retry. In een x402-transactie kan een 402-respons fungeren als een gestructureerd betalingsverzoek in plaats van een gewone foutmelding. MPP definieert een gerelateerde maar afwijkende flow — een dienst geeft een betalingsverzoek terug en de agent autoriseert de betaling voordat de bron wordt ontvangen; de publieke beschrijving van Stripe typeert die flow niet als gebaseerd op HTTP 402. Bij x402 geeft de server een prijs en betalingsdetails op; de client beslist of hij betaalt en herhaalt, na autorisatie, het verzoek met het betalingsbewijs. Als dat wordt geïntegreerd in een zelfvoorziende loop, heeft dat meerdere gevolgen. Prijs wordt een signaal op stap-niveau. Wanneer een loop met een vermelde prijs wordt geconfronteerd, moet deze mogelijk tijdens de uitvoering afwegen of een specifieke fetch, API-call of MCP-toolaanroep de prijs waard is ten opzichte van het resterende budget van de taak — een beslissing die voorheen hooguit bij het ontvangen van de factuur aan de orde kwam. De foutmodi draaien om. Amara's elf beleefde pogingen bij een geprijsd eindpunt illustreren de onschuldige variant; de dure variant ontstaat wanneer een automatisch betalingsbeleid herhaalde of afzonderlijke verzoeken autoriseert zonder afdoende idempotentie, ontdubbeling of budgetcontroles — een client die simpelweg een onbetaalde 402 opnieuw probeert, verspilt calls zonder iets te kopen, maar een beleid dat elke nieuwe prijsopgave opnieuw autoriseert, vermenigvuldigt de uitgaven. Dit is het fan-out effect dat in onze fleet post is geanalyseerd, maar nu met een meter op elke aftakking. Caching wordt een inkoopstrategie. Het opnieuw kopen van wat de organisatie al heeft gekocht is het nieuwe opnieuw berekenen van wat al berekend was; een betaalde respons is een waardevol bezit om te bewaren — voor zover de voorwaarden voor actualiteit, licenties, privacy en autorisatie dat toestaan. En betalingsbewijzen worden onderdeel van de operationele verantwoording. Wanneer een betalingsrecord cryptografisch en operationeel gekoppeld is aan het verzoek en de identiteit van de requester, kan dit een audit trail ondersteunen die de opgevraagde bron, het geautoriseerde bedrag en de status van de afwikkeling toont. Het levert op zichzelf geen bewijs van succesvolle levering, bronkwaliteit of juistheid van de uitvoer. Dat record hoort thuis in dezelfde trace op stap-niveau als de tool-calls die het vergezelt, zowel voor financiële controle als voor de kosten- en toegangsregistratie die nodig is voor operationele verantwoording. Dit alles staat los van de vraag welk afwikkelingskanaal uiteindelijk de standaard wordt. Het draait om het inzicht dat de uitgaande kant van de loop transactiesemantiek kan krijgen, en dat transactiesemantiek zonder governance de manier is waarop pilots veranderen in onvoorziene facturen.

4. Egress: De Derde Discipline van Loop Engineering

Onze eerste loop post stelde dat de loop thuishoort in een runtime — sandbox, credentials, gates, audit-records — en onze fleet post stelde dat de runtime moet kunnen opschalen naar vele loops zonder dat het aantal beheermechanismen vermenigvuldigt. Beide kijken naar binnen. Wat het betaalde web toevoegt kijkt naar buiten, en het vormt een samenhangend geheel dat als een op zichzelf staande discipline kan worden benoemd — door ons gepresenteerd als een redactionele synthese in plaats van een vaststaande doctrine. Egress engineering is het gecontroleerde beheer van alles wat een loop buiten de bedrijfsgrenzen uitvoert, en de onderdelen ervan vormen een heldere spiegel van de interne set. Identiteit: de loop toont wie hij is — ondertekende verzoeken waar de infrastructuur dat ondersteunt, maar fylogeen een identiteit die per agent wordt beheerd met daarachter delegatie per gebruiker, zodat de vraag "wie heeft dit gedaan" een dieper antwoord heeft dan alleen een sleutel. Beleid: wat de loop mag kopen, van wie en tot welk maximum — de externe tegenhanger van de tool-allowlist. Handhaving: uitgaven binnen het verzoekpad begrenzen, in plaats van achteraf bij het sluiten van de maand afrekenen — warn-only modi voor inventarisatie, harde modi voor productie, en drempelwaarden die waarschuwen voordat limieten worden bereikt. Audit-records: betalingsbewijzen en toegangsbeslissingen gekoppeld aan de trace per stap van de loop, zodat de kosten, bronnen en autorisaties van een run vanaf één centrale plek herleidbaar zijn. De argumentatie schuilt in deze symmetrie: bedrijven accepteerden geen onbeheerde credentials binnen de loop, en er is geen reden om onbeheerde identiteit en uitgaven aan de buitenrand te accepteren — zeker nu deelnemende eindpunten per verzoek kunnen factureren.

5. Waar TrueFoundry Dit Ontmoet

Eerst een verduidelijking, want deze serie onderbouwt de productsecties door het toepassingsgebied precies af te bakenen: de functionaliteiten van TrueFoundry omvatten geen x402-afwikkeling of het ondertekenen van Web Bot Auth-verzoeken, zoals te lezen is in de meest recente documentatie. Het punt is een structureel punt. Welke standaarden ook winnen, het governance-patroon dat belangrijker wordt naarmate machinetoegang met betalingen of identiteitspoorten toeneemt — identiteit beheerd per agent, uitgaven in-path begrensd, activiteit auditeerbaar per stap — is precies de gedocumenteerde vorm van het gateway-plane dat TrueFoundry vandaag levert. Identiteit en delegatie: agents werken met beheerde credentials in plaats van ingebouwde sleutels, RBAC gekoppeld aan de enterprise identity provider, en delegatie per gebruiker, waarbij goedkeuringsstappen beschikbaar zijn voor gevoelige acties (Agent Harness-docs; MCP Gateway auth & security). Uitgavenhandhaving: budgetten toegewezen per tenant of team en op te splitsen naar gebruikers, modellen, virtuele accounts en metadata, aangevuld met rate limits per gebruiker, per model en per applicatie — waarbij agents en omgevingen gerepresenteerd kunnen worden via virtuele accounts of metadata als de organisatie die koppeling gebruikt, met warn-only en harde handhavingsmodi plus meldingen bij budgetmijlpalen (budget-docs) — een in-path governance-patroon dat aan belang wint als bronnen met betaling per verzoek op brede schaal worden geadopteerd. Audit-records: toewijzing van kosten, tokens en latency per verzoek; traces per stap van agent-runs met OpenTelemetry-export; auditeerbare logboeken van agent- en tool-activiteit (gateway-docs). En één ontwikkeling uit Sectie 1 sluit rechtstreeks aan op een bestaand onderdeel: de aangekondigde Monetization Gateway van Cloudflare wil klanten laten betalen voor MCP-toolaanroepen. Als betaalde toegang tot tools groeit, kan een MCP-gateway een logisch controlepunt worden om te bepalen welke tools een fleet mag aanroepen, onder welke identiteiten en budgetten, en met welk audit-record. TrueFoundry’s bestaande MCP Gateway biedt de register-, authenticatie-, toegangsbeheer- en observability-laag waarop zulke governance gebouwd kan worden. Waar de binnenkant van de loop Sectie 5 van onze eerste post vormde en de beheermechanismen voor de fleet de tweede, komen de bovenstaande egress-componenten uit op hetzelfde vlak — uitrolbaar, voor organisaties met strikte eisen voor de runtime-omgeving, in VPC, on-premises of in air-gapped vorm (deployment posture).

6. Beperkingen

Vijf punten van voorbehoud, zodat het argument binnen de grenzen van de feiten blijft. Volwassenheid verschilt per onderdeel. De Monetization Gateway staat op een wachtlijst, Pay Per Crawl blijft een beta-traject, en Chainalysis rapporteerde meer dan 100 miljoen x402-transacties op Base tot het eerste kwartaal van 2026, met de kanttekening dat een groot deel van de eerdere piek werd gedreven door speculatieve activiteit en dat grootschalige adoptie nog ver weg was (chainalysis.com). De strijd om de standaarden is niet gestreden. Er bestaan al concurrerende protocollen: een Machine Payments Protocol ontwikkeld door Stripe en Tempo (een betalingsnetwerk opgezet door Stripe en Paradigm). Het argument in deze post is bewust onafhankelijk van het gekozen betalingskanaal; lezers moeten hierin geen winnaar lezen. Adoptie van identiteitsstandaarden is nog pril. De werkgroep van Web Bot Auth, de concept-registers en de eerste providers die in productie ondertekenen zijn reëel; van universele dekking is echter geen sprake. En het kader is het onze. "Egress engineering," de vergelijking met het paspoort en de portemonnee, en de symmetrie-redenering zijn de redactionele synthese van TrueFoundry, voorzien van bronnen zodat u deze zelf kunt wegen; uitspraken over de mogelijkheden van TrueFoundry weerspiegelen de openbare documentatie op het moment van schrijven, en Amara is een illustratief profiel.

De beveiliging van betalingsprotocollen is nog in ontwikkeling. Recent onderzoek heeft mogelijke kwetsbaarheden aan het licht gebracht bij x402-implementaties rond replay-attacks, autorisatiekoppeling, concurrency en situaties waarbij wel is betaald maar toegang wordt geweigerd (arXiv preprint); deze bevindingen moeten worden beschouwd als voortschrijdend onderzoek en niet als definitieve conclusies voor het gehele ecosysteem.

Tot Slot

Loop engineering dankt zijn naam aan het serieus nemen van de loop als de centrale eenheid van werk: onze eerste post beheerde de binnenkant, onze tweede schaalde dit op over een fleet. Delen van het web beginnen nu explicietere identiteits- of betalingsvoorwaarden te stellen aan geautomatiseerde toegang. Voor bedrijven die agent loops inzetten, roept dat een praktische ontwerpvraag op: kan elke loop de twee nieuwe vragen van de buitenwereld beantwoorden zonder te improviseren — “dit is wie ik ben” en “dit is het budget waarbinnen ik werk”? Beide antwoorden zijn governance-artefacten. Beide horen thuis in een control plane, niet in een prompt. En beide zijn eenvoudiger in te richten vóór de eerste factuur binnenkomt dan erachteraf.

Referenties

• Betalingen — Linux Foundation, x402 Foundation launch, 2 april 2026 (bestuursorgaan Coinbase/Cloudflare/Stripe; Google, Visa, Microsoft onder 20+ met initiële steun; het citaat van Zemlin): linuxfoundation.org; Cloudflare Monetization Gateway waitlist, 1 juli 2026 (de zinsnede "agents should pay for the inputs they need", geplande MCP-tool prijsstelling): blog.cloudflare.com; Pay Per Crawl private beta, juli 2025: blog.cloudflare.com; 402 volume, primair (1B+ dagelijkse responzen naar bots en crawlers): blog.cloudflare.com/x402; crawler-categorie standaarden 15 september, primair: blog.cloudflare.com; x402 transactievolume (100M+ op Base t/m Q1 2026, kanttekeningen bij adoptie): chainalysis.com; Machine Payments Protocol (co-auteurs Stripe en Tempo): stripe.com.
• Identiteit — Web Bot Auth huidig concept-protocol; HTTP Message Signatures Directory draft; werkgroep oprichtingsaankondiging en charter; Signature Agent Card concept-register; Cloudflare principles voor verantwoorde AI-bots en implementatiebewijs en signed-agents aankondigingen; AWS AgentCore Browser preview-documentatie; Vercel Web Bot Auth verificatie-aankondiging; Cloudflare referentie-implementatie
• TrueFoundry documentatie — Agent Harness, MCP Gateway auth & security, budget limiting (warn-only, hard enforcement, milestone alerts), AI Gateway, MCP Gateway, deployment posture.
• Aanvullende artikelen in deze reeks — Loop engineering op enterprise-niveau (de runtime van de loop), Loop engineering voor de fleet (de loop op schaal), De Agentic Convergence (de periode midden 2026), AI FinOps, semantic caching, agentic commerce governance.

Amara en haar research loop zijn een illustratieve compositie, geen specifiek persoon, organisatie of incident. Alle statistieken en citaten zijn zoals gerapporteerd door de gelinkte bronnen op de vermelde datums, met geciteerde fragmenten van minder dan vijftien woorden en voorzien van bronvermelding; cijfers die zijn aangeduid als secundaire berichtgeving zijn als zodanig gelabeld in de tekst. "Egress engineering" en de paspoort-en-portemonnee-framing zijn de redactionele synthese van TrueFoundry. De functionaliteiten van TrueFoundry zijn geparafraseerd uit openbare documentatie die actueel was op het moment van schrijven — verifieer deze aan de hand van de live documentatie; de documentatie van TrueFoundry beschrijft geen ondersteuning voor x402 of Web Bot Auth, en deze wordt ook niet beweerd. TrueFoundry is niet gelieerd aan Cloudflare, de Linux Foundation, de IETF, Amazon of de geciteerde publicaties.

‍