AI stuurt de server aan, zonder die stuk te maken

Atlas kan zijn eigen Model Context Protocol server openen, voor wie dat wil, en biedt een opdrachtveld in het paneel. Het is een apart onderdeel: het komt niet mee met de installatie, wie het wil voegt het met één knop toe vanuit het paneel, en op een machine die het niet wil is het helemaal niet aanwezig. Eenmaal toegevoegd wordt de staat van de server gelezen, een storing doorgewerkt en werk gedaan door te typen wat er nodig is. De grens wordt getrokken door Proxmox: waar een gebruiker aan mag komen, komt de AI ook aan, niet verder. Er komt geen nieuw rechtenbegrip bij. De AI wordt op Atlas aangesloten, niet op Proxmox. Proxmox ligt eronder, maar het model komt er nooit rechtstreeks bij; het gebruikt alleen wat Atlas kan.

Wat het vandaag kost om een model toegang tot de server te geven

Er is vandaag maar één manier om een AI-assistent met Proxmox te laten werken: hem een SSH-sessie of een API-token met volledige rechten geven. Dat is root weggeven, en vanaf dat punt staat er niets meer tussen het model en de hardware.

Het risico ontstaat door ontbrekende context, niet door kwade wil. Een model kan een schijf leeg zien en als verwijderbaar behandelen, terwijl die schijf bij een simpelweg uitgeschakelde machine hoort. Het kan een gedegradeerde pool lezen en voorstellen die opnieuw op te bouwen, terwijl de juiste stap het vervangen van één schijf is. Het commando is correct geschreven en het resultaat is dataverlies.

Daarom blijft het model in serieuze omgevingen buiten de server. Het verlies zit in de diagnose: lange logboeken lezen en vinden wat kapot is, is precies waar een model goed in is, en precies dat werk gebeurt niet.

Wat er gevraagd kan worden

In het opdrachtveld van het paneel wordt gevraagd en opgedragen, als één gesprek. De voorbeelden hieronder zijn de vraagkant: het model leest de staat van de server en antwoordt met het gegeven waarop het steunt, en daarin verandert niets.

Waarom is de back-up van vannacht mislukt, bij welke stap stopte hij, was er ruimte op de doelopslag?

Waarom is deze virtuele machine sinds gisteravond traag, ligt de knel bij de processor of bij de schijf?

Waarom is de pool gedegradeerd, welke schijf viel uit, lopen de gegevens nu gevaar?

Welke van de openstaande updates vraagt een herstart en welke diensten legt hij stil?

Wat betekent deze fout in het logboek, is die eerder voorgekomen, herhaalt hij zich?

Wanneer is de capaciteit in dit tempo vol, welke machine groeit het snelst?

Wat er gedaan kan worden

Dit heet VibeOps: een server aansturen door te praten. Vibe coding is schrijven zonder de code te lezen, en op Proxmox kan dat niet, dus blijft hier elke stap zichtbaar. In hetzelfde veld wordt ook gewerkt. Er wordt getypt wat er nodig is. Atlas meldt eerst wat het gaat doen en waar het raakt: de stappen, de betrokken machines en opslag, en de weg terug. Het werk gebeurt pas na goedkeuring. Er komt geen nieuw rechtenbegrip bij: het opdrachtveld werkt met de rechten van het Proxmox-account waarmee het verbindt. Wie een smallere AI wil, geeft die een smal Proxmox-account, en de reikwijdte staat in de rechten van dat account. Wie liever alleen leest, zet schrijven uit voor de eigen sessie. Elke stap komt in het auditlogboek.

Geef deze machine twee cores extra en breng het geheugen naar acht gigabyte.

Zet een back-up om drie uur s nachts klaar voor alle machines in deze pool.

Installeer de openstaande beveiligingspatches, laat de patches met herstart voor het onderhoudsvenster.

Zet het herstartbeleid van die container op altijd.

Geef deze gebruiker alleen back-uprechten, verder niets.

Verplaats die schijf naar de nieuwe pool, maak er eerst een momentopname van.

Het model gaat door dezelfde deur als een mens

De MCP-server opent geen zijweg. Dezelfde beschermingen die Atlas al voor de menselijke gebruiker uitvoert, gelden in dezelfde volgorde ook voor het model.

Rechten komen uit Proxmox

Het model werkt met de rechten van de gebruiker waarmee het verbindt, niet met een eigen account. Wat Proxmox die gebruiker ontzegt, blijft ook het model ontzegd. Atlas bouwt geen eigen rechtensysteem.

Het Proxmox-account bepaalt de reikwijdte

Het opdrachtveld werkt met de rechten van het Proxmox-account waarmee het verbindt; Atlas voert geen eigen rechtenbegrip in. Wie een smalle reikwijdte wil, geeft het een smal account, en die reikwijdte staat in de rechten van dat account en wordt bij een audit daar teruggelezen. Schrijven uitzetten voor de eigen sessie is één handeling.

De impact wordt eerst getoond

Wordt een wijziging voorgesteld, dan ziet een mens de toe te passen stappen, de geraakte bronnen en de weg terug. De goedkeuring gebeurt op het scherm, niet in het gesprek.

Harde bevestiging voor wat niet terug kan

Heeft het account waarmee het verbindt geen recht, dan kunnen verwijderen, formatteren en een pool afbreken helemaal niet. Waar het recht er wel is, geldt nog steeds de harde bevestiging die het product elders gebruikt: de naam typen om te bevestigen, één klik is niet genoeg. Wie nog een stap wil, zet die aan: schrijfacties vragen een eenmalige code, dezelfde verificatie in twee stappen die het account al gebruikt.

Elke stap wordt vastgelegd

Alles wat het model leest en elke bewerking die het vraagt komt in het auditlogboek: welke gebruiker, welk model, wanneer en met welk resultaat. De regel is achteraf niet te wijzigen.

Antwoorden tonen hun bron

Het model zegt waar het zijn conclusie vandaan haalt: welke logregel, welke meting, welke configuratie. Een antwoord dat niet te controleren is, telt niet als antwoord.

Wat het model niet kan

De grenzen zitten in het product, niet in het gesprek. Hoe het model wordt gevraagd, of hoe hard iemand het probeert om te praten, maakt niets uit. Ook in een organisatie die haar eigen model aansluit gelden dezelfde grenzen, want de regel wordt in de server afgedwongen en niet in het model.

Het kan zijn eigen rechten niet verruimen en geen gebruiker of toegangssleutel aanmaken.

Het kan geen enkele schrijfbewerking uitvoeren zonder goedkeuring.

Heeft het account waarmee het verbindt geen schrijfrecht, dan verandert het niets en leest het alleen.

Het kan op de server geen shell openen en niet naar de opdrachtregel vallen. Dat is zelden nodig, want ook werk dat diepte vraagt is gedekt: van de ZFS-pool tot Ceph, van de bridge tot OVS, van het vastzetten van de kernel tot het toekennen van rechten, en die dekking groeit met elke versie. Voor de zeldzame klus die erbuiten valt schrijft het de opdracht en legt het risico uit; de uitvoering blijft mensenwerk.

Het kan de auditregel niet verwijderen of wijzigen.

Waar de gegevens heen gaan

De MCP-server is een apart onderdeel en hoort niet bij de standaardinstallatie. Het wordt met één knop toegevoegd vanuit het paneel; op een machine die het niet wil staat er geen enkel bestand van. Na installatie blijft het aan de klant welke bronnen het mag bekijken en hoe lang het openstaat.

Welk model wordt aangesloten kiest de klant ook zelf. Met een lokaal model dat op de server zelf draait, verlaat er geen gegeven de machine en blijft het product offline. Wordt een externe dienst gekozen, dan is de te verzenden inhoud zichtbaar voor het verzenden.

Voor organisaties onder strenge regelgeving

Er wordt geen certificering geclaimd. Het product is ontworpen om te voldoen aan de eisen van kaders met harde auditvoorwaarden, en de eigen audit van een organisatie kan dit gedrag als bewijs gebruiken.

AI-managementsysteem (ISO/IEC 42001): wat het model mag doen staat op schrift, de grenzen worden in het product afgedwongen, elk gebruik wordt vastgelegd.

Informatiebeveiliging (ISO/IEC 27001): toegang komt uit het bestaande identiteitssysteem, rechten volgen het beginsel van minimale rechten, regels zijn onveranderlijk.

AI-risicobeheer (ISO/IEC 23894 en NIST AI RMF): geen autonome handeling, menselijke goedkeuring is een verplichte stap in de stroom.

Persoonsgegevens (AVG en gelijkwaardige regels): gegevens blijven op de machine van de klant; moeten ze naar buiten, dan is dat vooraf zichtbaar en de keuze is aan de klant.

Kritieke infrastructuur (NIS2 en transparantieregels voor AI): na een incident valt terug te lezen wie wat deed, wat het model voorstelde en wie het goedkeurde.

Veelgestelde vragen

Betekent dit dat de server aan een AI wordt overgedragen?
Nee. Er gebeurt alleen wat de rechten van die gebruiker in Proxmox toestaan; de AI heeft geen eigen rechten. Wie een smalle reikwijdte wil, geeft de AI een smal Proxmox-account. Elke bewerking vraagt een impactrapport en goedkeuring.
Waarom komt dit in een product dat offline werkt?
Het onderdeel hoort niet bij de standaardinstallatie, alleen wie het wil voegt het toe. Het toevoegen zelf vraagt op dat moment een verbinding; de rest van het product staat daar los van. Eenmaal geïnstalleerd blijft het product offline met een lokaal model dat op de server zelf draait.
Welke modellen worden ondersteund?
Er zijn twee wegen: de assistent die Atlas aanbiedt, of een eigen model. Het protocol staat los van het model, dus elke client die Model Context Protocol spreekt kan verbinden, ook lokaal draaiende. Welke weg ook gekozen wordt, de grenzen veranderen niet, want ze zitten in de server en niet in het model.
Wat gebeurt er als het model iets verkeerds zegt?
Een verkeerd antwoord blijft op het niveau van een voorstel, want toepassen is een aparte stap. Elk antwoord toont bovendien het gegeven waarop het steunt, zodat een mens het kan nagaan.
Hoe houdt dit stand bij een strenge bedrijfsaudit?
Het auditlogboek draagt alles wat het model las en elke bewerking die het vroeg. Wie goedkeurde staat in dezelfde regel, dus de beslisketen is volledig terug te lezen.
Wanneer komt het beschikbaar?
Het ontwerp is klaar en de bouw staat op de productroutekaart. Zodra het klaar is, voegen gebruikers die het willen het met één knop toe vanuit het paneel; een installatie die het niet wil blijft precies zoals ze is.

Verwante artikelen