Anthropic ID-verificatie: agents splitsen in 16 dagen

Op 11 juni om 09:14 stuurde de operations lead van een groothandel met 23 medewerkers in Tiel ons een e-mail van Anthropic door en vroeg wat 8 juli betekende voor de veertien agents die we voor haar gebouwd hadden. Tien daarvan lezen inbox-threads, zoeken productspecs op in een kennisbank, schrijven concept-antwoorden, en raken de buitenwereld nooit aan. Vier doen echt werk — een computer-use agent die een oude Citrix VDA bestuurt om prijslijsten in de ERP bij te werken, een code-execution agent in een Modal-sandbox die verzendmanifesten verzoent, een file-access agent die in hun SharePoint-tenant leeft om order-PDF's georganiseerd te houden, en een Playwright-browser agent die palletophalingen boekt op een vervoerderportaal zonder API.

De mail zei dat vanaf 8 juli 2026 iedereen die de high-capability API-features aanroept — diezelfde vier dingen die we net noemden — een identity verification op de workspace moet voltooien. De geverifieerde persoon wordt een benoemde partij voor dat verkeer. De volledige tekst van het beleid staat op anthropic.com/legal.

Als we een ABN-medewerker zouden verifiëren tegen de bestaande workspace van de klant, dan zou de verwerkersovereenkomst van die workspace een nieuwe sub-verwerker-verklaring binnen scope krijgen. Elke klant-DPA die de groothandel ooit had getekend — en dat was een hele stapel — zou bij strikte lezing een addendum nodig hebben. Het juridische team zou ons niet dankbaar zijn.

We hadden zestien dagen. Dit is wat we hebben uitgerold. Het werkt of je nu vier agents hebt of veertig, specifiek genoeg dat je de architectuur kunt overnemen, generiek genoeg dat je Citrix kunt vervangen door Azure Virtual Desktop en SharePoint door Google Drive zonder de vorm te wijzigen.

Wat ID-verificatie eigenlijk verandert

ID-verificatie hangt alleen aan de workspace die de gated capabilities aanroept. Roept een workspace nooit computer-use, code-execution met netwerk, file-access met tenant scope of browser-control met screenshot aan, dan blijft die in het oude regime. De inbox-RAG-agents lezen tekst en schrijven tekst. Ze triggeren niets.

De vraag is dus niet verifiëren we. De vraag is waar de geverifieerde identiteit zit, en of die ergens opduikt in de verwerkingsketen van een bestaand contract.

Voor ons was het antwoord: een tweede workspace bouwen, geverifieerd, eigendom van een ABN-entiteit in plaats van de klant, aangeroepen over een service-grens. De bestaande workspace van de klant blijft de voordeur voor de tien inbox-agents en stuurt specifieke taken door naar de tweede workspace waar nodig. De tweede workspace verwerkt niets wat niet al was afgedekt door de clausule uit de oorspronkelijke DPA: ABN BV als sub-verwerker met het recht om verdere sub-verwerkers in te schakelen onder gelijkwaardige voorwaarden.

Die clausule is dragend. Geeft jouw DPA je nog geen ruimte om verdere sub-verwerkers onder gelijkwaardige voorwaarden in te schakelen, dan bespaart deze playbook je het opnieuw tekenen niet. Dan voer je eerst een gesprek met de DPO van de klant. Check dat voordat je een regel code schrijft.

De splitsing, uitgewerkt

We tekenden 'm op een whiteboard met twee vakken. De klant wilde 'm zien voor akkoord, dus we hebben de vakken aangescherpt tot een diagram van één pagina en in de project-repo gezet.

Workspace A — tiel-prod — blijft waar 'ie altijd al was. Anthropic-facturatie op de factuur van de klant. Tien agents. Inbox-triage, kennis-lookups, concept-antwoorden, FAQ-chat voor de front-of-site. Geen geverifieerde identiteit eraan gekoppeld.

Workspace B — tiel-cap — is nieuw, gefactureerd aan ABN, geverifieerd op het ID van een bestuurder onder de juridische entiteit ABN BV. Vier agents. Computer-use, code-execution, file-access, browser-control. Elk zit achter een dunne HTTP-service die workspace A kan aanroepen.

De call-vorm die we vastlegden:

POST /agents/file-access/move-pdf
Authorization: Bearer <hmac-signed-token>
Content-Type: application/json

{
  "tenant_id": "tiel",
  "task_id": "ord-2026-07-44823",
  "intent": "move shipment PDF to /Orders/2026/Q3/"
}

Workspace A houdt geen credentials voor SharePoint, de Citrix VDA, Modal of het vervoerderportaal. Hij heeft één uitgaand secret: de HMAC-sleutel voor de agent gateway. De gateway authenticeert, routeert naar de juiste capability-agent in workspace B, en geeft een gestructureerd resultaat terug aan workspace A.

Die gateway is een Cloudflare Worker van 200 regels. Alleen inbound vanuit workspace A, uitgaand naar de vier agent-endpoints, Logpush-sink gedeeld met beide workspaces. Op de logs komen we terug.

DPA-keten, onaangeroerd

De contractketen op dag één, vóór dit traject, was: de groothandel als verwerkingsverantwoordelijke, ABN BV als verwerker genoemd in 100% van hun klant-DPA's, Anthropic als sub-verwerker genoemd in 100% van hun klant-DPA's, en Modal, Cloudflare en Microsoft (voor SharePoint via de eigen tenant van de klant) opgenomen in de sub-verwerker-lijst die de klanten van de groothandel hadden geaccordeerd.

Na de splitsing is de contractketen identiek. De nieuwe workspace tiel-cap is eigendom van ABN BV. De geverifieerde persoon is een bestuurder van ABN BV. Er verschijnt geen nieuwe juridische entiteit in de verwerkingsketen. De rol van Anthropic voor tiel-cap is een strengere versie van de rol die het al had voor tiel-prod — dezelfde sub-verwerker, met extra identity-attestation aan de kant van ABN.

De geverifieerde identiteit hangt aan ABN, niet aan de klant. De klanten van de groothandel hebben nooit een relatie gehad met die identiteit. Zij hoeven er net zo min over geïnformeerd te worden als over wie bij ABN welke regel Python heeft geschreven.

We schreven een korte memo aan de DPO van de klant waarin we dit in helder Nederlands uitlegden. De memo vroeg geen tegen-tekening. We hebben 'm in hun compliance-map gezet en zijn doorgegaan.

Kortlevende credentials voor de browser-agent

De Playwright-agent — headless Chromium op Modal, die het palletboekingsportaal van de vervoerder bestuurt — had zijn eigen draai nodig. De vervoerder heeft geen API. Inloggen is alleen voor mensen. De agent logde dus in als een echte gebruiker, een service-account dat we daarvoor in 2024 hadden aangemaakt.

Dat werkte. Het betekende ook dat een high-capability agent vaste credentials voor een echt account in handen had — een positie die slecht oud wordt op het moment dat er upstream een geverifieerde identiteit aan vastzit.

Bij de herontwerp zijn we voor die agent overgestapt op kortlevende sessies. Elke boekings-taak geeft aan het begin een verse credential uit, gebruikt 'm één keer, en rouleert 'm aan het eind. Cloudflare publiceerde in juni een patroon hiervoor, specifiek voor AI-agents: temporary accounts for AI agents, dat in de week dat we live gingen op 225 stond op Hacker News. Het idee is dat de agent nooit een langlevend wachtwoord in handen heeft; de credential bestaat voor de duur van de taak en is daarna weg.

Dat kunnen we niet precies zo doen tegen het vervoerderportaal, omdat dat portaal geen tijdelijke credentials uitgeeft. De rotatie gebeurt dus aan onze kant. Vault bewaart een verzegelde seed. De agent gateway leidt een eenmalige login af die de komende acht minuten geldig is. De agent gebruikt 'm, de portal-sessie wordt gesloten, het wachtwoord wordt opnieuw geroteerd vóór de volgende taak. De blast radius van een gecompromitteerde agent is één boekingspoging, niet het hele account.

Het is niet het schoonste ontwerp. Het is het schoonste ontwerp dat we in zestien dagen konden uitrollen tegen een vervoerder die niet gaat veranderen.

Audit-logs die de splitsing overleven

De oorspronkelijke opzet logde alles in één stream. Na de splitsing liepen we een reëel risico de rode draad kwijt te raken: een klant-antwoord opgesteld door een inbox-agent kon twintig minuten later een prijslijst-update door de computer-use agent triggeren, en die moesten we op aanvraag kunnen koppelen.

Elke request van workspace A naar de gateway draagt een task_id die doorpropageert naar workspace B. Beide workspaces sturen logs naar dezelfde Logpush-sink, gekoppeld op task_id. Eén LogQL-query joint ze.

{job="anthropic-audit"}
  | json
  | task_id = "ord-2026-07-44823"
  | line_format "{{.workspace}} {{.agent}} {{.event}}"

Die query is wat de operations lead nu opent als een klant vraagt wat het systeem met zijn order heeft gedaan. Twee workspaces, één log, één antwoord.

We hebben een retention-policy aan de gateway gehangen: volledige request- en response-bodies voor 90 dagen, gestructureerde metadata voor 24 maanden. Dat sloot aan op de bestaande data-retentie-notice van de groothandel. Geen update van de privacyverklaring nodig.

Hygiëne aan Anthropic-kant vóór 8 juli

Het bouwen is het makkelijke deel. De setup aan Anthropic-kant heeft twee valkuilen die het waard zijn om hardop te benoemen.

Eén: als je de nieuwe workspace aanmaakt, blijven de API-keys in workspace A werken. Aan die workspace verandert niets. Onderdruk de neiging tot opruimen door keys opnieuw uit te geven. Het hoeft niet, en opnieuw uitgeven introduceert een raam waarin de inbox-agents stoppen met werken om een reden die je klant niet accepteert.

Twee: rond de identity verification minimaal 72 uur vóór de deadline af. Wij deden 'm op 17 juni, vijf dagen nadat de oorspronkelijke mail binnenkwam. De verificatie vroeg om een paspoortfoto, een live selfie en het KvK-uittreksel van de juridische entiteit. De volgende ochtend kwam de goedkeuring binnen. Was 'ie afgekeurd en hadden we een handmatige review nodig gehad, dan was 7 juli geen slim moment geweest.

Het engineering-team van Anthropic publiceerde een stuk dat hierbij de moeite van het lezen waard is: building effective agents. De punten over elke agent die zijn eigen credentials beheert in plaats van die van jou te erven, sluiten netjes aan op de splitsing hierboven.

Maandagochtend bij de klant

Niets zichtbaar. Dat was het doel.

De inbox-agents bleven triëren. De prijslijst-agent bleef prijzen updaten. De palletboekings-agent bleef pallets boeken. Latency op cross-workspace calls voegde ongeveer 280 ms toe aan de vier high-capability flows, wat niemand merkte omdat ze allemaal async lopen en via Teams terugkoppelen.

De operations lead kreeg er één dashboard-tegel bij — een telling van gateway-calls per agent per dag — waarvan ze zei dat ze 'm de eerste week zou negeren en die ze in de tweede week elke ochtend ging checken.

Waar deze playbook ophoudt

Drie situaties waarin de vorm verandert.

Jouw DPA dekt nog geen inschakeling van sub-verwerkers onder gelijkwaardige voorwaarden. Dan ga je heronderhandelen, en de architectuur hierboven is een halve oplossing.

De toezichthouder van jouw klant (financiële sector, zorg, bepaalde aanbestedingen bij de overheid) eist dat de verwerkingsverantwoordelijke de identiteit ziet van iedere benoemde persoon die data verwerkt. Dan kun je de geverifieerde persoon niet binnen een sub-verwerker verstoppen. Die persoon moet upstream genoemd worden, en je accepteert het opnieuw tekenen.

Jouw high-capability agents hebben directe toegang nodig tot data die de inbox-agents al in context hebben geladen. Dan is de gateway geen dunne service meer — die bemiddelt in data-verkeer, en je schrijft een kleine data-laag. Reken op twee weken, niet een weekend.

Voor de groothandel in Tiel speelde geen van die situaties. De splitsing was schoon.

Toen we de gateway en de geverifieerde workspace voor die groothandel bouwden, bleek de dragende beslissing de DPA-review op dag één, niet de Cloudflare Worker of de Modal-sandbox. Geeft jouw sub-verwerker-clausule je al ruimte om verdere partijen onder gelijkwaardige voorwaarden in te schakelen, dan heb je een weekend werk voor de boeg. Wij doen dit soort AI-agent-scheidingswerk end-to-end als de deadline echt is en de agenda krap.

Open je drie meest-getekende klant-DPA's en zoek op sub-verwerker en gelijkwaardige voorwaarden. Het antwoord zit in die twee termen. Ontbreken ze, dan is dat gesprek het eerste om vandaag in te plannen.