At give en AI-assistent adgang til Proxmox: hvor grænsen skal ligge

Der er en ægte og lidt irriterende skævhed her. At læse to tusind loglinjer og finde linjen, hvor noget gik i stykker, er præcis hvad en sprogmodel er god til. Det er samtidig præcis det arbejde, de fleste ikke kan lade den udføre, på grund af måden adgang gives på.

Spørgsmålet er ikke, om en model skal røre en server. Det er hvor grænsen ligger, og i dag ligger den som regel det forkerte sted.

Hvorfor den sædvanlige opsætning er ubehagelig

Der er to almindelige måder at koble en assistent til Proxmox på: give den en SSH-session eller en API-nøgle med fulde rettigheder. Begge løber ud i det samme. Fra det øjeblik står intet mellem modellen og hardwaren, og al beskyttelse lever i ordlyden af en instruktion.

En instruktion er ingen grænse. Det er en anmodning til et system, der er bygget til at være hjælpsomt, på et sprog uden tvangskraft.

Risikoen er manglende kontekst, ikke ond vilje

Det er her, diagnosen bliver forkert. Fejlformen er sjældent en model, der beslutter sig for at gøre skade. Det er en model, der handler korrekt på et ufuldstændigt billede.

En disk, der ser tom ud. Modellen læser en enhed uden monteret filsystem og regner den for ledig. Enheden hører til en maskine, der ganske enkelt er slukket.

En degraderet pool. Modellen læser den degraderede tilstand og foreslår at genopbygge samlingen. Det rigtige skridt var at udskifte én disk, og genopbygningen er måden, de resterende data går tabt på.

En tjeneste, der "ikke kører". Den kører ikke, fordi den kører efter plan og er færdig. At genstarte den er harmløst; at slå den fra, fordi den "hele tiden stopper", er det ikke.

I alle tre er kommandoen skrevet korrekt. Det, der er forkert, er præmissen, og en korrekt kommando på en forkert præmis kan bagefter ikke skelnes fra sabotage.

Kun læsning hjælper, og er ikke hele svaret

Det oplagte svar er læseadgang, og det fjerner virkelig de værste udfald. To ting står tilbage.

At læse er ikke gratis. Konfiguration, logfiler og revisionsspor indeholder værtsnavne, adresser, brugernavne og af og til nøgler, der er indsat, hvor de ikke burde. En assistent med fuld læseadgang er en eksport af din infrastruktur.

Diagnose uden handling stopper halvvejs. Er det nyttige svar "genstart lige den her tjeneste", giver en læseopsætning fundet tilbage til et menneske, der skal skrive det af. Det er fint, og det er også derfor, rettigheder senere udvides i stilhed.

Kun læsning er altså en god start og et dårligt mål. Målet er smal skriveadgang gennem de samme porte, et menneske passerer.

Hvor grænsen faktisk hører hjemme

Ikke i instruktionen og ikke i modellen. I laget, der udfører, for det er det eneste sted, der kan nægte.

Tre egenskaber gør et sådant lag troværdigt, og alle tre kan kontrolleres i stedet for at blive lovet.

Rettigheder kommer fra systemet, der allerede har dem. Forbinder assistenten sig med en eksisterende konto, er det, den konto må røre, præcis det, assistenten må røre. Der opfindes ikke en anden rettighedsmodel, så der er intet at holde synkront og ingen måde, hvorpå de to kan modsige hinanden.

Ødelæggende handlinger passerer samme port som et menneske. Hvis det at slette en disk beder et menneske om bekræftelse, skal det også bede, når en model anmoder om det. En vej, der er sikker for mennesker og åben for automatik, er ingen grænse, det er en genvej med et pænt navn.

Hvert skridt lander i revisionsloggen. Hvem, hvad, hvornår, på hvad og med hvilket resultat. Uden det har det egentlige spørgsmål efter en hændelse, "var det assistenten, der gjorde det", intet svar, og fraværet af svar er i sig selv en grund til ikke at give adgang.

Spørgsmålet man bør stille om et sådant værktøj

Ikke "er det sikkert", men "hvad er det, der nægter, og hvor bor det?"

Er svaret "modellen har fået besked på at lade være", er der ingen grænse. Er svaret "laget, der udfører, tjekker kontoens rettigheder og sender ødelæggende skridt gennem en port", er der en, og du kan teste den: forbind med en begrænset konto og bekræft, at nægtelsen er ægte.

Hvad Atlas gør

⚠️ Dette lag er planlagt, ikke leveret. Det følgende er det design, det bygges mod, skrevet ned her, fordi spørgsmålet ovenfor fortjener et ærligt svar og ikke et reklamesvar.

Hensigten er, at assistenten kobles til Atlas og ikke til Proxmox. Proxmox ligger nedenunder, og modellen når det aldrig direkte; den kan kun bruge det, Atlas selv kan, hvilket lader hver eksisterende port blive stående på vejen.

Grænsen trækkes af Proxmox' rettigheder, altså den første egenskab ovenfor: det, den tilsluttede konto må røre, er alt, hvad assistenten rører, og der dukker ikke et nyt rettighedsbegreb op. Ødelæggende handlinger beholder den bekræftelse, de allerede har, og revisionsloggen noterer allerede hvem, hvad, hvornår, på hvad og med hvilket resultat for hver privilegeret handling, afviste inklusive.

Det er også tænkt som en selvstændig komponent i stedet for en del af installationen: på en maskine, der ikke vil have den, er den aldrig til stede. Det betyder noget af samme grund som resten af denne artikel. Den sikreste grænse for en evne, du ikke har valgt, er dens fravær.