AI aan je server koppelen: zo deployt en beheert een AI-agent je server

De meeste mensen gebruiken AI nog altijd als een zeer belezen collega aan de telefoon: je beschrijft een serverprobleem, krijgt een commando voorgesteld, plakt het in de console, kopieert de foutmelding terug en herhaalt dat spelletje tot het werkt. Zodra je de AI aan je server koppelt, valt die omweg weg. Een AI-agent zoals Claude Code, OpenAI Codex CLI of Gemini CLI logt zelf via SSH in op de server, leest de logs, controleert de configuratie, voert wijzigingen door, test het resultaat en schrijft op wat hij heeft gedaan. Jij bepaalt de taak en keurt de stappen goed die niet meer terug te draaien zijn.

Dit artikel is een praktijkverslag. Bij KernelHost werkt al maanden elke dag een AI-agent mee aan onze eigen infrastructuur: klantenportaal, monitoring, betaalkanalen, documentatie. We laten zien hoe de verbinding tussen agent en server is opgebouwd, volgens welke werkwijze de agent op productiesystemen deployt, welke regels voorkomen dat er daarbij iets misgaat of naar buiten lekt, en wat een server moet bieden om dit alles te laten werken. De basisprincipes van hulpmiddelen en architecturen staan in het artikel AI managed server: AI-agents veilig koppelen, de installatie op de server in de handleiding voor Claude Code en Codex CLI.

AI aan je server koppelen: wat dat betekent

Een AI aan je server koppelen betekent dat je een AI-agent een eigen, gecontroleerde toegang geeft tot de commandoregel van de server, meestal via een SSH-sleutel. Vanaf dat moment kan de agent commando's niet alleen voorstellen, maar ook zelf uitvoeren, de uitvoer lezen en daaruit de volgende stap afleiden. Het taalmodel zelf blijft bij de aanbieder draaien (Anthropic, OpenAI of Google). Op je computer of server draait alleen een licht commandoregelprogramma dat de commando's uitvoert.

Het gaat om het woord „gecontroleerd". Een agent met servertoegang is geen automatische piloot, maar een heel snelle collega die vóór elke ingrijpende actie om toestemming vraagt. Hoeveel hij mag zonder het eerst te vragen, bepaal je zelf: van pure leestoegang tot het zelfstandig uitrollen van updates volgens een vaste werkwijze.

Chatbot of agent: het verschil in één tabel

Zo wordt een half uur heen en weer vaak een kwestie van enkele minuten, en de foutbron „verkeerd overgetypt" verdwijnt helemaal.

Wat een AI-agent op de server doet: voorbeelden uit ons eigen beheer

De volgende voorbeelden komen uit onze dagelijkse praktijk. Namen, adressen en toegangsgegevens laten we weg, de werkwijzen zijn echt.

Deployments met back-up en terugweg

Als we iets aan het klantenportaal of aan een serverscript wijzigen, neemt de agent het uitrollen over. Eerst vergelijkt hij het bestand op de server met de laatst bekende versie, zodat hij geen wijziging van iemand anders overschrijft. Daarna maakt hij een back-up met datum buiten de webroot, schrijft hij een rollbackscript, controleert hij de syntaxis van het nieuwe bestand, plaatst hij het met dezelfde eigenaar en rechten als voorheen en test hij vervolgens de betrokken functie. Pas als alles groen is, meldt hij dat het klaar is. De precieze werkwijze staat verderop in het gedeelte over deployen.

Foutopsporing: van symptoom naar oorzaak in enkele minuten

„De website is vanaf ons kantoor niet bereikbaar, onderweg wel." Vroeger betekende dat een lange zoektocht. De agent controleert de firewallregels, doorzoekt de logs van de beveiligingssoftware op het kantooradres, vindt de regel die heeft ingegrepen en legt uit door welk verzoek die werd geactiveerd. De beslissing over wat er moet gebeuren, blijft bij ons, het speurwerk niet. Bij typische webserverfouten zoals 502 Bad Gateway of een volle schijf werkt hij net zo: hij kijkt in journalctl en in de applicatielogs, stelt een hypothese op en onderbouwt die voordat hij iets wijzigt.

Monitoring die de agent zelf bouwt

Een groot deel van onze monitoring is samen met de agent ontstaan: kleine controlescripts die om de paar minuten via een cronjob een dienst end-to-end testen en bij een fout een bericht naar de telefoon sturen, bijvoorbeeld via een Telegram-bot. De agent schrijft het script, test het met een opzettelijk veroorzaakte fout, richt de cronjob in en documenteert hoe je het alarm dempt. Hoe je zoiets in het algemeen opzet, beschrijft het artikel Servermonitoring inrichten.

Overzichten en opruimwerk

Welke servers draaien nog, hoewel het bijbehorende contract is opgezegd? Voor welke extra diensten wordt betaald terwijl ze niet meer worden gebruikt? Zulke vragen beantwoordt de agent door databases en interfaces alleen met leesrechten te bevragen en het resultaat als tabel te presenteren. Opruimen mag hij pas na goedkeuring, en vooraf controleert hij of de machine echt ongebruikt is, bijvoorbeeld aan de hand van het dataverkeer van de afgelopen dagen.

Documentatie die vanzelf meegroeit

Elke wijziging eindigt met een regel in het wijzigingslogboek en, waar nodig, een aanvulling in het beheerhandboek. Dat kost de agent seconden en bespaart ons later uren, omdat de vraag „Waarom is dit eigenlijk zo?" een schriftelijk antwoord heeft.

De voordelen als de AI direct op de server werkt

• Snelheid: de agent leest in seconden waar een mens minuten voor nodig heeft, en probeert een hypothese meteen uit in plaats van die eerst te beschrijven.
• Grondigheid: hij leest de hele configuratie inclusief de ingeladen bestanden en de logregels rond de fout, niet alleen het fragment dat iemand relevant vond.
• Steeds dezelfde werkwijze: back-up, syntaxcontrole en verificatie lopen elke keer, ook op vrijdagavond en ook bij de twintigste kleine wijziging.
• Documentatie zonder extra werk: elke wijziging is beschreven, met reden, back-uplocatie en terugweg.
• Automatisering zonder scriptcursus: controlescripts, cronjobs en rapporten ontstaan uit een beschrijving in gewone taal en worden getest voordat ze in gebruik gaan.
• Al doende leren: de agent legt uit wat hij doet en waarom. Wie meeleest, begrijpt zijn server na een paar weken duidelijk beter.

Drie architecturen en welke wij gebruiken

Er zijn drie beproefde manieren om een agent aan een server te koppelen. Ze verschillen in waar het programma draait en waar de toegangsgegevens staan.

Onze keuze: agent op de werkplek, servers via SSH

Wij werken met de eerste variant. De agent draait op de werkcomputer, elke server heeft een eigen vermelding in de SSH-configuratie en de agent maakt verbinding met een eigen sleutel. De belangrijkste reden: we beheren veel systemen, en juist zo kan één agent in één sessie een oorzaak over meerdere servers heen volgen, bijvoorbeeld van de webserver via de database tot aan de firewall. Bovendien staan de aanmelding bij de AI-aanbieder en de sleutels op een plek die we toch al beveiligen. Wie maar één server heeft en 's nachts automatische rapporten wil, is met de tweede variant goed af. Meer over de voor- en nadelen staat in het artikel over AI managed server.

Handleiding: AI-agent via SSH aan je server koppelen

De volgende zeven stappen werken met Claude Code, Codex CLI en Gemini CLI op dezelfde manier. De voorbeelden gebruiken het documentatieadres 203.0.113.10 en de gebruikersnaam deploy; vervang beide door je eigen waarden. Voorwaarde is een server waarop je met een SSH-sleutel inlogt, zoals beschreven in het artikel SSH beveiligen en inloggen met sleutel instellen.

Stap 1: een eigen SSH-sleutel alleen voor de agent aanmaken

De agent krijgt nooit je persoonlijke sleutel, maar een eigen sleutel. Zo kun je hem de toegang op elk moment ontnemen zonder je eigen toegang kwijt te raken, en in de logs is te zien welke aanmelding van de agent kwam.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 is kort, snel en geldt als veilig. Het commentaar ki-agent verschijnt later in de authorized_keys van de server en maakt de sleutel in één oogopslag herkenbaar.

Stap 2: de openbare sleutel op de server plaatsen

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Wil je de toegang verder inperken, zet dan in het bestand ~/.ssh/authorized_keys op de server opties vóór de sleutel. from= staat aanmelden alleen vanaf een bepaald adres toe, no-agent-forwarding en no-port-forwarding voorkomen dat de verbinding als springplank dient:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Meldt de server daarna Permission denied (publickey), dan helpt het artikel SSH Permission denied (publickey) oplossen.

Stap 3: een host-alias in de SSH-configuratie aanmaken

Met een alias hoeft de agent alleen een korte naam te kennen en gebruikt hij altijd de juiste sleutel:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Daarna volstaat ssh web-prod "systemctl status nginx". IdentitiesOnly yes voorkomt dat SSH andere sleutels uit je sleutelbos uitprobeert. Voor elke extra server maak je een eigen blok aan, voor test- en productiesystemen het liefst met verschillende namen zoals web-test en web-prod, zodat een verwisseling al aan de naam opvalt.

Stap 4: de agent installeren en aanmelden

Claude Code, Codex CLI en Gemini CLI draaien op Linux, macOS en Windows en worden aangemeld met een account bij de aanbieder of met een API-sleutel. De installatie en het aanmelden zonder browser staan beschreven in de stapsgewijze handleiding. Voor de werkplekvariant installeer je het programma op je eigen computer, niet op de server.

Stap 5: regels vastleggen waaraan de agent zich houdt

Alle drie de programma's lezen bij het starten een regelbestand in de werkmap: Claude Code de CLAUDE.md, Codex CLI de AGENTS.md, Gemini CLI de GEMINI.md. Daarin staat hoe er op je servers wordt gewerkt. Een beproefd begin:

# Regels voor het werken op servers

- Vóór elke wijziging een back-up met datum maken, buiten de webroot.
- Vóór het uitrollen de syntaxis controleren (nginx -t, php -l, apachectl configtest).
- Na het uitrollen dienst, log en functie controleren en het resultaat melden.
- Wachtwoorden, API-sleutels en tokens nooit tonen, nooit naar bestanden kopiëren.
- Verwijderen, databasewijzigingen en alles wat onomkeerbaar is alleen na uitdrukkelijke goedkeuring.
- Bestanden die het controlepaneel beheert niet rechtstreeks wijzigen.
- Testbestanden na de test weer verwijderen.

De regels groeien mee. Elke keer dat de agent iets anders doet dan jij wilt, hoort de correctie als regel in dit bestand. Na een paar weken werkt hij zoals je zelf zou werken.

Stap 6: goedkeuringen en allowlist instellen

Standaard vragen de programma's om toestemming vóór elk commando dat iets verandert. In het begin is dat precies goed. Leescommando's die je steeds opnieuw bevestigt, kun je vrijgeven. In Claude Code gebeurt dat in het bestand .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Alles wat niet op deze lijst staat, heeft nog steeds jouw toestemming nodig. Opties die alle bevestigingsvragen uitschakelen, horen hooguit thuis op een wegwerp-testmachine.

Stap 7: de eerste taak: alleen lezen

Begin met taken die niets kunnen veranderen en kijk hoe de agent te werk gaat:

Controleer op web-prod de nginx-fouten van de afgelopen 24 uur en noem de drie
meest voorkomende oorzaken, elk met een regel uit het log als bewijs. Wijzig niets.

Pas als de analyses kloppen, volgen kleine wijzigingen, zoals een nieuwe logrotatie of een systemd-service, en pas daarna deployments op het productiesysteem.

Zo deployt de agent: onze werkwijze voor elke wijziging aan het productiesysteem

Een AI-agent mag op een productiesysteem alleen deployen volgens een vaste werkwijze met een back-up, een voorbereide terugweg en een controle vóór en na het uitrollen. Bij ons ziet die werkwijze er zo uit:

1. Huidige stand controleren. Het bestand op de server wordt vergeleken met de laatst bekende versie. Heeft iemand anders het intussen gewijzigd, dan stopt de agent en vraagt hij na, in plaats van die wijziging te overschrijven.
2. Back-up maken. De betrokken bestanden komen met datum in een back-upmap buiten de webroot terecht. Een back-up in de webroot zou onder omstandigheden publiek op te vragen zijn.
3. Terugweg voorbereiden. Een klein script dat de oude stand met één commando terugzet, ontstaat vóór de wijziging, niet pas in een noodgeval.
4. Syntaxis controleren. Het nieuwe bestand wordt vóór het uitrollen gecontroleerd, bij PHP met php -l, bij nginx met nginx -t. Zo bereikt een syntaxfout het productiesysteem helemaal niet.
5. Met de juiste rechten uitrollen. Eigenaar, groep en bestandsrechten worden van de oude versie overgenomen. Na syntaxfouten zijn verkeerde rechten de meest voorkomende oorzaak van storingen na een update.
6. Zonder bijwerkingen testen. Er wordt lezend getest, met verzonnen testgegevens of in een afgeschermde omgeving, nooit met echte bestellingen of echte klantgegevens.
7. Live controleren. HTTP-status, foutlog en de gewijzigde functie worden na het uitrollen gecontroleerd.
8. Documenteren. Wijzigingslogboek en beheerhandboek worden aangevuld, inclusief de locatie van de back-up en het commando voor de terugweg.

Als reeks commando's, met plaatshouders in plaats van echte paden, ziet dat er ongeveer zo uit:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Waarom de terugweg vóór de wijziging ontstaat

Bij een storing is niemand op zijn best om rustig een nette terugweg te bedenken. Ligt het script al klaar, dan is terugdraaien een kwestie van seconden, en de agent kan dat ook zelf doen als de controle na het uitrollen mislukt. Dat is het grootste verschil tussen een agent die „even snel" iets wijzigt en een agent aan wie je een productiesysteem toevertrouwt.

Tests die niets kapot kunnen maken

Veel functies zijn niet te testen zonder dat er iets gebeurt: een bestelling, een betaling, een e-mail. Hier helpen drie technieken. Ten eerste dry-runs die het programma zelf aanbiedt. Ten tweede verzonnen ID's die gegarandeerd nergens bestaan. Ten derde een afgeschermde omgeving: een proces dat in een eigen netwerk-namespace zonder netwerk draait (unshare -n), kan geen externe interface bereiken en ook niet per ongeluk iets kopen, maar ziet de lokale database nog steeds via de Unix-socket. Na de test worden alle testbestanden weer verwijderd.

Acties die geld kosten, hebben een vergrendeling nodig

Als een taak iets bestelt, factureert of verwijdert, mag die niet twee keer tegelijk draaien, ook niet als iemand dubbelklikt of de agent een commando herhaalt. De eenvoudigste oplossing op Linux is flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "draait al"

Bij databasetoepassingen vervult een benoemde vergrendeling (GET_LOCK in MySQL en MariaDB) hetzelfde doel, bij API's een Idempotency-Key; meer daarover verderop bij de KernelHost API.

Beveiliging: toegang voor de agent zonder dat er iets uitlekt

De zorg die we het vaakst horen, luidt: „En hoe zit het met mijn gegevens?" Het eerlijke antwoord: alles wat de agent leest, stuurt hij ter verwerking naar het taalmodel van de aanbieder. Daarom bepaal je met de volgende regels wat hij überhaupt te zien krijgt.

Geheimen horen niet in de chat

Wachtwoorden, API-sleutels en tokens worden nooit in een taak geschreven en nooit door de agent getoond. Scripts lezen ze uit bestanden met rechten 600, die de agent niet hoeft te tonen om het script te gebruiken. Belandt er toch een keer een sleutel in de chat, dan wordt die direct bij de aanbieder ingetrokken en opnieuw aangemaakt. Ook fragmenten horen niet in de chat: de eerste tekens van een sleutel helpen niemand bij het zoeken naar een fout, maar verkorten wel het werk van een aanvaller.

Eigen sleutels, eigen rechten, altijd in te trekken

Elke agent krijgt een eigen SSH-sleutel, en elke sleutel is in de authorized_keys herkenbaar aan zijn commentaar. Wie de toegang wil intrekken, verwijdert die ene regel. Waar dat volstaat, werkt de agent met een eigen gebruiker en een sudo-regel die alleen de benodigde commando's toestaat. API's krijgen eigen sleutels met zo weinig mogelijk rechten, voor pure rapportages alleen leesrechten.

Goedkeuringen: wat nooit zonder mens gebeurt

Zonder uitdrukkelijke toestemming mag de agent bij ons niets verwijderen, niet in databases schrijven, geen firewall- of beschermingsregels versoepelen, geen machines stoppen en niets bestellen. De programma's ondersteunen dat: Claude Code houdt ingrijpende acties tegen en is daarnaast zo in te stellen dat een veiligheidsfilter riskante commando's herkent en blokkeert tot ze zijn goedgekeurd. Uit onze praktijk: dit filter heeft meer dan eens een actie tegengehouden die inhoudelijk juist was, maar nu eenmaal onomkeerbaar. Die werd pas uitgevoerd nadat een mens er uitdrukkelijk toestemming voor had gegeven. Precies zo hoort het.

Traceerbaarheid: logs, wijzigingslijst, back-ups

Elke sessie laat sporen na die een mens kan lezen: de back-ups met datum, het rollbackscript, de regel in het wijzigingslogboek en de aanmeldingen in het systeemlog. Wie /etc daarnaast met etckeeper in Git beheert, ziet elke configuratiewijziging als diff. Wat niet traceerbaar is, kun je ook niet terugdraaien. De basis blijft een werkende back-upstrategie, want een agent vervangt geen back-up.

Welke server is geschikt voor een AI-agent?

Een server voor AI-ondersteund beheer vereist volledige roottoegang, inloggen met SSH-sleutels, onbeperkte uitgaande verbindingen, permanente DDoS-bescherming en idealiter een API waarmee je servers geautomatiseerd bestelt en bestuurt. Een GPU is niet nodig, want het taalmodel draait bij de aanbieder.

Waarom KernelHost voor door AI beheerde servers

In principe kan een AI-agent met elke server werken waarop hij een shell krijgt. In de praktijk bepaalt de omgeving echter hoeveel werk je hem echt kunt toevertrouwen. Op een KVM-rootserver of dedicated server van KernelHost zijn er geen beperkte accounts, geen drempels voor de HTTPS-verbindingen naar de AI-aanbieders en geen vast contract dat experimenteren duur maakt. De permanente DDoS-bescherming is bij elke server zonder meerprijs actief, en voor rekenintensieve taken is er de Professional VDS met dedicated kernen. De afrekening is PrePaid: geen contract, geen minimale looptijd, geen installatiekosten. Wie eerst wil uitproberen, begint met de gratis testserver.

De KernelHost API: je agent bestelt en bestuurt servers zelf

De grootste hefboom ligt een niveau boven de afzonderlijke server. Via de KernelHost API kan een agent producten en prijzen opvragen, servers bestellen, de status van zijn diensten uitlezen, servers starten, stoppen en herstarten, en opzeggingen indienen en weer intrekken. Zo wordt „Richt een testserver voor me in" één enkele taak: de agent bestelt de machine, wacht op de levering, maakt verbinding via SSH, installeert de applicatie en meldt het adres terug.

Voor gebruik door agents is de API bewust voorzichtig opgezet. API-sleutels krijgen alleen de machtigingen die ze nodig hebben, en een sleutel voor rapportages kan helemaal niets bestellen. Een Idempotency-Key zorgt ervoor dat een bestelling die de agent na een time-outfout herhaalt, niet dubbel wordt uitgevoerd. Verzoeken zijn per sleutel, per account en per adres begrensd, zodat ook een agent in een eindeloze lus geen lawine veroorzaakt. En elke keer dat toegangsgegevens worden opgevraagd, gaat er een melding per e-mail uit, zodat je ziet wanneer een agent toegangsgegevens heeft gelezen.

Wat kost een door AI beheerde server?

Er zijn twee kostenposten. Ten eerste de server zelf: voor een agent die via SSH werkt, is geen bijzondere uitrusting nodig, want elke rootserver waarop je applicatie toch al draait, volstaat. Draait de agent direct op de server, dan heeft het programma zelf maar een paar honderd megabyte werkgeheugen nodig, en een rootserver met 2 vCPU en 4 GB RAM is genoeg als er verder weinig op draait. Ten tweede het taalmodel: ofwel een abonnement bij de aanbieder waarin het gebruik van het commandoregelprogramma is inbegrepen, ofwel een API-sleutel met afrekening naar verbruik. Bij dagelijks intensief gebruik is het abonnement meestal goedkoper; voor geautomatiseerde taken zonder mens ervoor is de API-sleutel de nette weg, omdat je die met een maandbudget kunt begrenzen. De actuele serverprijzen vind je op de pagina Rootserver huren.

Veelgemaakte fouten en hoe je ze voorkomt

• De agent werkt met de persoonlijke sleutel van de beheerder. Dan kun je zijn toegang niet apart intrekken en is die in de logs niet te onderscheiden. Oplossing: een eigen sleutel met een eigen commentaar.
• Alle bevestigingsvragen staan uit. Dat bespaart op de eerste dag klikken en kost je vroeg of laat een server. Oplossing: een allowlist voor leescommando's, goedkeuring voor alles wat ingrijpt.
• Geen back-up vóór de wijziging. Oplossing: back-up en rollbackscript als vaste regel in de CLAUDE.md of AGENTS.md.
• Back-ups in de webroot. Een bestand als config.php.bak in de webroot kan publiek op te vragen zijn, inclusief databasewachtwoord. Oplossing: een back-upmap buiten de webroot met rechten 700.
• Geheimen in de prompt. Oplossing: toegangsgegevens alleen in bestanden met rechten 600 die scripts inlezen, en bij een vergissing meteen opnieuw aanmaken.
• Dubbele uitvoering. Een dubbele klik of een herhaald verzoek bestelt twee keer. Oplossing: een vergrendeling met flock of een Idempotency-Key.
• Bestanden die het controlepaneel beheert, rechtstreeks gewijzigd. Het paneel overschrijft ze bij de volgende update of loopt erop vast. Oplossing: zulke bestanden in de regels uitsluiten en wijzigingen via het paneel of de API ervan doorvoeren.
• Uitvoer ongecontroleerd overgenomen. Een agent die een uitvoer niet begrijpt, gokt. Oplossing: bewijs vragen („laat me de logregel zien") en resultaten live laten controleren.

Kort samengevat

• Een AI aan je server koppelen betekent: een agent zoals Claude Code, Codex CLI of Gemini CLI een eigen SSH-sleutel en duidelijke regels geven.
• De agent leest logs, voert wijzigingen door, controleert het resultaat en documenteert het; ingrijpende stappen lopen alleen met goedkeuring.
• Elke deployment volgt een vaste werkwijze: huidige stand controleren, back-up maken, terugweg voorbereiden, syntaxis controleren, uitrollen, testen, live controleren, documenteren.
• Geheimen horen nooit in de chat, en acties die geld kosten, hebben een vergrendeling tegen dubbele uitvoering nodig.
• De server heeft roottoegang, SSH-sleutels, vrije uitgaande verbindingen en DDoS-bescherming nodig, maar geen GPU.
• KernelHost-servers voldoen standaard aan alle eisen, PrePaid en zonder vast contract, en via de KernelHost API kan de agent zelfs zelf servers bestellen en besturen.