Hårda kontroller · Agenter · Utkast
En liten värdagent: ingen modell, ingen inkommande port
Status: detta är en skriven design, ett utkast; ännu inte byggd och inte i bruk. Utrullningen planeras så att först endast fakta och läsning införs, och kommandon sist.
Det mesta som sägs om AI-agenter handlar om vad de kan göra. Den här artikeln handlar om en del som medvetet är utformad för att göra mycket lite: en liten agent som skulle bo på en värd. Den skulle inte innehålla någon modell. Den skulle rapportera fakta om värden, bara köra kommandon från en fast lista, ta sina instruktioner som signerade meddelanden över git och inte lyssna på någon inkommande port.
Det är det minsta exemplet på tanken som löper genom den här serien: när du inte kan göra en komponent pålitlig genom att be den snällt, gör den så liten att det finns lite att lita på.
Vad den är till för
Vissa värdar styrs inte av en AI-assistent alls. De behöver ändå vara kända och, på smala sätt, skötta: vad som körs på dem, vilket tillstånd de är i och en handfull rutinåtgärder. Den lilla värdagenten är utformad för att sitta på en sådan värd och göra exakt det och inget mer.
Den skulle göra tre saker. Den skulle rapportera fakta om värden. Den skulle ta emot instruktioner som signerade meddelanden. Den skulle bara köra ett kommando om kommandot finns på dess tillåtelselista.
Varför varje designval
Varje val finns där för det det tar bort från angreppsytan.
Ingen modell. En modell går att argumentera med: text den läser kan styra vad den gör. Ett litet fast program kan inte övertalas till en åtgärd, och det är så litet att en människa kan läsa och granska det i ett svep. Att ta bort modellen tar bort en hel klass av manipulation från värden.
En tillåtelselista. Agenten skulle vägra varje kommando som inte finns på listan. Ett misstag, ett felaktigt meddelande eller en förfalskad begäran kan då bara nå det listan tillåter. Okänt betyder nekat.
Signerade meddelanden. Värden skulle bara agera på instruktioner vars signatur den kan verifiera. Att kunna nå kanalen räcker inte; bara den som håller signeringsnyckeln kan instruera värden.
Git som kanal. Värden skulle fråga git efter nya meddelanden, i stället för att vänta på att bli anropad. Varje instruktion blir en commit, så historiken är en post över vad som efterfrågades och av vem, och transporten behöver ingenting särskilt.
Ingen inkommande port. Eftersom värden alltid skulle sträcka sig ut och ingenting skulle nå in finns ingen lyssnande tjänst att skanna, sondera eller utnyttja från nätverket.
Ett meddelande, fem fasta steg
Varje meddelande skulle gå igenom samma steg i samma ordning: hämta det, verifiera signaturen, kontrollera kommandot mot tillåtelselistan, köra det enda listade kommandot, rapportera resultatet och värdens fakta. Om något steg misslyckas stannar meddelandet där. Osignerat, okänt eller olistat betyder att ingenting körs, och det finns inget omdöme i mitten som någon kan luta sig mot.
Vad det skulle kosta
Litet och strikt har ett pris.
- Flexibilitet. En ny sorts uppgift betyder en ny post på tillåtelselistan, som måste skrivas och granskas. Det är poängen, och också friktion.
- Nyckelhantering. Signering kräver nycklar: någon måste skapa dem, förvara dem säkert, avgöra vem som får signera och byta ut dem vid behov. Designen kräver att det arbetet görs väl; hur signeringsnyckeln hålls är en öppen designpunkt, och den här artikeln beskriver ingen uppsättning.
- Hastighet. En värd som hämtar med jämna mellanrum får veta om en instruktion vid nästa hämtning, inte omedelbart.
- Beroende av git. Kanalen beror på att git-tjänsten är nåbar och fungerar som den ska.
- Diagnos. Ett fast program med snäv utdata säger lite när något går fel, så rapportering och loggning kräver omsorg.
Vad den här designen inte skyddar mot
Att namnge gränserna är viktigare än att lista styrkorna.
Signeringsnyckeln. Den som håller signeringsnyckeln kan skicka giltiga meddelanden. Tillåtelselistan begränsar vad de kan be om, men en skadlig åtgärd som står på listan skulle utföras. Hur nyckeln hålls, och hur den skulle bytas ut, är en öppen designpunkt.
Återuppspelning. Ett äkta signerat meddelande kan skickas igen senare. Designen kräver ett sätt att skilja färska meddelanden från gamla, till exempel ett utgångsdatum eller en räknare; utan det är återuppspelning möjlig.
En komprometterad git-tjänst. Tjänsten kan inte förfalska signaturer, men den kan hålla inne meddelanden, fördröja dem eller visa gamla. Det påverkar tillgänglighet och aktualitet, inte äkthet.
En dålig tillåtelselista. Tillåtelselistan är den verkliga behörighetsgränsen. Den är bara så säker som sina poster och de argument de accepterar; en bred post är en bred behörighet.
En komprometterad värd. En värd som har tagits över kan rapportera falska fakta om sig själv. Skadan begränsas till värdens egna sökvägar: den skulle inte nå andra värdar genom den här designen.
Dessa risker skulle minskas med små tillåtelselistor med fasta argument, färska meddelanden, noggrann hantering av nycklar och övervakning av det värden rapporterar. De tas inte bort.
Hur den passar in i resten av serien
Värdagenten skulle vara det understa lagret i samma bild. Agenter ovanför föreslår, människor godkänner, och signerade, registrerade meddelanden för det godkända ner. Längst ned skulle det finnas en del som följer sin lista och för en post, och som har lite annat att angripa.