Een AI-assistent toegang tot Proxmox geven: waar de grens moet liggen

Er zit hier een echte en licht ergerlijke scheefheid. Tweeduizend logregels lezen en de regel vinden waar iets stukging is precies wat een taalmodel goed kan. Het is tegelijk precies het werk dat de meeste mensen het niet kunnen laten doen, vanwege de manier waarop toegang wordt verleend.

De vraag is niet of een model een server mag aanraken. De vraag is waar de grens ligt, en vandaag ligt hij meestal op de verkeerde plek.

Waarom de gebruikelijke opzet ongemakkelijk is

Er zijn twee gangbare manieren om een assistent aan Proxmox te koppelen: een SSH-sessie geven, of een API-token met volledige rechten. Beide komen op hetzelfde neer. Vanaf dat moment staat er niets meer tussen het model en de hardware, en alle bescherming leeft in de formulering van een instructie.

Een instructie is geen grens. Het is een verzoek aan een systeem dat ontworpen is om behulpzaam te zijn, in een taal zonder afdwingbaarheid.

Het risico is ontbrekende context, niet kwade opzet

Dit is het deel dat verkeerd wordt gediagnosticeerd. De storingsvorm is zelden een model dat besluit schade aan te richten. Het is een model dat correct handelt op een onvolledig beeld.

Een schijf die leeg lijkt. Het model leest een apparaat zonder aangekoppeld bestandssysteem en beschouwt het als vrij. Het apparaat hoort bij een machine die simpelweg uitstaat.

Een gedegradeerde pool. Het model leest de gedegradeerde toestand en stelt voor de verzameling opnieuw op te bouwen. De juiste stap was één schijf vervangen, en opnieuw opbouwen is hoe de resterende gegevens verloren gaan.

Een dienst die "niet draait". Hij draait niet omdat hij volgens schema draait en klaar is. Herstarten is onschuldig; uitschakelen omdat hij "steeds stopt" niet.

In alle drie is de opdracht correct geschreven. Wat fout is, is de premisse, en een correcte opdracht op een foute premisse is achteraf niet te onderscheiden van sabotage.

Alleen-lezen helpt, en is niet het hele antwoord

Het voor de hand liggende antwoord is alleen-lezen toegang, en dat neemt de ergste afloop echt weg. Twee dingen blijven.

Lezen is niet gratis. Configuratie, logboeken en auditsporen bevatten hostnamen, adressen, gebruikersnamen en soms tokens die zijn geplakt waar ze niet hoorden. Een alleen-lezen assistent met volledige leesreikwijdte is een export van uw infrastructuur.

Diagnose zonder handeling stopt halverwege. Als het nuttige antwoord is "herstart deze ene dienst", geeft een alleen-lezen opzet de bevinding terug aan een mens om over te typen. Dat is prima, en het is ook waarom rechten later stilletjes worden verruimd.

Alleen-lezen is dus een goed begin en een slechte bestemming. De bestemming is smalle schrijftoegang, door dezelfde poorten die een mens passeert.

Waar de grens werkelijk thuishoort

Niet in de instructie en niet in het model. In de uitvoerende laag, want dat is de enige plek die kan weigeren.

Drie eigenschappen maken zo'n laag betrouwbaar, en alle drie zijn controleerbaar in plaats van beloofd.

Rechten komen uit het systeem dat ze al heeft. Verbindt de assistent zich met een bestaand account, dan is wat dat account mag aanraken precies wat de assistent mag aanraken. Er wordt geen tweede rechtenmodel verzonnen, dus valt er niets synchroon te houden en kunnen de twee elkaar niet tegenspreken.

Vernietigende bewerkingen passeren dezelfde poort als een mens. Als het verwijderen van een schijf een mens om bevestiging vraagt, moet het dat ook doen wanneer een model erom vraagt. Een pad dat veilig is voor mensen en open voor automatisering is geen grens, het is een sluiproute met een mooie naam.

Elke stap belandt in het auditlogboek. Wie, wat, wanneer, waarop en met welk resultaat. Zonder dat heeft de echte vraag na een incident, "heeft de assistent dit gedaan", geen antwoord, en het ontbreken van dat antwoord is op zichzelf een reden om geen toegang te geven.

De vraag die je over zo'n gereedschap moet stellen

Niet "is het veilig" maar "wat weigert er, en waar woont dat?"

Is het antwoord "het model is verteld dat niet te doen", dan is er geen grens. Is het antwoord "de uitvoerende laag controleert de rechten van het account en laat vernietigende stappen door een poort", dan is die er, en u kunt het testen: verbind met een beperkt account en bevestig dat de weigering echt is.

Wat Atlas doet

⚠️ Deze laag is gepland, niet uitgeleverd. Wat volgt is het ontwerp waarnaar hij wordt gebouwd, hier opgeschreven omdat de vraag hierboven een eerlijk antwoord verdient en geen reclamezin.

De bedoeling is dat de assistent op Atlas aansluit en niet op Proxmox. Proxmox ligt eronder en het model bereikt het nooit rechtstreeks; het kan alleen gebruiken wat Atlas zelf kan, waardoor elke bestaande poort in het pad blijft.

De grens wordt getrokken door de rechten van Proxmox, dus de eerste eigenschap hierboven: wat het verbindende account mag aanraken is alles wat de assistent aanraakt, en er verschijnt geen nieuw rechtenbegrip. Vernietigende bewerkingen behouden de bevestiging die ze al hebben, en het auditlogboek noteert al wie, wat, wanneer, waarop en met welk resultaat voor elke bevoorrechte handeling, geweigerde inbegrepen.

Het is ook bedoeld als losse component in plaats van onderdeel van de installatie: op een machine die hem niet wil is hij nooit aanwezig. Dat telt om dezelfde reden als de rest van dit artikel. De veiligste grens voor een mogelijkheid die u niet hebt gekozen, is haar afwezigheid.