Eén sleutel voor elke klant: het stille risico van uw automatiseringsserver

Het eerste account op een nieuwe automatiseringsserver is een beheerdersaccount. Dat is normaal. Iemand moet de server immers inrichten.

Daarna wil een collega een flow bouwen. De snelste oplossing is om die collega ook beheerdersrechten te geven. Een script moet runs starten, dus krijgt het een sleutel. Die sleutel belandt in een configuratiebestand. Vervolgens komt er een tweede klant bij. Het werk voor die klant draait op dezelfde server, want die staat er toch al. Een jaar later hebben vijf mensen beheerdersrechten, geeft één sleutel toegang tot elke workflow en staan de gegevens van drie klanten in dezelfde database.

Er is niets misgegaan. Er is geen alarm afgegaan. Juist dat maakt dit risico zo verraderlijk. Het gaat niet om één incident, maar om een structuur die bij elke snelle oplossing een beetje verder groeit.

Dit patroon komt steeds terug op gebruikersforums over automatiserings- en agenttools. Eén team bouwde AI-workflows waarin AI agents externe diensten aanroepen, interne databases lezen en gedeelde documenten aanpassen. Toen het team het werk overdroeg aan een kleine groep collega's, bleek er geen goede manier te zijn om vast te leggen welke personen en workflows welke toegangsgegevens (credentials) mochten gebruiken. Een andere gebruiker wilde dat een agent namens iemand kon handelen zonder dat er permanent een sleutel in een configuratiebestand stond. Hij vroeg om sleutels met een korte geldigheidsduur, beperkte rechten en een eenvoudige manier om ze in te trekken. De tools die hij vond, waren daar niet op ingericht.

Klanten vormen een derde uitdaging. Eén gebruiker wilde één gedeelde server gebruiken voor externe klanten die elkaar niet vertrouwen. Ervaren gebruikers wezen erop dat projecten op die server bedoeld waren om samen te werken, niet om klanten van elkaar af te schermen. Beheerders konden alle toegangsgegevens en runs bekijken, terwijl alle projecten dezelfde database en encryptiesleutel deelden. Hun advies was om voor elke klant een aparte installatie te gebruiken.

Grotere organisaties lopen tegen hetzelfde probleem aan, maar in een andere vorm. Een beheerder van een grootschalige uitrol kon niet voorkomen dat gebruikers agents publiceerden zonder hun ook rechten te ontnemen die ze voor ander werk nodig hadden. Een ander team dat de software zelf host, ontdekte dat hun API keys dezelfde gegevens konden benaderen als de eigenaar van de werkruimte, ongeacht wie de sleutel had aangemaakt.

Een persoon met beheerdersrechten gebruikt nog steeds zijn eigen oordeel. Die persoon opent het ene record en daarna het volgende, en aarzelt voordat er iets wordt verwijderd.

Een AI agent werkt niet op dezelfde manier. Die leest, beslist en voert acties uit via tools, vaak snel en herhaaldelijk. Wilt u eerst weten wat een AI agent is, lees dan onze uitleg. Alles waartoe de toegangsgegevens toegang geven, kan ook binnen het bereik van de agent vallen. Een verkeerde instructie, een verwarrend document of een gewone bug kan daardoor in één keer alle rechten benutten die aan de gebruikte sleutel zijn gekoppeld.

Bij AI agents is toegang dus geen onbelangrijk detail van de inrichting. Die bepaalt hoe groot de mogelijke schade door een fout kan zijn. Elke tool die u koppelt, kan het risico vergroten; daarover schreven we in elke tool die u een AI agent geeft, is een deur die u openlaat.

Least privilege, oftewel het principe van minimale rechten, is een beproefd uitgangspunt. Elke persoon, elk programma en elke sleutel krijgt alleen de toegang die nodig is voor de betreffende taak, en niets meer. Voor een server waarop AI agents draaien, komt dat neer op drie vragen.

Wie mag wat? Niet iedereen hoeft beheerder te zijn. De meeste mensen bouwen flows of voeren ze uit. Sommigen hoeven alleen resultaten te bekijken. Slechts een kleine groep beheert gebruikers en toegangsgegevens. Met een rollenmodel dat alleen de opties 'admin' en 'gebruiker' biedt, moet u al snel meer rechten toekennen dan nodig is.

Waartoe heeft elke sleutel toegang? Een sleutel die door een heel team wordt gedeeld, is moeilijk te herleiden en in te trekken. Als zo'n sleutel uitlekt, weet u niet wie hem heeft gebruikt. Trekt u hem in, dan werkt niets meer dat ervan afhankelijk is. Een sleutel die aan één persoon is gekoppeld en de rechten van die persoon heeft, is eenvoudiger te beheren. Een sleutel met een vervaldatum beperkt bovendien de mogelijke schade als iemand vergeet een sleutel in te trekken.

Waar houdt de ene klant op en begint de andere? Dit is de lastigste vraag, en ook de vraag waarop teams het vaakst vertrouwen op een scheiding die er in de praktijk niet is. De eenvoudigste oplossing is al lang bekend: geef elke klant een eigen installatie, database en encryptiesleutel. Een scheiding die u aan een auditor kunt laten zien, is eenvoudiger te verdedigen dan een instelling waarvan u maar moet aannemen dat die voldoende bescherming biedt.

EpicStaff draait op uw eigen infrastructuur. U beheert dus de server, de database en de mensen die daarvoor verantwoordelijk zijn.

Mensen. Een beheerder geeft elke gebruiker een rol. Elke rol geeft aan wat die gebruiker mag doen met flows, agents, tools en toegangsgegevens. De ingebouwde rollen zijn Org Admin, Member en Viewer. Een organisatie kan ook eigen rollen aanmaken, met rechten voor aanmaken, lezen, bijwerken, verwijderen, exporteren, gebruiken en weergeven (create, read, update, delete, export, use en list) per onderdeel.

Toegangsgegevens. De toegangsgegevens van tools worden opgeslagen als versleutelde geheimen van uw organisatie. Ze worden niet in de flow zelf opgenomen. Alleen rollen met het recht om toegangsgegevens te gebruiken, kunnen opgeslagen toegangsgegevens aan een tool koppelen. Het recht 'use' (gebruiken) voor toegangsgegevens geldt voor alle toegangsgegevens van de organisatie. EpicStaff biedt geen mogelijkheid om een rol wel toegang te geven tot bepaalde toegangsgegevens, maar niet tot andere.

Agents. In EpicStaff kan een agent een ander systeem alleen bereiken via tools die uw team eraan koppelt: Python-tools, die u zelf kunt bouwen of kant-en-klaar van EpicStaff kunt gebruiken, of een MCP-server die uw team aansluit. Elke agent krijgt een eigen set tools. De tools van de ene agent worden dus niet automatisch gedeeld met alle andere agents. Heeft een tool toegang nodig, dan wordt die expliciet gekoppeld. Elke tool gebruikt alleen de opgeslagen toegangsgegevens die eraan worden toegewezen. Die toegangsgegevens horen bij de organisatie, niet bij één specifieke flow.

Sleutels. API keys zijn gekoppeld aan een gebruiker en hebben de rechten van die gebruiker. De sleutel van een gebruiker kan verlopen en kan worden ingetrokken. Daarnaast is er één installatiesleutel, die wordt ingesteld door de beheerder van de installatie. Deze sleutel heeft alle rechten en verloopt niet. Om de sleutel te vervangen, stelt de beheerder van de installatie een nieuwe waarde in en herstart hij EpicStaff. Daarna werkt de oude sleutel niet meer. Behandel deze sleutel als een rootwachtwoord en houd hem buiten uw dagelijkse scripts.

Klanten. Gebruik één installatie per klant. Elke klant krijgt een eigen EpicStaff-installatie op infrastructuur die u beheert.

Gebruik deze tabel om elke agent- of automatiseringsserver te beoordelen die u wilt inzetten. In de laatste kolom staat hoe EpicStaff er op dit moment voor staat, inclusief de beperkingen.

Vraag	Waar u op let	EpicStaff nu
1. Kan ik beperken waartoe elke persoon en elke sleutel toegang heeft?	Rollen met rechten per onderdeel, en sleutels die bij één persoon horen	Ja. Elke gebruiker krijgt een rol. API keys horen bij een gebruiker en hebben de eigen rechten van die gebruiker.
2. Zijn er meer rollen dan "admin" en "gebruiker"?	Ingebouwde rollen en de mogelijkheid om zelf rollen aan te maken	Ja. Org Admin, Member en Viewer, plus eigen rollen, met rechten per onderdeel.
3. Wie mag opgeslagen toegangsgegevens aan een tool koppelen?	Een benoemd recht, niet "iedereen die mag bewerken"	Alleen rollen met het recht om toegangsgegevens te gebruiken.
4. Kan ik een rol beperken tot één specifieke set toegangsgegevens?	Rechten per credential	Nee. Het recht "use" geldt voor alle toegangsgegevens van de organisatie.
5. Kan de sleutel van een gebruiker verlopen, en kan ik hem intrekken?	Een verloopdatum en de mogelijkheid om elke sleutel in te trekken	Ja. De sleutel van een gebruiker kan verlopen, en hij kan worden ingetrokken.
6. Is er een sleutel met alle rechten?	Waar die sleutel wordt bewaard en wie er toegang toe heeft	Ja: de installatiesleutel van de beheerder van de installatie. Die heeft alle rechten en verloopt niet. Bewaak hem, en vervang hem als hij mogelijk is uitgelekt.
7. Krijgt elke agent alleen zijn eigen tools?	Een afzonderlijke set tools per agent, zonder automatisch gedeelde verzameling	Ja. Elke agent krijgt zijn eigen set tools.
8. Blijven geheimen buiten de flows?	Een versleutelde opslag, geen sleutels in flowbestanden	Ja. Toegangsgegevens van tools worden bewaard als versleutelde geheimen van uw organisatie.
9. Hoe worden klanten van elkaar gescheiden?	Een scheiding die u een auditor kunt laten zien	Per installatie. Elke klant krijgt een eigen EpicStaff-installatie, met een eigen database en eigen sleutels, die u bij de installatie instelt, op infrastructuur die u beheert.

Een 'ja' in deze tabel is een begin, geen eindpunt. U bepaalt zelf wie de rol Org Admin krijgt, welke rollen het recht 'use' krijgen en waar de installatiesleutel wordt bewaard. Leg die keuzes vast voordat de eerste agent wordt ingezet.