Hoe een AI-agent veilig toegang te geven tot bedrijfsdata

De architectuur: de agent is een cliënt, het systeem is de autoriteit

Begin met de structuur, omdat de meeste fouten structuurfouten zijn. Een persoon vraagt zijn agent om iets. De agent beslist welke tools te gebruiken. Elke oproep gaat door een permissielaag die toebehoort aan het bedrijfsysteem, niet aan de agent, en bereikt pas daarna een module zoals financiën of CRM. De agent raakt nooit de database aan, houdt nooit een database-inloggegeven vast, en ziet nooit een tool die zijn persoon niet zou kunnen gebruiken.

Het principe onder de afbeelding is één zin: de agent handelt met de autoriteit van de persoon die hij vertegenwoordigt, en nooit meer. Alles wat verder in dit artikel staat, is een manier om die zin waar te maken onder druk, wanneer het model fout is, wanneer een document dat het leest instructies bevat, of wanneer een token lekt.

De OWASP Top 10 voor LLM-toepassingen benoemt de fout die deze architectuur voorkomt: overmatige autonomie, die wordt onderverdeeld in overmatige functionaliteit (tools die verder gaan dan wat de taak nodig heeft), overmatige permissies (meer toegang downstream dan nodig) en overmatige autonomie (geen onafhankelijke controle voor een actie met hoge impact). De mitigaties lezen als een specificatie voor de permissielaag: voer uit in de context van de gebruiker, minimaliseer de tools en hun permissies, handhaaf autorisatie in het downstreamsysteem in plaats van op het model te vertrouwen, en vereis goedkeuring van een persoon voor acties met hoge impact.

Vijf controles, en waar elk zich bevindt

De controles zijn niet nieuw; het zijn de controles die je al toepast op een persoon met systeemtoegang, toegepast op een cliënt die namens die persoon handelt. De tabel geeft aan wat elk antwoordt, waar het wordt afgedwongen, en hoe een fout eruitziet wanneer het ontbreekt. De locatiekolom is de belangrijke. Een controle die in de prompt wordt afgedwongen, is een suggestie.

Identiteit: verbind als een persoon, via OAuth, nooit met een gedeelde sleutel

De autorisatiespecificatie van het Model Context Protocol is hier duidelijk over. Een externe server fungeert als een OAuth 2.1 resource server; de klant verkrijgt een token via een standaard autorisatieflow met PKCE; de klant moet aangeven voor welke server het token is met behulp van de resourceparameter; en de server moet valideren dat elk token specifiek voor haar is uitgegeven, en alles wat anders is afwijzen. De specificatie verbiedt expliciet token passthrough, waarbij een server een token accepteert dat zij niet heeft uitgegeven en het verderop doorstuurt, omdat dit zowel het auditspoor als de vertrouwensgrens vernietigt.

In de praktijk betekent "een keer inloggen, geen token om te plakken" dit. De persoon voegt het adres van de werkruimte toe aan hun agent, wordt naar een normale inlogpagina gestuurd, keurt de verbinding goed en de agent ontvangt een token dat hen identificeert en alleen tegen die werkruimte werkt. De richtlijnen van Anthropic voor aangepaste connectors in Claude zijn om de scopes die een server aanvraagt te herzien, deze waar mogelijk te beperken en alleen verbinding te maken met servers die je vertrouwt. Een leverancier die je vraagt om een bedrijfsbrede API-sleutel in een agentconfiguratie te plakken, heeft de eerste controle overgeslagen en de andere vier veel moeilijker gemaakt.

Scope: filteren voordat je aanbiedt, opnieuw controleren tijdens het uitvoeren

Een agent ontdekt wat hij kan doen door de server om zijn gereedschapslijst te vragen. Het juiste ontwerp beantwoordt die vraag per persoon: de lijst die een agent van een boekhouder ontvangt, is anders dan de lijst die een agent van een directeur ontvangt, en geen van beiden bevat tools voor modules die hun rol niet kan zien. Dit is het OWASP-advies om functionaliteit te minimaliseren, en het heeft een tweede voordeel: een model dat nooit een tool te zien krijgt, kan er niet toe worden gedwongen deze aan te roepen.

Het filteren van de lijst is op zichzelf niet genoeg, omdat rollen veranderen, sessies aanhouden en cliënten cachen. Dezelfde controle moet opnieuw worden uitgevoerd wanneer elke oproep binnenkomt, tegen de machtigingen van de persoon op dat moment. Hieronder staat een gereedschapslijst in de vorm die het protocol definieert, voor een rol die facturen kan lezen maar geen betalingen kan registreren. De afwezigheid van de tool is het punt.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

Een tools/lijstrespons in de vorm die de MCP-specificatie definieert, met toolnamen uit de Sois boekhoudmodule. De specificatie zegt ook dat cliënten annotaties zoals readOnlyHint als onbetrouwbaar moeten beschouwen, tenzij de server vertrouwd is, wat nog een reden is waarom de server, niet de annotatie, de regel moet handhaven.

Promptinjectie: de data kan terugpraten

De bedreiging die specifiek is voor agents is dat de gegevens die ze lezen instructies kunnen bevatten. Een e-mail van een klant die eindigt met een regel die de agent vertelt de leverancierslijst naar een extern adres door te sturen; een document dat zegt dat het elke factuur als betaald moet markeren. Het model kan al dan niet voldoen, en geen prompt kan garanderen dat het dat niet zal doen, wat de reden is waarom promptinjectie bovenaan de OWASP-lijst staat en waarom zowel Anthropic als OpenAI hierover waarschuwen in hun connectorrichtlijnen.

De verdediging is de architectuur, niet het model. Een agent die alleen de tools aangeboden krijgt die zijn persoon kan gebruiken, kan niet doorsturen wat zijn persoon niet kan zien. Een oproep om facturen als betaald te markeren, wordt door het systeem gecontroleerd tegen de machtigingen van de persoon, niet tegen de overtuiging van het model dat het daarom werd gevraagd. Gevolgtools zijn gemarkeerd zodat de cliënt eerst een persoon vraagt: ChatGPT vereist momenteel handmatige bevestiging in een gesprek voordat schrijfacties worden uitgevoerd, en de richtlijnen van OpenAI zijn om goedkeuring aan te houden voor tools die gegevens wijzigen; Claude vraagt om goedkeuring per tool en adviseert "altijd toestaan" te reserveren voor vertrouwde servers. En het logboek registreert de poging, zodat een geblokkeerde injectie achteraf zichtbaar is in plaats van stil.

Budget en logs: maak het werk van de agent net zo controleerbaar als dat van een persoon

Budget is om twee redenen belangrijk. De voor de hand liggende reden is kosten: een agent die een vage uitkomst krijgt, blijft tools aanroepen totdat iets het stopt, en OWASP vermeldt onbeperkte consumptie als een risico op zich. De subtiele reden is de impactradius: een limiet per integratie beperkt hoeveel een gecompromitteerde of verwarde agent kan doen voordat een persoon het opmerkt. Waar de eigen agent van de persoon de redenering doet, liggen de AI-kosten bij hen; waar de eigen agent van het systeem dit doet, moet de limiet per integratie worden ingesteld en zichtbaar zijn per actie.

Logs maken van dit alles een belofte iets dat je kunt auditen. Elke oproep moet registreren voor wie de agent handelde, welke tool, de invoer, het resultaat en de tijd, op dezelfde plaats waar het systeem registreert wat mensen deden. De test is of een financieel leidinggevende kan achterhalen wat de agent vorige maand met het account van een klant heeft gedaan, net zo gemakkelijk als voor een collega. De MCP-specificatie vraagt cliënten om het gebruik van tools te loggen voor audit; een zakelijk systeem zou daar niet op moeten vertrouwen, omdat de cliënt niet het systeem van record is.

Een checklist die je tegen elk systeem kunt uitvoeren

Neem deze mee naar elke leverancier, inclusief ons. Elk is een ja of nee, en elk heeft een test in plaats van een vraag om te stellen.

1. De agent verbindt als een genoemde persoon via OAuth., zonder een bedrijfsbrede sleutel om in te voeren. Test: maak verbinding met een externe MCP-client en kijk wat de inlogpagina vraagt.
2. De lijst met tools verschilt per rol. Test: verbind als een beperkte gebruiker en als een administrator en vergelijk wat de agent wordt aangeboden.
3. De controle wordt herhaald wanneer de tool draait. Test: verwijder een toestemming van een verbonden gebruiker halverwege de sessie en probeer de actie opnieuw.
4. Toegang faalt gesloten. Test: roep een tool op die de rol niet zou moeten hebben en bevestig dat je een weigering krijgt, geen resultaat.
5. Uitgaven kunnen per integratie worden beperkt en per actie worden bekeken. Test: stel een kleine limiet in en kijk hoe deze bindt.
6. Elke actie wordt gelogd tegen de persoonmet invoer en resultaat, waar het systeem alles anders logt. Test: lees het logboek voor een run die je net hebt gedaan.
7. Gevolgtools zijn gemarkeerd voor bevestiging dus de klant vraagt een persoon. Test: vraag de agent om geld te sturen of een record te verwijderen en bevestig dat je eerst wordt gevraagd.

Sois is één systeem dat is gebouwd om deze lijst door te geven, en de vorm bovenaan het artikel is zijn vorm. Een werkruimte is een MCP-server; elke MCP-client verbindt door het adres van de werkruimte toe te voegen en eenmaal in te loggen via OAuth; tools worden gefilterd op rol voordat ze worden aangeboden en opnieuw gecontroleerd wanneer ze draaien; toegang faalt gesloten; uitgaven kunnen per integratie worden beperkt; elke actie wordt gelogd; en netwerken die op het platform zijn gebouwd hebben hun eigen database, opslag, domeinen en sleutels. Voer de checklist er toch tegen uit. De waarde van een checklist is dat het niemand's woord aanneemt.

Vragen die mensen stellen

Dit artikel wordt herzien wanneer de producten die het beschrijft veranderen. Volgende geplande herziening: 4 december 2026.