Anthropic verified tier: 14 agents migreren in 16 dagen

Vorige woensdag veegden we het whiteboard in de vergaderruimte schoon en schreven één getal bovenaan: 8 juli 2026. Daaronder veertien regels, één voor elke agent die in productie draait bij onze klanten. Drie van die regels kregen een rode stip: de computer-use scheduler voor een logistiek bedrijf in Rotterdam, de code-execution sandbox die we draaien voor een Antwerpse fintech, en de file-access bibliothecaris bovenop een Drupal-naar-Strapi migratiecorpus. De andere elf waren inbox-triage en RAG-agents. Werkpaarden, niets exotisch. Zestien werkdagen om de drie rode stippen achter Anthropic's verified-organisation tier te krijgen, zonder de elf saaie er onderweg uit te gooien.

Dit is het draaiboek dat we gebruikten. Het is de tweede keer dat we zo'n tier-migratie doen, en de eerste keer leerde ons het meeste van wat hieronder staat. Heb je een klantenboek vol agents en ben je nog niet begonnen, dan heb je een lang weekend papierwerk voor de boeg en een kort venster om de techniek goed te krijgen.

De splitsing die er echt toe doet

Anthropic's bijgewerkte usage policy trekt de lijn op een plek die technisch lijkt maar in werkelijkheid over blast radius gaat. Agents die een muis kunnen bewegen, willekeurige code draaien of lokale bestanden van een gebruiker lezen, zitten vanaf nu achter een identity-verified organisatie. Al het andere, de inbox-responders, de kennisbank-lookups, de single-tool webhook-agents, blijft op een standaard API-key draaien. De Hacker News-thread schilderde het af als een compliance-last. Vanuit een agent-shop gezien leest het meer alsof Anthropic het high-capability oppervlak eindelijk op dezelfde voet zet als een Stripe Treasury-account: je mag het blijven gebruiken, maar de organisatie die het gebruikt moet een echte, met naam genoemde rechtspersoon zijn die iets heeft getekend.

De splitsing doet ertoe omdat je kunt stoppen met doen alsof elf inbox-agents hetzelfde risicoprofiel hebben als één computer-use scheduler. Dat hadden ze nooit. Ze gelijk behandelen is wat audits in het verleden zo pijnlijk maakte.

Capability koppelen aan risico, niet aan labels

Het eerste uur ging in de inventarisatie zitten. We pakten elke agent in het boek en tagden 'm op wat hij op API-niveau daadwerkelijk kon doen, niet op hoe marketing 'm noemde. De elf laagrisico-agents waren makkelijk: elk consumeert een vaste scope (een Gmail-label, een Pinecone-index, een HTTP-webhook) en zendt tekst uit. De drie die voor de verified tier werden geflagged, waren lastiger, omdat twee ervan langzaam in hun capabilities zijn gegroeid.

De Rotterdamse scheduler begon in 2024 als een Calendly-spiegel en kreeg er stilletjes browser-automation bij toen we afgelopen najaar containertracking toevoegden. De Antwerpse sandbox was altijd al code-execution, maar had ergens onderweg een "lees de CSV van de klant uit S3"-tool opgepikt die bij zorgvuldig lezen als file-access kwalificeerde. Labels liegen. De toollijst niet.

jq '.agents[] | {id, tools: [.tools[].name]}' inventory.json \
  | rg -e 'computer_use|code_execution|filesystem|browser' \
  | tee high-capability.txt

Die check van vier regels leverde dezelfde drie agents op als de menselijke review. We hielden het scriptje toch in het draaiboek. Als de volgende capability-grens verschuift, willen we dat de audit vijf minuten kost, geen vijf uur.

Het pad voor identity verification

Onze Nederlandse BV verifiëren kostte twee dagen end-to-end: het KvK-uittreksel, de UBO-verklaring en een videocall met de ID-check per ontwikkelaar. De Thaise vestiging duurde langer. Reken op een week als je tweede entiteit buiten de EU zit, en start daarmee als eerste, niet als laatste.

Eenmaal geverifieerd krijgt de organisatie een aparte API-key namespace. Oude keys blijven werken op de standaard tier. Nieuwe keys, gescoped op verified-only modellen en capabilities, leven in hun eigen ring. Probeer keys niet te hergebruiken over de grens heen. De velden in het audit log verschillen, en je SIEM gaat je haten.

DPA-addenda zonder achtvoudige tekenronde

Elke klant met wie we werken heeft een Data Processing Agreement getekend op basis van de agent-capabilities die op dat moment bestonden. Drie van die agents naar een nieuwe sub-processor-relatie verplaatsen, Anthropic-als-verified-processor in plaats van Anthropic-als-standaard-processor, is een materiële wijziging onder AVG artikel 28. Je bent elke betrokken verwerkingsverantwoordelijke een bijgewerkt addendum verschuldigd.

Acht klanten, zestien dagen, ongeveer evenveel huisjuristen die alleen op dinsdag contracten lezen. We hadden geen tijd voor acht losse onderhandelingen.

Wat werkte, was een omnibus capability schedule: één addendum per klant dat verwijst naar een door ons onderhouden, geversioneerd schedule (v2026-07) waarin per agent staat: de capability tier, de sub-processor en de dataklassen die eraan raken. Toekomstige capability-verschuivingen binnen dezelfde tier verhogen de schedule-versie en triggeren een notificatiemail, geen nieuwe handtekening. Capability-verschuivingen over tiers heen vereisen wel een nieuwe handtekening, en dat is de juiste default. Dan moet de verwerkingsverantwoordelijke er ook opnieuw naar kijken.

Twee klanten drukten terug op het schedule-patroon en wilden elke ronde een maatwerkaddendum. Voor die twee draaiden we de lange versie. De andere zes tekenden binnen negen werkdagen.

De cutover zonder downtime

De elf laagrisico-agents hoefden niet te verhuizen. De helft van het engineering-werk was de neiging onderdrukken om ze "voor de netheid" tóch te migreren. Ze blijven op standaard keys. Hun DPA's veranderen niet. Laat ze met rust.

Voor de drie high-capability agents liep de cutover per agent, niet per klant, in een lus van vier stappen:

1. Provisioneer een verified-tier key, gescoped op de toollijst van één agent.
2. Dual-write gedurende 48 uur: zowel de oude als de nieuwe key verwerkt live traffic. Responses van de nieuwe key worden gelogd en gediff't tegen die van de oude, maar alleen de oude responses gaan terug naar de klant.
3. Schakel de response-bron over naar de nieuwe key. Houd de oude key zeven dagen actief en idle.
4. Trek de oude key in.

Het schaduwvenster van 48 uur ving één echte bug op. De execute_python-tool van de Antwerpse sandbox gaf op de verified tier een iets andere error-envelope terug (een extra capability_grant_id-veld dat een Pydantic-validator verderop sloopte). We zagen het in uur zes van de schaduwperiode, fixten het in 40 minuten, en de eigenlijke cutover verliep zonder incidenten. Zonder dual-write hadden we die regressie naar productie geduwd.

Cloudflare temporary accounts als zijdeur voor credentials

De truc die we deze ronde overnamen, komt uit een Cloudflare-post over temporary accounts voor AI-agents, dezelfde week gepubliceerd als de aankondiging van Anthropic. Vergelijkbaar instinct, andere laag. Voor de drie high-capability agents is de verified-tier API-key nu extreem waardevol: hij draagt de identiteit van de organisatie, en als hij lekt, betekent rotatie nóg een KYC-ronde.

De verified key raakt dus nooit het netwerk van de klant. Hij leeft in een Worker. De Worker mint per sessie een wegwerp-credential, gescoped op één agent-run, en het proces aan de client-kant praat alleen met die credential. Lekt een session credential, dan trekken we 'm in dertig seconden in en de verified key blijft onaangeroerd. Het patroon voegt zo'n twaalf milliseconden latency toe en haalt een hele incidentcategorie uit het draaiboek.

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const session = await mintSessionToken({
      agent: req.headers.get("x-agent-id"),
      ttlSeconds: 900,
      scope: ["computer_use:click", "computer_use:read"],
    });
    return fetch("https://api.anthropic.com/v1/messages", {
      method: "POST",
      headers: {
        "x-api-key": env.VERIFIED_KEY,
        "x-session-token": session.token,
        "content-type": "application/json",
      },
      body: req.body,
    });
  },
};

Dat is de hele brug. De x-session-token is van ons, niet van Anthropic. De Worker verifieert 'm aan de ingang en weigert requests die een agent noemen waarvoor het token niet gescoped is. Elke high-capability call heeft nu twee onafhankelijke failure domains, en de credential waar het ons echt om gaat, woont in Cloudflare Secrets, niet op een bastion host bij een klant.

Wat we de eerste keer fout deden

Drie dingen, opgeschreven zodat de volgende migratie goedkoper wordt.

We behandelden DPA-heronderhandeling als een juridische exercitie. De securityteams van de klanten gaven meer om toegang tot het audit log dan om de tekst van het addendum. De tweede klant die we benaderden, vroeg vóór hij het schedule had gelezen of hij het nieuwe capability-grant log naar zijn eigen Splunk kon trekken. Wij hadden geen antwoord paraat. Daarna openden we met de audit posture, en kwam het addendum erachteraan.

We onderschatten KYC buiten de EU. De Thaise entiteit kostte zes werkdagen, inclusief één ronde "graag de UBO-verklaring opnieuw uploaden met een scherpere scan". Heb je een tweede jurisdictie in je organisatie, start die verificatie dan op dag één.

We vergaten de staging keys. Twee van de elf laagrisico-agents hadden staging-omgevingen die nog steeds keys van de oude organisatie gebruikten, voor het gemak. Ze hoefden niet te verhuizen, maar ons deprovision-script probeerde ze toch in te trekken. Tag je keys op environment voordat je iets gaat intrekken, en schrijf de revoke-lijst de eerste keer met de hand.

De kleinste versie die je deze week kunt draaien

Heb je één agent en één klant, dan klapt het draaiboek samen tot: verifieer de organisatie, scope een nieuwe key, dual-write 48 uur, stuur een addendum van één pagina dat verwijst naar een geversioneerd capability schedule, ga over, houd de oude key een week warm. De vorm verandert niet met schaal. Alleen de spreadsheet wel.

Toen we de high-capability AI-agents voor de Antwerpse fintech bouwden, was wat ons in deze migratie bijna in de staart beet niet de verificatie of de cutover. Het was een Pydantic-validator drie hops verderop die crashte op een nieuw audit-veld. We zagen het omdat we twee dagen lang live traffic hebben geschaduwd voordat we de response-bron omzetten. Schaduw je traffic. De rest is papierwerk.

Ben je nog niet begonnen, doe dit dan vandaag: jq over je agent-inventaris, grep op de vier capability-toolnamen hierboven, en zet een rode stip naast alles wat matcht. De rest van het draaiboek leest zich af van die lijst.