Veilig toegang geven aan een AI-agent tot bedrijfsdata

De vraag die elk bestuur hoort te stellen voordat een agent wordt gebouwd: wat kan deze zien, en wat kan deze doen? Goede agent-beveiliging is geen aparte fase achteraf, maar een ontwerpkwestie vanaf dag één.

Principe 1: minimale rechten

Een agent krijgt per taak precies de bronnen die die taak vraagt — niet meer. Technisch betekent dat: geen gedeelde superuser-account, maar scoped credentials per integratie. De agent erft idealiter de rechten van de gebruiker namens wie hij handelt; kan hij meer dan die gebruiker, dan zit er een fout in het ontwerp.

Principe 2: harde grenzen op acties

Leg per agent vast welke acties zelfstandig mogen en welke een goedkeurstap vereisen. Leesbewerkingen kunnen vrijwel altijd automatisch; schrijf- en externe acties (mails versturen, orders plaatsen, records verwijderen) verdienen een drempel — zeker in de eerste periode. Grenzen horen in code, niet in een prompt: 'beloof me dat je dit niet doet' is geen beveiliging.

Principe 3: log alles, audit regelmatig

• Elke opgevraagde bron en uitgevoerde actie wordt gelogd met context (wie, wanneer, waarom).
• Logs maken evaluatie mogelijk: welke antwoorden waren fout, welke acties onterecht?
• Periodieke review van logs is de enige manier om drift in gedrag op tijd te zien.

Principe 4: let op datastromen richting modellen

Weet welke data naar welke externe dienst gaat en onder welke voorwaarden. Privacygevoelige velden filter je vóór verzending, niet achteraf. Voor gevoelige omgevingen zijn hostingkeuzes en dataverwerkingsafspraken een selectiecriterium voor het model, geen bijzaak.

Principe 5: verwacht misbruik

Gebruikers proberen uit nieuwsgierigheid of kwaadwil grenzen te testen: prompt-injectie via documenten, verzoeken buiten scope, social engineering. Invoerfiltering, duidelijke weigerregels en het beperken van wat agent-output kan triggeren (bijv. geen directe code-executie) horen tot de basis.