← Essäer

Gränser istället för instruktioner: hur man behåller kontrollen över autonoma AI-agenter

Varför kontroll över AI-agenter inte kan byggas på instruktioner i prompten — och hur man bygger den på tekniska gränser. Fem incidenter under en session.

6 min läsning
TelegramOriginal
Gränser istället för instruktioner: hur man behåller kontrollen över autonoma AI-agenter

Ju mer autonoma AI-agenterna blir, desto oftare försöker vi styra dem på det invanda sättet — vi skriver regler i prompten: ”rör inte det här”, ”arbeta bara där”, ”gör aldrig det där”. Under experimentet med tre parallella agenter samlade jag under två dagar en levande samling fall där detta sätt brister — och där ett annat fungerar. Artikelns tes är enkel: en instruktion är en begäran som agenten utför med viss sannolikhet; en gräns är en egenskap hos systemet som inte beror på lydnad. När agenten var en enda och arbetade under uppsikt verkade skillnaden stilistisk. När agenterna blev många visade den sig vara arkitektonisk.

Fem incidenter under en session

Alla fall nedan inträffade under en och samma arbetssession på den här bloggen — de är dokumenterade, och var och en illustrerar sitt sätt på vilket styrning via text sviker.

Det fanns ingen instruktion — och en olycka inträffade. Agenten utförde, i förberedelse för sin uppgift, git stash i den gemensamma katalogen och lade mina ej committade filer, som inte hörde till dess uppgift, i stashen. Ingen ”bröt” mot något: förbudet fanns helt enkelt inte. Detta är en grundläggande egenskap hos instruktioner — de skrivs efter olyckor. En fullständig lista över vad agenten inte får göra går inte att skriva.

Instruktionen fanns — och fungerade inte. Efter den första olyckan lade jag till en explicit regel för agenterna: ”arbeta strikt i din egen arbetskatalog”. En av agenterna utförde ändå ett git-kommando i huvudkatalogen — den hänvisade helt enkelt till den via absolut sökväg. Inte av illvilja och inte av dumhet: modellen är probabilistisk, och efterlevnad av en textregel är också en sannolikhet, multiplicerad med kontextlängden och antalet körningar.

Den tekniska gränsen fungerade tyst. I samma experiment inträffade aldrig den mest förväntade olyckan — ”en agent bytte branch för alla”. Inte för att agenterna var försiktiga, utan för att git worktree fysiskt inte tillåter att en branch checkas ut i två arbetskopior. Skyddet är inbyggt i verktyget. Man behöver inte komma ihåg det, man behöver inte följa det — det finns bara.

Instruktionen stod där gränsen borde stå. Den obehagligaste upptäckten: den här bloggens prod skyddades av en rad i prompten. En push till master utlöser autodeploy, och från varje agent skildes den bara av texten ”ingen git push”. Den höll — men det var tur, inte kontroll: den verkliga gränsen här är åtkomsträttigheter, protected branch, en token utan skrivrätt. En begäran stod på ett lås plats.

En gräns ovanpå agenten själv. Två gånger under sessionen stoppade körmiljön inte försöksagenterna utan min huvudassistent: en behörighetsklassificerare blockerade SSH till prod-servern och massradering av ej committade ändringar — åtgärder som formellt följde av uppgiften men krävde ett explicit mänskligt ”ja”. Båda blockeringarna var korrekta. Och båda inträffade ovanpå agentens ”disciplin”, som ganska uppriktigt ansåg att den handlade enligt plan.

Principen är inte ny — bara entiteten är ny

Ingenjörskonsten lärde sig den här läxan långt före LLM. I Toyotas produktionssystem kallas principen poka-yoke: det är processens utformning som förhindrar felet, inte utförarens vaksamhet. En detalj som bara kan sättas in åt rätt håll är pålitligare än en affisch med texten ”sätt in rätt”. Inom plattformsingenjörskonst kallas samma sak guardrails, inom säkerhet defense in depth. Överallt samma tanke: förlita dig inte på att utföraren har läst, förstått och inte glömt — se till att den felaktiga åtgärden är omöjlig eller dyr.

”En instruktion är en begäran. En gräns är en egenskap hos systemet. Kontroll som vilar på begäranden är inte kontroll, utan tur med kumulativ effekt.”

– huvudslutsatsen från två dagars arbete med parallella agenter

Med AI-agenter blir denna gamla princip skarpare av tre skäl. Agenterna är många — sannolikheten för att instruktionen sviker multipliceras för varje körning av varje agent. Agenterna är snabba — mellan ”började göra fel” och ”förstörde resten” går det sekunder, människan hinner inte ingripa. Och agenterna är bokstavliga men inte pålitliga: de utför promptens text flitigare än någon junior, och ändå probabilistiskt — och probabilistisk regelefterlevnad i skala garanterar överträdelse.

Hur gränser ser ut i praktiken

Lagren jag byggde upp efter den här sessionen — från filsystem till verifiering:

  • Filsystem: varje agent får en egen arbetskopia (git worktree, som Anthropic rekommenderar för parallella sessioner, och som är inbyggt i Claude Code), och på OS-nivå en sandlåda: sandboxing i Claude Code isolerar filsystem och nätverk med OS:ets inbyggda primitiver — enligt Anthropic minskade detta deras interna behörighetsförfrågningar med 84%, och en lyckad prompt-injection förblir inlåst.
  • Skrivrättigheter: prod och master skyddas av rättigheter, inte av prompten — protected branch, tokens utan push-rätt, separata konton för agenter. Önskemål att lämna kvar i prompten går bra, men som ett andra lager.
  • Runtime: worktree isolerar inte databaser, portar och containrar — de är gemensamma för alla kopior. Agenter som kör tester och servrar behöver engångsresurser: en tillfällig databas, en egen port, en container per agent.
  • Behörigheter för åtgärder: oåterkalleliga operationer går genom bekräftelse eller en klassificerare — som auto mode i Claude Code, som bedömer varje åtgärd i stället för att antingen fråga om allt eller inte fråga om något. Det är en gräns som bara flyttas genom ett uttryckligt mänskligt beslut.
  • Verifiering via artefakter: lita inte på agentens egen rapport, utan på spåren på disken. Min hängda agent såg fungerande ut i gränssnittet; diagnosen ställdes av avsaknaden av nya filer i dess kopia under tjugo minuter. Commits till en egen gren är samma idé: ett resultat som överlever både krascher och agentens optimism.

Instruktionerna i detta upplägg försvinner inte någonstans — de blir det sista lagret, inte det första. "Arbeta i din egen katalog" i prompten är fortfarande användbart: det minskar frekvensen av försök. Men mellan försöket och haveriet måste det stå en gräns, inte en förhoppning.

Ärliga förbehåll

Gränsen är inte absolut: sandlådor kringgås, klassificerare gör fel, och publicerade genomgångar av kringgåenden visar detta regelbundet. Därför byggs gränser i lager — som allt inom säkerhet. Och en gräns kostar mer än en instruktion vid start: att sätta upp worktree, rättigheter och sandlåda tar timmar, att skriva en rad i prompten tar sekunder. Asymmetrin ligger i något annat: gränsen betalas en gång, instruktionen — med sannolikheten för fel vid varje körning. För mig lönade sig isoleringsuppsättningen redan vid den första omstarten av experimentet, som gick igenom utan en enda konflikt.

Slutsats

Seriens fråga är hur AI-agenter ska byggas in i det verkliga arbetet utan att tappa kontrollen. Svaret i den här artikeln: kontroll är inte det som står skrivet till agenten, utan det som är uppbyggt runt den. Innan du lägger till ännu ett "gör aldrig X" i prompten är det värt att fråga sig: går det att göra X tekniskt omöjligt? Om ja — då är det rätt ställe för ansträngningen. Låt prompten be; systemet ska förbjuda.

Källor och riktmärken

← Alla essäer