Hoe geef je een AI-agent veilig toegang tot je bestanden?
Maak de toegang zo klein mogelijk: een expliciete allowlist in plaats van een denylist, gescheiden read- en write-rechten, backups vóór iedere mutatie en een tool-laag die de scope afdwingt buiten het model om.
Je geeft een AI-agent veilig toegang tot bestanden door de toegang zo klein mogelijk te maken: alleen de mappen en bewerkingen die voor zijn taak noodzakelijk zijn. Geef een agent dus niet standaard toegang tot je volledige home-directory, netwerkschijf of bedrijfsarchief als hij slechts één projectmap hoeft te verwerken. Een fout, verkeerd geïnterpreteerde opdracht of prompt-injectie kan anders bestanden buiten de bedoelde scope lezen, wijzigen of verwijderen.
De veiligste architectuur combineert least privilege, een expliciete allowlist, sandboxing, afzonderlijke rechten voor lezen en schrijven, backups vóór mutaties en volledige logging. Nog beter is het wanneer de agent niet rechtstreeks met het bestandssysteem communiceert, maar via een beperkte tool-laag die zelfstandig controleert welke bestanden en acties zijn toegestaan.
Waarom brede bestandstoegang gevaarlijk is
Een AI-agent verschilt van een gewone chatbot doordat hij zelfstandig acties kan uitvoeren. Zodra je hem tools geeft om bestanden te openen, te verplaatsen, te wijzigen of te verwijderen, kan een verkeerd besluit dus gevolgen hebben buiten het gesprek zelf.
Prompt-injectie is daarbij een belangrijk risico. Een agent kan bijvoorbeeld een document lezen waarin instructies staan die proberen zijn oorspronkelijke taak te veranderen. Als die agent tegelijkertijd onbeperkte bestandstoegang heeft, kan zo'n instructie hem ertoe brengen andere directories te inspecteren, vertrouwelijke informatie op te halen of bestanden te wijzigen.
Maar kwaadaardige instructies zijn niet het enige probleem. Agents maken ook gewone fouten. Een verkeerd geïnterpreteerd pad, een te brede glob zoals "*" of een fout in een recursieve operatie kan honderden bestanden raken terwijl slechts één bestand bedoeld was. Veilige bestandstoegang moet daarom niet afhankelijk zijn van de verwachting dat het model altijd de juiste beslissing neemt. De infrastructuur moet begrenzen wat technisch mogelijk is.
Pas least privilege toe op agents
Het principe van least privilege betekent dat een systeem alleen de rechten krijgt die noodzakelijk zijn voor zijn taak. Voor AI-agents moet je dat letterlijk toepassen op zowel bestanden als acties. Moet een agent documenten uit /project/offertes analyseren, dan is er meestal geen reden om hem ook toegang te geven tot /project/administratie, ~/.ssh of andere gebruikersdirectories.
Een expliciete allowlist is daarbij veiliger dan een denylist. Met een denylist probeer je gevaarlijke locaties uit te sluiten, maar moet je vooraf alle plekken kennen die beschermd moeten worden. Een allowlist draait dat om: standaard is niets toegankelijk en alleen expliciet goedgekeurde locaties worden beschikbaar. Die scope kan bovendien per taak verschillen. Een agent die facturen analyseert hoeft niet dezelfde volumes te zien als een agent die broncode onderhoudt.
Direct bestandssysteem of beperkte tool-laag
Er is een belangrijk architectuurverschil tussen een agent die rechtstreeks bestandssysteemcommando's mag uitvoeren en een agent die alleen gespecialiseerde tools krijgt. Bij directe toegang kan het model bijvoorbeeld shellcommando's uitvoeren of filesystem-API's aanroepen. De agent krijgt daarmee relatief veel vrijheid. Zelfs wanneer je hem instrueert binnen één directory te blijven, is die instructie op zichzelf geen harde beveiligingsgrens.
Een veiliger patroon is een beperkte tool-laag, bijvoorbeeld via een eigen API of MCP-server. Je kunt daar functies aanbieden zoals read_document(), list_project_files() en save_generated_report(). Die tussenlaag controleert vervolgens zelf of het gevraagde pad binnen de toegestane directory ligt en of de operatie is toegestaan. De beveiliging zit dan niet alleen in de prompt, maar in code buiten het model. Dat is een fundamenteel sterkere grens.
Beoordeel lezen en schrijven afzonderlijk
Read-only toegang is niet hetzelfde risico als write-toegang. Een agent die bestanden alleen hoeft samen te vatten, hoeft normaal gesproken geen wijzigingsrechten te krijgen. Ook lezen is niet risicoloos: vertrouwelijke gegevens kunnen worden blootgesteld of naar externe modellen worden gestuurd. Maar schrijven introduceert aanvullende risico's zoals beschadiging, overschrijven en ongewenste configuratiewijzigingen.
Destructieve acties verdienen nog strengere behandeling. Verwijderen, bestaande bestanden overschrijven en recursieve chmod- of chown-operaties zouden niet zelfstandig door een agent uitgevoerd moeten kunnen worden. Gebruik hiervoor bijvoorbeeld expliciete menselijke bevestiging, een afzonderlijke privileged tool of een workflow waarin de agent eerst een wijzigingsvoorstel maakt en pas na goedkeuring de mutatie uitvoert.
Maak iedere mutatie herstelbaar
Een goede beveiliging voorkomt niet alleen fouten, maar maakt fouten ook herstelbaar. Een praktisch uitgangspunt is daarom backup vóór iedere relevante mutatie. Voordat een agent een bestaand bestand overschrijft of verwijdert, wordt eerst een herstelbare kopie, snapshot of versie gemaakt.
Hoe je dat technisch uitvoert hangt af van de omgeving. Voor broncode kan versiebeheer voldoende zijn. Voor documenten kan een kopie naar een afzonderlijke backup-directory werken. Bij grotere volumes kunnen filesystem-snapshots geschikter zijn. Belangrijk is dat de agent niet tegelijkertijd ongecontroleerde rechten heeft om ook zijn eigen backups te verwijderen. Anders bevindt de herstelmogelijkheid zich binnen hetzelfde faaldomein als de oorspronkelijke actie.
Log wat de agent daadwerkelijk doet
Wanneer een agent bestanden kan benaderen, moet achteraf reconstrueerbaar zijn wat er is gebeurd. Log minimaal welk bestand is gelezen, gemaakt, gewijzigd, verplaatst of verwijderd, welke tool daarvoor is gebruikt en wanneer de actie plaatsvond. Bij mutaties is het nuttig ook vast te leggen welke agent-run of opdracht aanleiding gaf tot de wijziging.
Logging helpt bij incidentonderzoek, maar ook bij het verbeteren van de beveiliging. Misschien blijkt bijvoorbeeld dat een agent structureel veel meer directories scant dan voor zijn taak noodzakelijk is. Dat is een aanwijzing dat zijn toegangsmodel verder kan worden beperkt. Auditlogs moeten bij voorkeur buiten het bereik van de agent zelf worden opgeslagen. Een agent die zijn eigen logbestand kan aanpassen, ondermijnt de waarde ervan als controlemechanisme.
Let op symlinks en pad-traversal
Een allowlist op directorynamen is onvoldoende als je bestandspaden niet veilig verwerkt. Stel dat een tool toegang toestaat tot /data/project en de agent een bestandsnaam uit user-input mag toevoegen. Een invoer zoals ../../andere-map/bestand kan via pad-traversal proberen buiten de toegestane directory te komen.
Symlinks veroorzaken een vergelijkbaar probleem. Een bestand dat ogenschijnlijk binnen de toegestane map staat, kan via een symbolic link verwijzen naar een locatie erbuiten. Los dit niet op met alleen tekstcontroles zoals zoeken naar "../". Normaliseer en resolve het volledige pad op filesystemniveau en controleer vervolgens of het uiteindelijke doel daadwerkelijk binnen de toegestane root valt. Houd ook bij schrijfoperaties rekening met race conditions waarbij paden tussen controle en gebruik kunnen veranderen.
Lokaal draaien is niet automatisch veilig
Een lokaal draaiende agent voelt soms veiliger omdat gegevens het eigen systeem niet hoeven te verlaten. Maar als die agent draait met dezelfde rechten als de ingelogde gebruiker, kan hij potentieel alles benaderen wat die gebruiker kan benaderen. Dat kan home-directories, cloud-synchronisatiemappen, NAS-mounts, SSH-sleutels en configuratiebestanden omvatten.
Een containerized of gesandboxte agent biedt een sterkere technische grens. Geef de container alleen expliciet geselecteerde volumes en mount bestanden waar mogelijk read-only. Gebruik daarnaast een eigen serviceaccount of beperkte gebruiker in plaats van de volledige rechten van de menselijke gebruiker. Een container is geen magische beveiligingsoplossing, maar hij maakt least privilege wel veel concreter afdwingbaar.
Conclusie
Veilige bestandstoegang voor AI-agents begint met de aanname dat de agent fouten kan maken of gemanipuleerd kan worden. Geef daarom alleen expliciet toegestane bestanden en acties vrij, scheid read- en write-rechten, plaats bij voorkeur een gecontroleerde tool-laag tussen model en filesystem en vereis extra controle voor destructieve acties. Combineer dat met backups, auditlogging en bescherming tegen pad-traversal en symlinks. De belangrijkste beveiligingsregel is eenvoudig: laat niet de prompt bepalen wat de agent niet mag doen, maar zorg dat de infrastructuur het onmogelijk maakt.