Låt inte AI Coding-agenter ärva ditt förtroende

Sedan såg jag kubectl-kommandon köras. Mot ett produktionskluster. Inget gick faktiskt fel. Men det kändes ändå som att något hade gjort det, eftersom min agent på egen hand hade kunnat exfiltrera klusterhemligheter. Den hade åtkomst.

Saken är att det delvis var mitt fel. Agenten fungerade inte fel. Den hade inte löpt amok. Den försökte få så mycket kontext som möjligt för uppgiften den hade fått. Den tittade på ett riktigt kluster för att förstå vad den arbetade med. Helt rimligt. Problemet var att jag hade lämnat nycklarna framme och att den, som ett nyfiket småbarn, hade händer att ta dem med.

När du startar en AI-kodagent från terminalen ärver den hela din miljö. Dina SSH-nycklar, dina molnuppgifter, din kubeconfig, varje projektkatalog på disken. Inte för att du har fattat det beslutet, utan för att det är så en process körs som din användare. Operativsystemet skiljer inte mellan dig och något som körs som du. Det har inget begrepp om att ”den här processen är en agent och bör behandlas annorlunda”. Samma användare, samma förtroende.

Det här är ingen sårbarhet. Det är ingen bugg i agenten. Det är helt enkelt vad som händer när du lämnar saker inom räckhåll för något som inte vet att det inte borde röra dem. Småbarnet vet inte skillnaden mellan en leksak och ditt pass. Det tar upp det som finns där.

Explicit före implicit

Förtroende är inget som uppstår automatiskt inom systemutveckling. Det är något du beslutar om. Du bestämmer vilka system som får kommunicera med vilka andra system. Du bestämmer vilka data som flödar vart. Du bestämmer vilka gränser som finns och varför. De besluten finns i konfiguration, policyer och revisionsloggar – på platser där du kan läsa, granska och ändra dem.

Agentens åtkomstmodell bör fungera på samma sätt. Inte: ”Agenten ärver allt den kan nå, och vi hoppas att inget går fel.” Utan: ”Vi har uttryckligen och skriftligt beslutat exakt vad agenten får åtkomst till, och allt annat är oåtkomligt genom design.”

Det här är principen om minsta behörighet, en grundläggande säkerhetsprincip sedan decennier. Det är också principen om explicit före implicit tillämpad på förtroende i agentbaserade system: standardläget är ingen åtkomst. Åtkomst ges genom ett uttryckligt beslut som dokumenteras och kan granskas. Agentens värld definieras på papper innan den startar.

Det uttryckliga är den största delen av värdet. Inte för att det stoppar beslutsamma angripare, även om det gör det, utan för att det tvingar fram en verklig fråga. Vad behöver den här agenten egentligen? Inte vad den skulle kunna vilja ha. Vad behöver den? När du besvarar det och ser diffen mot baslinjen upptäcker du vad ditt eget system faktiskt gör.

Gör gränserna verkliga

På Linux är låset som faktiskt håller Landlock LSM, en säkerhetsmodul i kärnan som låter oprivilegierade processer införa oåterkalleliga åtkomstbegränsningar för sig själva. Root-behörighet krävs inte. Ingen daemon. Reglerna tillämpas av kärnan innan processen ens startar, och när de väl har tillämpats går de inte att utöka eller ta bort. Varje underordnad process ärver samma begränsningar, hela vägen ned. Du kan inte prompta dig ur det.

Verktyg som nono använder Landlock för att upprätthålla det uttryckliga beslutet. Agenten kommunicerar bara med nätverket via en proxy som övervakaren kontrollerar. Den når bara de sökvägar i filsystemet som policyn uttryckligen ger den åtkomst till. Revisionsspåret – vad agenten gjorde, vad den försökte nå och vad som blockerades – skrivs av övervakaren. Agenten kan inte redigera sin egen historik. Den kan inte utelämna kubectl-anropet. Den kan inte städa upp efter sig.

Sandlådan gör den uttryckliga policyn omöjlig att bryta mot. Agenten kan inte av misstag försöka nå något som du inte har beslutat att ge den. Ännu viktigare är att du får en signal när den försöker. Gränsen är inte bara ett skyddsnät. Den är en observation.

Avgöra vad som är inom räckhåll

För att fatta det uttryckliga beslutet måste du faktiskt veta vad din agent behöver.

nono learn (eller motsvarande verktyg) spårar de verkliga åtkomstmönstren: sökvägar som läses, sökvägar som skrivs till och värdar som kontaktas. Resultatet är ett JSON-fragment som du kan omvandla direkt till en policy. Du gissar inte vad agenten kan tänkas göra. Du observerar och dokumenterar det du ser.

nono profile diff default my-agent

Den diffen är första gången du ser åtkomstmodellen tydligt. Allt agenten behöver, uppräknat innan du ger den nycklarna. Inte nycklarna till hela huset. En specifik nyckel till de specifika rum som faktiskt behövs.

Policydokumentet blir den uttryckliga dokumentationen: den här agenten, den här uppgiften, de här åtkomstgränserna. Du kan läsa det, granska det och lämna det till någon annan för genomläsning. Det finns på en plats där du kan diffa, versionshantera och granska det.

När en agent legitimt behöver åtkomst till något som blockeras som standard ger du den åtkomst uttryckligen:

Båda fälten krävs med avsikt. Att ta bort ett nekande utan att lägga till ett uttryckligt tillåtande är så du får en policy som ser låst ut men inte är det. Processen i två steg är en säkerhetsfunktion. Varje undantag blir medvetet, dokumenterat och synligt i diffen.

Vad jag såg

Efter kubectl-incidenten började jag köra sessioner med en sandlåda på plats. Samma agent, samma repos, andra uppgifter. Skillnaden var att jag nu kunde se vad som hände vid gränsen.

Mängden blockerade försök överraskade mig. Inte kubectl mot produktion. Det är ganska uppenbart. Det var de tystare sakerna. Bash-kommandon och läsanrop som stötte på blockeringar under vad som utifrån såg ut som helt rutinmässigt arbete. Beroendehantering som berörde sökvägar den inte hade någon anledning att vara i närheten av. Filsökningar som drev mot uppgiftsfiler. Inget dramatiskt. Inget som skulle ha synts i utdata eller flaggats som ovanligt beteende. Bara en ständig bakgrund av åtkomstförsök som alltid hade funnits där, i varje session, osynliga eftersom inget någonsin hade stått i vägen.

Det var inte så att agenten gjorde något fel. Oftast gjorde den inte det. Problemet var att jag inte hade någon aning om vad en vanlig session faktiskt försökte komma åt, eftersom jag aldrig hade haft något som kunde visa mig det. Sandlådan förändrade inte agentens beteende. Den gjorde bara åtkomsten synlig för första gången.

De tysta riskerna är värda att oroa sig för. En läsning av ~/.aws/credentials under något som ser ut som en filskanning. Ett steg för beroendeupplösning som kommer åt din kubeconfig. Ett bash-kommando som kontrollerar en miljövariabel. Inget av detta syns i agentens output. Inget av det känns som incidenter. Men de är potentiella mål för exfiltrering vid senare promptinjektioner, när de väl finns i agentens kontextfönster.

Gränsen är signalen. Inte ”något farligt hände”, utan ”något nådde längre än policyn tillät”. Utan gränsen får du inte den signalen. Du får bara en process som gjorde vad den än kunde komma åt, utan någon dokumentation över vart den tog vägen.

Definiera vilka nycklar som ska vara inom räckhåll

kubectl-incidenten var uppenbar eftersom jag råkade titta just då. Det mesta är inte uppenbart. Det mesta är rutinmässiga kommandon som i det tysta läser sådant de inte hade någon anledning att läsa, i sessioner där du inte följde allt noga, mot en bakgrund av åtkomst som aldrig var ett medvetet beslut. Det var bara vad det alltid har inneburit att köra som din användare.

Men det behöver inte fortsätta så. Principen är tydlig: uttryckligt framför underförstått. Agentens åtkomst ska vara ett medvetet beslut, dokumenterat, upprätthållet vid gränsen och möjligt att granska i loggen.

Nästa gång du kör en AI-agent från din terminal, gör det beslutet uttryckligt. Bestäm vad den faktiskt behöver. Skriv ner det. Upprätthåll det med en sandlåda. Se sedan vad som blockeras. Sandlådan förändrar inte vad agenten försöker göra. Men för första gången kan du se vad som alltid har varit inom räckhåll – och för första gången har du ett verkligt val kring vilka nycklar du lämnar på köksbänken.

Nycklarna är dina. Beslutet att ge tillgång till dem ska också vara ditt.