Låt AI köra servern, inte ha sönder den

Atlas kan öppna sin egen Model Context Protocol server, för den som vill, och erbjuder ett kommandofält i panelen. Det är en egen komponent: den följer inte med installationen, den som vill lägger till den med en knapp i panelen, och på en maskin som inte vill ha den finns den inte alls. När den är tillagd läses serverns tillstånd, ett fel gås igenom och arbete utförs genom att skriva vad man vill. Gränsen dras av Proxmox: det en användare får röra vid rör modellen också, inte mer. Något nytt behörighetsbegrepp tillkommer inte. Modellen kopplas till Atlas, inte till Proxmox. Proxmox ligger under, men modellen når aldrig dit direkt; den använder bara det Atlas kan.

Vad det kostar i dag att ge en modell åtkomst till servern

I dag finns bara en väg för att en AI-assistent ska kunna arbeta med Proxmox: ge den en SSH-session eller en API-nyckel med fulla rättigheter. Det innebär att lämna över root, och därefter står ingenting mellan modellen och hårdvaran.

Risken kommer av saknad kontext, inte av ont uppsåt. En modell kan se en disk som tom och behandla den som borttagbar, fast den hör till en maskin som bara är avstängd. Den kan läsa en degraderad pool och föreslå att bygga om den, fast rätt steg är att byta en disk. Kommandot skrivs korrekt och resultatet blir dataförlust.

Därför hålls modellen utanför servern i seriösa miljöer. Förlusten syns i diagnosen: att läsa långa loggar och hitta vad som gick sönder är precis vad en modell är bra på, och precis det arbetet blir ogjort.

Vad som kan frågas

I panelens kommandofält ställs frågor och ges uppdrag, som ett enda samtal. Exemplen nedan är frågesidan: modellen läser serverns tillstånd och svarar med posten den stödde sig på, och i dem ändras ingenting.

Varför misslyckades säkerhetskopian i natt, vid vilket steg stannade den, fanns det plats på mållagringen?

Varför har den här virtuella maskinen varit långsam sedan i går kväll, sitter flaskhalsen i processorn eller i disken?

Varför är poolen degraderad, vilken disk föll bort, är data i fara just nu?

Vilken av de väntande uppdateringarna kräver omstart och vilka tjänster stoppar den?

Vad betyder det här felet i loggen, har det hänt förut, upprepas det?

I den här takten, när tar kapaciteten slut, vilken maskin växer snabbast?

Vad som kan utföras

Det kallas VibeOps: att styra en server genom samtal. Vibe coding är att skriva utan att läsa koden, och på Proxmox går det inte, så här förblir varje steg synligt. I samma fält utförs också arbetet. Önskemålet skrivs in. Atlas rapporterar först vad som ska göras och var det tar i: stegen, maskinerna och lagringarna som berörs, och vägen tillbaka. Arbetet utförs efter godkännande. Något nytt behörighetsbegrepp tillkommer inte: kommandofältet arbetar med behörigheterna för det Proxmox-konto det ansluter som. Den som vill ha en smalare modell ger den ett snävt Proxmox-konto, och omfattningen står i det kontots behörigheter. Vid behov stängs skrivning av för den egna sessionen och bara läsning återstår. Varje steg hamnar i granskningsloggen.

Ge den här maskinen två kärnor till och höj minnet till åtta gigabyte.

Lägg upp en säkerhetskopia klockan tre på natten för alla maskiner i den här poolen.

Installera de väntande säkerhetsfixarna, lämna de som kräver omstart till underhållsfönstret.

Sätt omstartsregeln för den containern till alltid.

Ge den här användaren bara rätt att säkerhetskopiera, inget annat.

Flytta den disken till den nya poolen, ta en ögonblicksbild innan flytten.

Modellen går genom samma dörr som en människa

MCP-servern öppnar ingen sidoväg. Samma skydd som Atlas redan kör för den mänskliga användaren gäller modellen, i samma ordning.

Behörigheter kommer från Proxmox

Modellen arbetar med rättigheterna för den användare den ansluter som, inte med ett eget konto. Det Proxmox stänger för den användaren förblir stängt för modellen. Atlas bygger inget eget rättighetssystem.

Proxmox-kontot sätter omfattningen

Kommandofältet arbetar med behörigheterna för det Proxmox-konto det ansluter som; Atlas inför inget eget behörighetsbegrepp. Den som vill ha en snäv omfattning ger det ett snävt konto, och den omfattningen står i kontots behörigheter och läses tillbaka därifrån vid en granskning. Att stänga av skrivning för sin egen session är ett enda grepp.

Effekten visas först

När en ändring föreslås visas stegen som ska köras, resurserna som berörs och vägen tillbaka för en människa. Godkännandet sker på skärmen, inte inne i samtalet.

Hård bekräftelse för det som inte går att ångra

Saknar kontot det ansluter som behörighet går det inte alls att radera, formatera eller riva en pool. Där behörigheten finns gäller fortfarande den hårda bekräftelse produkten använder på andra ställen: namnet skrivs in för att bekräfta, ett klick räcker inte. Den som vill ha ytterligare ett steg slår på det: skrivningar kräver en engångskod, samma tvåstegsverifiering som kontot redan använder.

Varje steg antecknas

Allt modellen läser och varje åtgärd den ber om hamnar i granskningsloggen: vilken användare, vilken modell, när och med vilket resultat. Posten går inte att ändra i efterhand.

Svaren visar sin källa

Modellen säger varifrån slutsatsen kommer: vilken loggrad, vilken mätning, vilken konfiguration. Ett svar som inte går att kontrollera räknas inte som svar.

Vad modellen inte kan göra

Gränserna bor i produkten, inte i samtalet. Hur modellen tillfrågas, eller hur hårt någon försöker övertala den, spelar ingen roll. I en organisation som kopplar in sin egen modell gäller samma gränser, eftersom regeln drivs igenom i servern och inte i modellen.

Den kan inte vidga sina egna rättigheter eller skapa användare och åtkomstnycklar.

Den kan inte köra någon skrivåtgärd utan godkännande.

Om kontot det ansluter som saknar skrivbehörighet ändrar den ingenting och läser bara.

Den kan inte öppna ett skal på servern eller hamna på kommandoraden. Det behövs sällan, eftersom även arbete som kräver djup täcks: från ZFS-poolen till Ceph, från bryggan till OVS, från att låsa kärnan till att dela ut behörigheter, och täckningen växer med varje version. För det sällsynta jobb som hamnar utanför skriver den kommandot och förklarar risken, och körningen sker manuellt.

Den kan inte radera eller ändra granskningsposten.

Vart datan tar vägen

MCP-servern är en egen komponent och ingår inte i standardinstallationen. Den läggs till med en knapp i panelen; på en maskin som inte vill ha den finns inte ens en fil av den. Efter installationen är det fortfarande kunden som avgör vilka resurser den får titta på och hur länge den står öppen.

Vilken modell den ansluter till väljer kunden också. Med en lokal modell som kör på servern själv lämnar ingen data maskinen och produkten förblir offline. Väljs en extern tjänst syns innehållet som ska skickas innan det skickas.

För organisationer under sträng reglering

Ingen certifiering påstås. Produkten är utformad för att möta kraven i ramverk med hårda granskningsvillkor, och en organisations egen granskning kan använda beteendena som bevis.

Ledningssystem för AI (ISO/IEC 42001): vad modellen får göra står skrivet, gränserna drivs igenom i produkten, varje användning antecknas.

Informationssäkerhet (ISO/IEC 27001): åtkomsten kommer från det identitetssystem som redan finns, rättigheter följer minsta behörighet, poster är oföränderliga.

AI-riskhantering (ISO/IEC 23894 och NIST AI RMF): ingen självständig handling, mänskligt godkännande är ett obligatoriskt steg i flödet.

Personuppgifter (GDPR och motsvarande): data stannar på kundens maskin; ska den ut syns det först och beslutet är kundens.

Kritisk infrastruktur (NIS2 och krav på öppenhet kring AI): efter en händelse går det att läsa tillbaka vem som gjorde vad, vad modellen föreslog och vem som godkände.

Vanliga frågor