Varför read-only är mitt defaultläge för nya AI-agenter
När jag kopplar en ny agent till ett riktigt system börjar jag nästan alltid med en begränsning som kan kännas tråkig: den får läsa, men inte skriva. Inte för att modellen är oanvändbar. Tvärtom. Read-only är ett sätt att låta modellen visa vad den kan innan jag gör dess misstag irreversibla.
När jag kopplar en ny agent till ett riktigt system börjar jag nästan alltid med en begränsning som kan kännas tråkig: den får läsa, men inte skriva. Inte för att modellen är oanvändbar. Tvärtom. Read-only är ett sätt att låta modellen visa vad den kan innan jag gör dess misstag irreversibla.
Det här är en annan fråga än om modellen "är bra nog". En agent kan vara imponerande på resonemang och ändå göra fel verktygsval, tolka en instruktion för brett eller agera på manipulerad kontext. Det viktiga i första fasen är därför inte maximal autonomi utan observerbarhet.
Read-only ger mig felbilder utan blast radius
I ett nytt workflow vill jag först se vilka typer av beslut agenten faktiskt fattar. Den får söka, läsa, sammanställa och föreslå. Jag kan då logga:
- vilken information den hämtade,
- vilka antaganden den gjorde,
- vilket verktyg den ville använda,
- vad den skulle ha ändrat,
- när den borde ha avstått.
Det ger en dataset av verkliga fel innan agenten har rätt att orsaka dem i produktion.
I contentfabriken för BijoyIQ syns samma princip som separation of duties. Researcher kan samla underlag. Writer kan skriva ett draft från godkänd evidens. Publisher Gate kan sätta status. Ingen av de rollerna får hoppa över hela kedjan och publicera på egen hand.
Jag delar upp access i tre nivåer
Min praktiska modell är enklare än många permissionsramverk.
Nivå 1: Read. Läs filer, hämta dokumentation, sök poster, skapa analys.
Nivå 2: Prepare. Skapa ett utkast till förändring, diff, draft, SQL eller åtgärdsplan, men utför den inte.
Nivå 3: Act. Skicka, publicera, skriva över, radera, ändra behörighet eller trigga ett externt system.
Jag försöker bevisa behovet för varje förflyttning uppåt. En agent som klarar nivå 1 får inte automatiskt nivå 3 bara för att demon såg bra ut.
OpenAI rekommenderar i sin agentguide att verktyg riskklassas bland annat utifrån read-only kontra write access, reversibilitet, kontobehörighet och finansiell påverkan. OWASP:s kategori Excessive Agency utgår från samma grundproblem: skadan avgörs inte bara av vad modellen säger, utan av vad systemet låter den göra.
"Prepare" är ofta den mest underskattade nivån
Det finns en frestelse att tänka binärt: antingen autonom agent eller vanlig chatbot. Jag använder ofta ett mellanläge där agenten gör nästan allt arbete men människan äger sista side effect.
Exempel:
Det är fortfarande mycket automation. Men det svåraste felet — att fel meddelande faktiskt skickas — ligger bakom en separat gate.
När jag höjer behörigheten
Jag vill normalt se tre saker innan write access införs.
För det första behöver felmoderna vara kända. Inte teoretiskt kända, utan observerade i realistiska testfall. För det andra ska handlingen vara tillräckligt reversibel eller ha en tydlig approval-mekanism. För det tredje behöver systemet logga vem eller vad som gjorde förändringen och med vilket underlag.
Det här gör rollout långsammare de första dagarna men snabbare senare. Om jag går direkt till bred write access blir varje fel en incidentfråga. Om jag börjar read-only blir samma fel ett eval-exempel.
Read-only är inte slutmålet
Jag förespråkar inte agenter som aldrig får göra något. Värdet med agenter uppstår ofta just när de kan genomföra arbetssteg. Poängen är att autonomi ska förtjänas per handling, inte delas ut som en egenskap till hela agenten.
Jag vill alltså inte fråga: "Litar jag på den här modellen?" Jag vill fråga: "Vilken exakt handling får den göra, med vilka data, inom vilken state, och vad händer om den har fel?"
Det är en mycket mer användbar säkerhetsfråga.