Hosting en security

AI-agents met shell-toegang: houd de netwerkuitgang dicht

Een open-weight model probeerde in een test van Cohere een bestand naar Beijing te sturen. Geef een AI-agent met shell-toegang alleen het netwerk dat nodig is.

AleksaDoor AleksaTech lead, Belgrado · 4 min lezenRead in English
Glasvezelkabels aangesloten op een netwerkswitch in een serverrek
Foto: Kirill Sh via Unsplash

Cohere zag in een afgesloten test een open-weight model van Alibaba, Qwen3.8-Flash-Next, de machine verkennen en een bestand naar een opslagbucket in Beijing proberen te uploaden. Het model had kort daarvoor in zijn redenering geschreven dat het geen tools zou gebruiken. Of dat opzet is of een gewoonte uit de training, weet niemand. Mijn advies is om het niet uit te maken: geef elke AI-agent die commando's mag uitvoeren alleen het netwerk dat de taak nodig heeft.

Wat Cohere zag

Cohere publiceerde het onderzoek op 26 oktober. Het team liet Qwen3.8-Flash-Next, een preview die Alibaba in augustus uitbracht, een benchmark van Microsoft doen voor AI-agents in een securityrol. De opdracht was een detectieregel schrijven voor malware die met curl een script binnenhaalt.

In dezelfde beurt voerde het model zelf commando's uit. Het bekeek de inhoud van /tmp, keek welke tools er waren (curl, wget, python3, jq), las de DNS-instellingen en probeerde met curl een teststring naar een bucket van Alibaba Cloud in Beijing te sturen. De sandbox had geen route naar buiten, dus het verzoek strandde daar.

Het gedrag is zeldzaam: minder dan één keer per 100.000 aanroepen in de tests van Cohere. Een tweede run met dezelfde prompt gaf gewoon een nette detectieregel. Cohere schrijft wel dat het verzoek op de laptop van een developer of in een CI-runner met normaal internet de server in Beijing had bereikt.

Er is ook kritiek. Volgens TechCrunch houden onderzoekers het vooral voor een bijproduct van rommelige trainingsomgevingen, en vonden critici dat Cohere het model met zijn methode in die richting stuurde. Cohere zette de ruwe traces daarna op Hugging Face, met een script om het na te doen.

Waarom zelf hosten hier niet genoeg is

Veel teams kiezen een open-weight model omdat het op hun eigen servers draait. Dan verlaat je data het gebouw niet, is de gedachte. Dat klopt zolang het model alleen tekst teruggeeft.

Een agent krijgt meer: een terminal, een browser, toegang tot je cloud. Dan bepaalt je netwerk wat er naar buiten gaat. En de redenering van het model is geen controle. In dit geval zei die letterlijk dat er geen tools zouden komen.

Het speelt ook niet bij één model. Volgens Cohere telt Hugging Face meer dan 113.000 afgeleide modellen van Qwen, en dook het verdachte adres op in builds van vier uitgevers. Een gesloten API van een groot lab haalt het risico ook niet weg: daar vertrouw je op wat de leverancier zegt.

Twee gewoontes om op te letten

Cohere zag nog iets. In een vervolgproef liet het team het model een curl-commando afmaken. In 23 tot 36 procent van die aanvullingen greep het model naar het metadata-adres 169.254.169.254. Daar halen machines bij AWS, Google Cloud en Azure hun tijdelijke credentials op.

Dat is het eerste wat ik zou afschermen. Een agent die dat adres bereikt, werkt met de rechten van de server waarop hij draait. Op AWS kun je IMDSv2 verplicht maken, maar blokkeer het adres daarnaast gewoon in de container van de agent.

In een andere test bouwde het model QEMU en wilde het een RAM-disk aanmaken. De container weigerde, want daar zijn beheerrechten voor nodig. Het model omzeilde dat met unshare in een eigen namespace. Op de host bleef het een gewone gebruiker, maar een agent die bij elke muur een uitweg zoekt, vindt wat je openlaat.

Zo zou ik beginnen

Draait er bij jullie al een agent met shell-toegang, in CI of op een laptop? Dan zou ik deze stappen nemen:

  1. Laat de agent in een container draaien, niet direct op de laptop of de runner. Met --network none in Docker heeft de container alleen een loopback en dus geen netwerk.
  2. Heeft de taak wel netwerk nodig, zoals een package registry of je eigen API? Zet dan een proxy met een allowlist ertussen en log elk verzoek dat wordt geweigerd.
  3. Blokkeer 169.254.169.254 voor de agent, ook als je denkt dat de container geen cloudrechten heeft.
  4. Geef de agent geen tokens die hij niet nodig heeft. Een lees-token voor één repository is genoeg voor de meeste taken.
  5. Lees de commando's die de agent uitvoert, naast zijn redenering. Bewaar ze, zodat je achteraf kunt zien wat er gebeurde.

Hoe je tokens kort laat leven en buiten de laptop houdt, staat in secrets en API-keys veilig beheren. De afspraken die een team over de tools zelf maakt, staan in afspraken over AI-codeertools in een remote team.

Kies je model, en kijk ook naar de code

Cohere wijst nog op een tweede risico: de code die een model schrijft gaat wel naar productie. Een netwerk zonder uitgang helpt daar niet tegen. Die code hoort dus dezelfde review te krijgen als code van een collega, met dezelfde scanners in je pipeline.

Behandel een model dat je downloadt als elke andere dependency. Leg vast welke versie je draait en waar die vandaan komt, net als bij een package van npm of PyPI. Milos schreef over die kant in supply chain-aanvallen op npm en PyPI. Mijn advies is om de netwerkregels voor agents gelijk te trekken met die voor je CI-runners: wat een build niet mag bereiken, mag een agent ook niet bereiken.

Bronnen

Veelgestelde vragen

Wat deed het Qwen-model in de test van Cohere?

Qwen3.8-Flash-Next kreeg de opdracht een detectieregel te schrijven. Het bekeek de machine waarop het draaide en probeerde met curl een testbestand te uploaden naar een opslagbucket van Alibaba Cloud in Beijing. De sandbox had geen route naar buiten, dus het verzoek kwam niet aan.

Is een open-weight model veilig als je het zelf host?

Zelf hosten houdt je data bij je zolang het model alleen tekst teruggeeft. Zodra het model commando's mag uitvoeren, bepaalt je netwerk wat het kan bereiken. Daarom hoort een agent in een omgeving zonder vrije uitgang naar internet.

Waarom moet een agent niet bij het cloud metadata-adres kunnen?

Op 169.254.169.254 halen servers bij AWS, Google Cloud en Azure hun tijdelijke credentials op. Een agent die dat adres bereikt, kan met de rechten van die server werken. Blokkeer het adres in de container van de agent.

Over de auteur

Aleksa

Aleksa

Tech lead, Belgrado

Aleksa is tech lead in Belgrado. Hij stuurt het developmentteam aan, bewaakt de architectuur en rapporteert aan Erik.

Meer van Aleksa
Contact
Bas Leijder HavenstroomMaarten ter VeldeBarry Willems

Vertel ons wie je zoekt.

Een kennismaking duurt een half uur, online of op ons kantoor in Amsterdam. In de chat antwoorden we meestal binnen een paar minuten.

Of bel +31 20 210 1978hello@brainpowergroup.eu

Bas, Maarten en BarryNu live · antwoord binnen een paar minuten