Cloudflares WriteGuard stopper agentens farligste verktøykall før de kjøres

Klokka tolv begynte feilsakene å lukke seg. Ingen tenkte over det, for Joe hadde flyttet noen saker til Ferdig, og Joe hadde tydeligvis en produktiv ettermiddag. Klokka fire var tusenvis av saker lukket, alle av Joe. Slik åpner Cloudflare sitt eget blogginnlegg om WriteGuard, og poenget er hva som skjedde etterpå: det tok en halvtime å spore feilen til én oppryddingsagent blant flere bakgrunnsagenter i tre parallelle sesjoner, og systemet hadde ført alle endringene på Joe uansett hvem som utførte dem.

Cloudflare kjører agenter mot Model Context Protocol internt i stor skala. Da selskapet beskrev sin interne KI-stack i april, koblet portalen sammen 13 MCP-servere. I dag er tallet 27, og team leverer nye hver måned. Alle startet som read-only, slik at agenter kunne søke i Jira, GitLab, wikien og driftssystemer uten å endre noe. Etterspørselen etter verktøy som faktisk kunne utføre handlinger, kom fra engineering, produkt, design, salg og kundeoppfølging samtidig.

«Vi kunne ikke stole på at hver ansatt konfigurerer hver agent perfekt eller følger med på hvert eneste verktøykall» — Cloudflare

WriteGuard er et delt lag for policy, attribusjon og revisjon som sitter mellom klienten og de underliggende serverne. Hvert verktøy får et risikonivå, en av eller på-tilstand og en merkekonfigurasjon. Read Only dekker søk og oppslag. Minimal Impact dekker reaksjoner og varselmerking. Contained Write dekker kommentarer og feltoppdateringer. Critical dekker merge, produksjonsdeploy og masseslettinger. Laget kan slippe kallet gjennom uendret, berike det med agentattribusjon, eller blokkere det før verktøyets handler kjøres.

Identitetsmodellen er verdt å merke seg for deg som bygger noe tilsvarende. Cloudflare valgte bort egne agentkontoer og lot agenten arve den ansattes rettigheter gjennom Cloudflare Access og OAuth. Kan ikke Joe lukke en sak, kan ikke agenten hans det heller. Ulempen er at nedstrømssystemet bare ser Joes legitimasjon, og WriteGuard kompenserer ved å legge på klient- og sesjonskontekst slik at hver skriving fremstår som en agentsesjon på vegne av en bestemt person.

Revisjonssiden er asynkron: hver invokasjon klassifiseres som vellykket, feilet eller blokkert, og sendes til en intern Worker som logger server, verktøy, risikonivå, utfall, bruker, klient og varighet, med hemmeligheter og sensitive verdier vasket bort. Fordi loggingen ikke ligger i svarveien, koster den ingen ekstra latens for agenten som venter.

GitLab-eksempelet viser forskjellen konkret. Et oppslag på en merge request passerer uendret. En kommentar på samme merge request får agentattribusjon i notatfeltet og en revisjonslinje. Et forsøk på å kjøre selve merge-verktøyet blir avvist før handleren kjøres, fordi merge hos Cloudflare utløser deploypipelines og derfor krever et menneske i loopen.

Hva bør du gjøre?

1. Gå gjennom MCP-serverne dine og sorter verktøyene etter hva som skjer hvis kallet gjøres tusen ganger i timen, ikke etter hva det heter. Det er den sorteringen risikonivåene faktisk uttrykker.
2. Legg skrivekontrollen i et delt lag foran serverne i stedet for i hver enkelt server. Cloudflare bygde WriteGuard nettopp fordi de samme kontrollene trengtes for Jira, wikien og Google Workspace, og reimplementering per server gir inkonsistent oppførsel.
3. Slutt å regne med kontroller på klientsiden. Oppførselen varierer mellom klienter, og brukeren kan skru dem av.