Brex CrabTrap: AI-agent-governance via

De fleste forsøg på at styre AI-agenter foregår inde i selve applikationen. En systemprompt, der beder agenten om at opføre sig ordentligt. Et sæt værktøjsdefinitioner, der begrænser, hvad den kan kalde. En menneskelig godkendelse indsat før kritiske handlinger. Jeg har bygget alle tre, og de har alle det samme hul: de virker kun, så længe agenten bliver inden for det lag, du kan se.

Agenter i produktion bliver sjældent der. De finder omveje, kæder værktøjer sammen på måder, ingen forudså, eller trækker data fra kilder, der ikke stod i planen. Brex har derfor lagt kontrolpunktet et lag længere nede, i trafikken mellem agenten og de systemer, den taler med. Hver forespørgsel, et API-kald, en database-forespørgsel, et kald til et internt værktøj, passerer gennem CrabTrap. Det giver ét sted at se al agent-adfærd samlet, uafhængigt af hvilken model eller hvilket framework der driver den enkelte agent. Du behøver ikke stole på, at agenten selv rapporterer, hvad den gjorde. Du ser det direkte i trafikken. Det er den slags synlighed, jeg ikke går i produktion uden.

Her adskiller metoden sig fra klassisk regelbaseret governance. CrabTrap starter i shadow mode. Proxyen logger og analyserer al trafik, men blokerer intet. I den periode bygger systemet et billede af, hvad normal, sikker agent-adfærd faktisk ser ud som i den konkrete organisation. Hvilke API-kald er rutine. Hvilke datakilder rører agenterne typisk. Hvilke handlinger optræder sammen, og hvilke er isolerede afvigelser.

Den observerede adfærd bliver derefter grundlaget for politikken, ikke omvendt. I stedet for at et sikkerhedsteam gætter regler, før agenterne overhovedet kører, lader Brex de faktiske mønstre definere, hvad der er normalt. Det vender risikoarbejdet om. Du behøver ikke forudse alle de måder, en agent kan gå galt på. Du skal bare kunne genkende, når den bevæger sig væk fra sit eget etablerede mønster. Regler skrevet, før du har set agenten arbejde, er gæt. Det har jeg selv betalt for at lære.

Når shadow mode har opbygget nok datagrundlag, kobler Brex et evalueringslag ind. En judge, en LLM-as-a-judge, vurderer konkrete trafikhændelser mod den lærte baseline og afgør, om en handling ligger inden for det acceptable mønster. Ændringer i politikken testes ikke i blinde. Et eval-system kører dem mod historiske logs, så man kan se, hvad en ny regel ville have gjort ved reel, tidligere trafik, før den slippes løs.

Oven på det ligger et feedback-loop lagret i PostgreSQL. Når en ressource gentagne gange bliver afvist, foreslår systemet en justering, i stedet for bare at blive ved med at sige nej. Det er en løbende sløjfe, ikke et engangsprojekt, og det er den del, jeg holder mest af. Alt er sporbart. Du kan se, hvad judgen afgjorde, hvorfor politikken ændrede sig, og hvad der skete med trafikken bagefter. Kan du ikke se, hvad agenten gjorde, har du ikke en medarbejder. Du har et ansvar med god PR.

Et naturligt modargument er ydelse. At sende hvert netværkskald gennem en ekstra evaluering lyder som noget, der kunne bremse et system, hvor agenter i forvejen kæder mange kald sammen i hurtig rækkefølge. Ifølge VentureBeat rammer judge-kaldet i praksis under 3 procent af den samlede trafik.

Det hænger sammen med, hvordan baseline bruges. Langt de fleste hændelser matcher allerede det godkendte mønster og lukkes igennem uden en fuld evaluering. Kun de hændelser, der reelt afviger nok til at være tvivlsomme, sendes videre til judgen. Systemet bruger altså sin dyreste og langsomste komponent sparsomt og fanger stadig de tilfælde, der faktisk betyder noget. Det er den pragmatiske balance mellem sikkerhed og hastighed, som mange governance-forsøg render forbi. Pålidelighed er den eneste feature, der tæller i produktion, og pålidelighed, der koster for meget latens, bliver slået fra i praksis.

For danske virksomheder, der har sat AI-agenter i drift eller overvejer det, er pointen ikke, at du skal bygge din egen CrabTrap. Pointen er erkendelsen bagved. En agent, der har adgang til kundedata, interne systemer eller betalingsflows, opfører sig sjældent præcis, som den blev specificeret til på papiret.

Det praktiske råd, der følger af Brex' tilgang, er at prioritere synlighed før kontrol. Kan du se, hvad agenterne rent faktisk foretager sig, samlet og uafhængigt af den enkelte model, har du et fundament at bygge politik på. Uden den synlighed bliver enhver regel et skud i tågen, og enhver afvigelse opdaget først, når skaden er sket. Det gælder dobbelt her i et lille marked, hvor du ikke kan ansætte dig ud af problemet og GDPR er en forudsætning og ikke en eftertanke. Netværkslaget er ikke det mest oplagte sted at lede efter kontrol. Men det er ofte det eneste sted, der viser sandheden om, hvad en agent gør, uanset hvad den blev bedt om.