La KI kjøre serveren, ikke ødelegge den

Atlas kan åpne sin egen Model Context Protocol server, for den som ønsker det, og tilbyr et kommandofelt i panelet. Det er en egen komponent: den følger ikke med installasjonen, den som vil ha den legger den til med én knapp i panelet, og på en maskin som ikke vil ha den finnes den ikke i det hele tatt. Når den er lagt til, leses tilstanden på serveren, en feil gås gjennom og arbeid utføres ved å skrive hva man vil. Grensen trekkes av Proxmox: det en bruker får røre ved, rører modellen også, ikke mer. Det kommer ingen ny rettighetsforestilling til. Modellen kobles til Atlas, ikke til Proxmox. Proxmox ligger under, men modellen når aldri dit direkte; den bruker bare det Atlas kan.

Hva det koster i dag å gi en modell tilgang til serveren

I dag finnes bare én vei for at en KI-assistent skal kunne arbeide med Proxmox: gi den en SSH-økt eller en API-nøkkel med fulle rettigheter. Det betyr å gi fra seg root, og fra da av står ingenting mellom modellen og maskinvaren.

Risikoen kommer av manglende sammenheng, ikke av vond vilje. En modell kan se en disk som tom og behandle den som fjernbar, selv om den hører til en maskin som bare er slått av. Den kan lese en degradert pool og foreslå å bygge den opp igjen, selv om riktig steg er å bytte én disk. Kommandoen skrives korrekt og resultatet blir tap av data.

Derfor holdes modellen utenfor serveren i seriøse miljøer. Tapet viser seg i diagnosen: å lese lange logger og finne hva som gikk i stykker er nettopp det en modell er god til, og nettopp det arbeidet blir ikke gjort.

Hva som kan spørres om

I panelets kommandofelt skjer både spørsmål og utførelse, som én samtale. Eksemplene nedenfor er spørresiden: modellen leser tilstanden på serveren og svarer med oppføringen den støttet seg på, og i dem endres ingenting.

Hvorfor feilet sikkerhetskopien i natt, ved hvilket steg stoppet den, var det plass på mållagringen?

Hvorfor har denne virtuelle maskinen vært treg siden i går kveld, ligger flaskehalsen i prosessoren eller på disken?

Hvorfor er poolen degradert, hvilken disk falt ut, står data i fare nå?

Hvilken av de ventende oppdateringene krever omstart, og hvilke tjenester stopper den?

Hva betyr denne feilen i loggen, har den skjedd før, gjentar den seg?

I dette tempoet, når går kapasiteten full, hvilken maskin vokser raskest?

Hva som kan utføres

Dette kalles VibeOps: å styre en server gjennom samtale. Vibe coding er å skrive uten å lese koden, og på Proxmox går ikke det, så her forblir hvert steg synlig. I det samme feltet utføres også arbeidet. Ønsket skrives inn. Atlas melder først hva som skal gjøres og hvor det griper inn: stegene, maskinene og lagringene som berøres, og veien tilbake. Arbeidet utføres etter godkjenning. Det kommer ingen ny rettighetsforestilling til: kommandofeltet arbeider med rettighetene til Proxmox-kontoen det kobler seg til som. Den som vil ha en smalere modell gir den en snever Proxmox-konto, og omfanget står i rettighetene til den kontoen. Skriving kan også slås av for den enkelte økten, slik at bare lesing står igjen. Hvert steg havner i revisjonsloggen.

Gi denne maskinen to kjerner til og øk minnet til åtte gigabyte.

Sett opp sikkerhetskopi klokken tre om natten for alle maskiner i denne poolen.

Installer de ventende sikkerhetsoppdateringene, la de som krever omstart vente til vedlikeholdsvinduet.

Sett omstartsregelen for den containeren til alltid.

Gi denne brukeren bare rett til sikkerhetskopiering, ingenting annet.

Flytt den disken til den nye poolen, ta et øyeblikksbilde før flyttingen.

Modellen går gjennom samme dør som et menneske

MCP-serveren åpner ingen sidevei. De samme beskyttelsene Atlas allerede kjører for den menneskelige brukeren gjelder modellen, i samme rekkefølge.

Rettigheter kommer fra Proxmox

Modellen arbeider med rettighetene til brukeren den kobler seg til som, ikke med en egen konto. Det Proxmox stenger for den brukeren forblir stengt for modellen. Atlas bygger ikke sitt eget rettighetssystem.

Proxmox-kontoen setter omfanget

Kommandofeltet arbeider med rettighetene til Proxmox-kontoen det kobler seg til som; Atlas innfører ingen egen rettighetsforestilling. Den som vil ha et snevert omfang gir det en snever konto, og det omfanget står i kontoens rettigheter og leses tilbake derfra ved en revisjon. Å slå av skriving for sin egen økt er ett grep.

Virkningen vises først

Når en endring foreslås, vises stegene som skal utføres, ressursene som berøres og veien tilbake for et menneske. Godkjenningen skjer på skjermen, ikke inne i samtalen.

Hard bekreftelse for det som ikke kan angres

Har kontoen den kobler seg til som ingen rettighet, er sletting, formatering og riving av en pool ikke mulig i det hele tatt. Der rettigheten finnes, gjelder fortsatt den harde bekreftelsen produktet bruker andre steder: navnet må skrives inn for å bekrefte, ett klikk holder ikke. Den som vil ha enda et steg slår det på: skriving krever en engangskode, den samme tostegsbekreftelsen kontoen allerede bruker.

Hvert steg føres

Alt modellen leser og hver operasjon den ber om havner i revisjonsloggen: hvilken bruker, hvilken modell, når og med hvilket resultat. Oppføringen kan ikke endres i etterkant.

Svarene viser kilden sin

Modellen sier hvor slutningen kommer fra: hvilken loggrad, hvilken måling, hvilken konfigurasjon. Et svar som ikke kan sjekkes teller ikke som svar.

Hva modellen ikke kan gjøre

Grensene bor i produktet, ikke i samtalen. Hvordan modellen spørres, eller hvor hardt noen prøver å overtale den, spiller ingen rolle. I en organisasjon som kobler til sin egen modell gjelder de samme grensene, for regelen håndheves i serveren og ikke i modellen.

Den kan ikke utvide sine egne rettigheter eller lage bruker og tilgangsnøkkel.

Den kan ikke utføre noen skriveoperasjon uten godkjenning.

Har kontoen den kobler seg til som ingen skriverettighet, endrer den ingenting og bare leser.

Den kan ikke åpne et skall på serveren eller havne på kommandolinjen. Det trengs sjelden, for arbeid som krever dybde er også dekket: fra ZFS-poolen til Ceph, fra broen til OVS, fra å låse kjernen til å dele ut rettigheter, og dekningen vokser med hver versjon. For den sjeldne jobben som faller utenfor, skriver den kommandoen og forklarer risikoen, og kjøringen skjer manuelt.

Den kan ikke slette eller endre revisjonsoppføringen.

Hvor dataene går

MCP-serveren er en egen komponent og hører ikke til standardinstallasjonen. Den legges til med én knapp i panelet; på en maskin som ikke vil ha den finnes ikke engang en fil av den. Etter installasjonen er det fortsatt kunden som avgjør hvilke ressurser den får se på og hvor lenge den står åpen.

Hvilken modell den kobles til velger kunden også. Med en lokal modell som kjører på serveren selv forlater ingen data maskinen, og produktet forblir uten nett. Velges en ekstern tjeneste, er innholdet som skal sendes synlig før det sendes.

For organisasjoner under streng regulering

Ingen sertifisering hevdes. Produktet er utformet for å møte kravene i rammeverk med harde revisjonsvilkår, og en organisasjons egen revisjon kan bruke oppførselen som bevis.

Styringssystem for KI (ISO/IEC 42001): hva modellen får gjøre står skrevet, grensene håndheves i produktet, hver bruk føres.

Informasjonssikkerhet (ISO/IEC 27001): tilgangen kommer fra identitetssystemet som allerede finnes, rettigheter følger minste privilegium, oppføringer er uforanderlige.

KI-risikostyring (ISO/IEC 23894 og NIST AI RMF): ingen selvstendig handling, menneskelig godkjenning er et påkrevd steg i flyten.

Personopplysninger (GDPR og tilsvarende): data blir på kundens maskin; skal de ut, synes det først og valget er kundens.

Kritisk infrastruktur (NIS2 og åpenhetskrav om KI): etter en hendelse kan man lese tilbake hvem som gjorde hva, hva modellen foreslo og hvem som godkjente.

Ofte stilte spørsmål