Elke tool die u een AI agent geeft, is een deur die u openlaat

De meeste teams kunnen zeggen wat hun AI agent hoort te doen. Veel minder teams kunnen zeggen wat de agent daadwerkelijk kan doen. Juist het verschil tussen die twee antwoorden zorgt voor verrassingen.

Een AI agent is een taalmodel met een set tools en een lus. De prompt vertelt het model wat u wilt. De tools bepalen waartoe de agent daadwerkelijk toegang heeft: welke systemen hij kan raadplegen, welke records hij kan wijzigen en welke berichten hij kan versturen.

Die twee worden gemakkelijk door elkaar gehaald, omdat het team veel tijd besteedt aan de prompt. Mensen schrijven zorgvuldige instructies: zoek alleen bestellingen op, voer nooit een terugbetaling boven een bepaalde grens uit, neem geen contact op met klanten. Die instructies sturen wat het model probeert te doen. Maar het zijn aanwijzingen voor het model, geen regel die het systeem afdwingt. Als de agent een tool heeft waarmee hij een terugbetaling kan uitvoeren, kan hij die terugbetaling uitvoeren, ongeacht wat er in de prompt staat.

Het echte antwoord op de vraag "wat mag deze agent doen?" staat dus niet in de prompt. Het staat in de lijst met tools die aan de agent zijn gekoppeld en in wat elk van die tools kan bereiken.

Teams die agents daadwerkelijk werk laten uitvoeren, beschrijven steeds dezelfde verrassing: de agent roept een tool aan waarvan niemand had verwacht dat hij die zou gebruiken.

Het mechanisme is eenvoudig. Bij elke stap ziet een model alle tools die het heeft gekregen. Het is getraind om behulpzaam te zijn. Als een tool relevant lijkt, gebruikt het die. Eén team meldde bijvoorbeeld dat het een marketingagent een lange lijst met tools had gegeven. Toen de agent om één kleine taak werd gevraagd, schreef hij zijn resultaten ook weg in een spreadsheet waar niemand om had gevraagd. Er ging niets kapot. Maar niemand had besloten dat deze agent voor dit verzoek bestanden zou schrijven. Zo'n aanroep ziet u alleen als er een runverslag is waarin elke tool-aanroep wordt vastgelegd.

Andere gevallen zijn minder onschuldig. Een agent met een sleutel met volledige toegang tot een klantsysteem kan records in bulk bijwerken of verwijderen als niets in de configuratie dat tegenhoudt. Een klantenserviceagent met een geldige sleutel kan een normaal gesprek afsluiten met een terugbetaling die nooit had mogen plaatsvinden, zonder dat daar een aanval voor nodig is. Een agent met een rechtstreekse databaseverbinding kan elke query uitvoeren die de verbinding toestaat.

Hiervoor is geen slimme aanvaller nodig. Er is alleen een tool nodig die verder reikt dan de taak en een model dat een reden vindt om die tool te gebruiken. Voegt u daar een aanvaller aan toe, bijvoorbeeld via tekst in een e-mail of op een webpagina die de agent vertelt wat hij moet doen, dan kan diezelfde brede tool ook voor iemand anders worden gebruikt.

De oplossing begint met een gewoonte, niet met een product. Kies de tools per agent en geef elke agent alleen de kleinste set waarmee hij het werk kan doen.

Begin bij nul. Vraag bij elke tool wat de agent zonder die tool niet kan. Is het antwoord "niets belangrijks", laat de tool dan weg. Een tool die niet is gekoppeld, kan niet worden aangeroepen, niet worden misbruikt en niet tegen u worden gebruikt.

Kies liever beperkte tools dan brede tools. Een tool die één bestelling opzoekt aan de hand van het bestelnummer, is makkelijker te overzien dan een tool waarmee u elke query op de database met bestellingen kunt uitvoeren. De brede tool is sneller gebouwd. De beperkte tool is de tool die u aan een auditor kunt uitleggen.

Wees voorzichtig met tools voor algemeen gebruik. Een shell, een omgeving waarin code kan worden uitgevoerd of een functie waarmee elke webpagina kan worden opgehaald, is niet één tool. Het is toegang tot elke handeling die vanaf die plek mogelijk is. Een lijst met toegestane opdrachten helpt minder dan het lijkt als de agent een kort script kan schrijven dat hetzelfde op een andere manier doet.

De naam van een tool zegt waarvoor de tool bedoeld is. De naam zegt niet wat de tool daadwerkelijk kan bereiken. Leg voor elke tool in uw lijst vier dingen vast.

• Netwerk. Welke adressen kan de tool aanroepen? Eén interne dienst of elke plek op het internet?
• Bestanden. In welke mappen kan de tool lezen of schrijven?
• Gegevens. Welke records kan de tool inzien, en kan de tool deze wijzigen of verwijderen?
• Andere systemen. Welke toegangsgegevens gebruikt de tool, en waartoe geven die toegang?

Vaak is de tool zelf niet het probleem. Het probleem is de sleutel die erachter zit. Een beperkte tool met een sleutel met volledige toegang is in feite een brede tool. De enige beperking is dan wat de eigen code van de tool toestaat, en agents zijn goed in het vinden van de grenzen van code.

Beveiligingsteams weten al hoe ze hiermee moeten omgaan. Ze houden toegangslijsten bij voor mensen en serviceaccounts en controleren die volgens een vast schema. De lijst met tools van een agent verdient dezelfde behandeling. Een niveau hoger speelt dezelfde vraag voor het platform zelf: wie controleert de agent-harness?

Controleer de lijst wanneer de agent verandert: bij een nieuwe taak, een nieuwe tool, een nieuw model of een nieuwe gegevensbron. Controleer de lijst ook wanneer een tool verandert, want een nieuwe versie van een connector kan handelingen toevoegen die eerder niet mogelijk waren. En controleer de lijst op vaste momenten, want lijsten met tools worden meestal langer en zelden korter.

Zorg voor één plek waar iedereen per agent kan zien welke tools de agent heeft en waartoe elke tool toegang geeft. Als dat antwoord alleen in het hoofd van één persoon zit, weet u nog steeds niet waartoe uw agent toegang heeft.

Kies één agent en doorloop deze week de volgende vier stappen. Ze werken op elk platform, ook op het onze.

1. Schrijf elke route naar buiten op. Maak een lijst van de tools van de agent en controleer of de lijst met tools de enige manier is waarop de agent andere systemen kan bereiken. Noteer ook waarmee het platform zelf verbinding naar buiten maakt, los van de tools die u koppelt.
2. Geef de agent zijn eigen set. Controleer of de agent zijn eigen tools heeft en niet één gedeelde set voor alle agents. Verwijder elke tool die de agent niet nodig heeft om zijn werk te doen.
3. Breng in kaart wat elke tool kan bereiken. Noteer per tool welke adressen, bestanden, gegevens en systemen de tool kan bereiken. Laat uw platform dit niet zien, kijk dan in de eigen code en instellingen van de tool.
4. Beperk de toegangsgegevens. Controleer per tool welke toegangsgegevens de tool gebruikt en beperk die tot wat de tool nodig heeft. Plan daarna de volgende controle in.

Hoe EpicStaff bij deze stappen past

Bij stap 1: in EpicStaff kan een agent een ander systeem alleen bereiken via tools die uw team eraan koppelt: Python-tools, uw eigen tools of kant-en-klare tools die EpicStaff meelevert, of een MCP-server die uw team aansluit. MCP staat voor Model Context Protocol, een gangbaar protocol om een toolserver met een agent te verbinden. Naar buiten maakt EpicStaff alleen verbinding met de aanbieders waarvoor u sleutels configureert. Tools doen wat u ze opdraagt. Een tool die u bouwt of inschakelt en die het internet bereikt, is uw keuze en uw configuratie.

Bij stap 2: elke agent krijgt zijn eigen set tools. De tools van één agent worden niet gedeeld met alle andere agents.

Bij stap 4: elke tool gebruikt alleen de opgeslagen toegangsgegevens die aan die tool zijn verstrekt. Toegangsgegevens horen bij de organisatie, niet bij één afzonderlijke flow.

Stap 3 ligt bij u: wat een tool kan bereiken, hangt af van de eigen code en de sleutel erachter. Controleer dit daarom per tool.