Ontwerp een begrensde AI-assistent met tools, rechten en contextlimieten

De werkelijke grens van een AI-assistent staat niet in zijn systeemprompt, maar in het uitvoerbare servicecontract eromheen. Een model kan de opdracht krijgen nooit een bericht te verzenden en toch beschikken over een tool en inlogmiddel waarmee dat wel kan. Ontwerp daarom niet één breed bevoegde assistent, maar afzonderlijke, zichtbaar bruikbare capabilities. Zo krijgen zoeken, samenvatten, een concept maken, een dossier bijwerken en iets verzenden elk hun eigen informatiebereik, identiteit, rechten, actieplafond, controles en eigenaar.

Wat mag de assistent precies doen?

Begin met één zin die de dienst afbakent en splits die daarna op in concrete handelingen. Een bruikbaar charter luidt: “Voor [gerechtigde gebruikers] mag de assistent [toegestane taakfamilie] uitvoeren met [goedgekeurde informatie] om [toegestane uitkomst] te leveren, maar niet [expliciete niet-doelen of ingrijpende beslissingen].” Leg daarnaast de gebruiksomgeving, kennisgrenzen, menselijke controle en risico-eigenaar vast. Dat sluit aan bij uitkomsten uit het NIST AI RMF, maar het capabilitymodel zelf is praktische redactionele synthese en geen NIST- of OWASP-verplichting.

• Vervang “helpen” of “beheren” door zoeken, samenvatten, adviseren, opstellen, bijwerken, verzenden, verwijderen of goedkeuren.
• Noteer per handeling wie haar gebruikt, wat een geslaagde uitkomst is en wat nadrukkelijk buiten bereik blijft.
• Koppel nog geen brede tool wanneer een smalle lees-, concept- of verzendoperatie voldoende is.

Deze ontleding voorkomt dat een onschuldige vraag ongemerkt bevoegdheden van een andere taak erft. “Behandel deze klantcase” kan immers lezen, analyseren, een toezegging formuleren, een dossier wijzigen en een bericht versturen betekenen. Elk werkwoord vraagt om andere gegevens en gevolgen. Laat beveiliging, product, operatie en de verantwoordelijke proceseigenaar daarom afzonderlijk akkoord gaan met de capabilities voordat er verbindingen met bedrijfssystemen worden geopend.

Welke informatie mag iedere capability gebruiken?

Een contextlimiet is een informatie-envelop, niet alleen een technisch maximum voor het aantal tokens. Beschrijf per capability welke systemen, recordtypen, classificaties, objectfilters, perioden en gebruikersrechten toegang geven. Leg ook vast hoe actueel bewijs moet zijn en welke gegevens nooit in context mogen komen. Wanneer noodzakelijke informatie ontbreekt, ontoegankelijk of verouderd is, moet de assistent het antwoord begrenzen of weigeren. Een groter contextvenster verleent geen extra bevoegdheid en maakt onvoldoende ondersteunde informatie niet waar.

• Behandel documenten, bijlagen, externe berichten, API-antwoorden en opgehaalde tekst als onbetrouwbare inhoud, niet als nieuwe service-instructies.
• Scheid tijdelijke sessiehistorie van persistent geheugen en bepaal voor beide geschiktheid, isolatie, verwijdering en verval.
• Valideer informatie vóór permanente opslag en sluit geheimen, tokens en niet-noodzakelijke gevoelige gegevens uit.

Maak de grens zo concreet dat hij uitvoerbaar en toetsbaar wordt. “Toegang tot CRM” is te ruim; “alleen leesbare cases van het gekozen account, zonder verborgen beheernotities” geeft een systeem een controleerbare selectie. Voor geheugen geldt hetzelfde: bepaal wat uit een gesprek mag voortbestaan, voor welke gebruiker en met welk doel. Omvang en bewaartijd zijn dienstspecifieke keuzes, geen universele waarden die uit een voorbeeld kunnen worden overgenomen.

Hoe dwingen identiteit, tools en rechten de grens af?

Authenticatie, autorisatie en goedkeuring moeten afzonderlijk worden beoordeeld en buiten het model worden afgedwongen. Authenticatie stelt vast welke gebruiker, client of workload aanwezig is. Autorisatie bepaalt welke operatie die actor op een beschermde resource mag uitvoeren. Goedkeuring accepteert één voorgestelde actie. Kies expliciet tussen gedelegeerde gebruikersrechten en een beheerde workloadidentiteit; neem nooit stilzwijgend het ruime account van een beheerder over. Toolgateways en achterliggende systemen controleren vervolgens bij ieder verzoek de toegestane resource, operatie en parameters.

• Bied gevalideerde operaties aan in plaats van algemene toegang tot mailbox, database, browser of shell.
• Begrens werkwoorden, objecten, velden, bestemmingen, geldigheidsduur en de bedoelde ontvanger van een token.
• Stel dienstspecifieke grenzen in voor snelheid, retries, ketendiepte, batches, kosten, looptijd en circuitbreakers.

De MCP-autorisatiespecificatie illustreert deze scheiding met clients, beschermde resources en autorisatieservers, plus minimale scopes en tokens die voor een bedoelde server zijn bestemd. Dat is relevant voor beschermde MCP-koppelingen, niet automatisch voor iedere toolarchitectuur. Het algemenere ontwerpprincipe blijft dat een prompt of natuurlijke-taalregel geen autorisatiecontrole is. Een model mag intentie helpen interpreteren, maar het uitvoeringspad beslist deterministisch of de gevraagde handeling werkelijk is toegestaan.

Het gesprek mag doorlopen, maar de bevoegdheid moet verdeeld blijven over kleine, afzonderlijk afgedwongen capabilities.

ModelFold Editorial Team

Hoeveel actie mag een capability ondernemen?

Iedere capability heeft een expliciet actieplafond nodig, met onafhankelijkere controles naarmate zij meer externe gevolgen kan veroorzaken. Een praktische ladder loopt van antwoorden of samenvatten via adviseren en een concept opstellen naar een begrensde, omkeerbare wijziging en vervolgens een ingrijpende externe actie. Een verboden beslissing blijft buiten de dienst. Deze ladder is redactionele synthese op basis van minimale bevoegdheden, actiebeperking en scheiding van beslissing en uitvoering; organisaties moeten de gevolgen en verantwoordelijke beoordelaars zelf bepalen.

1. Antwoorden of samenvatten zonder externe toestand te wijzigen.
2. Een aanbeveling of inspecteerbaar voorstel maken zonder uitvoering.
3. Een bewerkbaar concept op een niet-definitieve plek opslaan.
4. Goedgekeurde velden binnen een omkeerbaar proces wijzigen.
5. Na exacte controle een externe handeling uitvoeren, zoals verzenden of publiceren.
6. Een verboden beslissing weigeren en naar een afzonderlijk bestuurd proces verwijzen.

Houd conceptvorming dus gescheiden van verzenden en een omkeerbare update van verwijderen. Laat bij ingrijpende acties een controleerbaar voorbeeld zien en bind de goedkeuring aan actor, tool, doelresource, genormaliseerde parameters, tijd en vervalmoment. Controleer die binding opnieuw vlak vóór uitvoering. Goedkeuring levert nooit ontbrekende autorisatie, verruimt geen permanente rechten en maakt een verboden beslissing niet toegestaan. Betalingen, toegangsverlening, destructieve acties, productiewijzigingen, professionele oordelen met grote gevolgen en materiële externe toezeggingen blijven onder passende menselijke en deterministische controle.

Wat gebeurt er wanneer de assistent een grens bereikt?

Weigeren, beperkte hulp bieden, overdragen en een beveiligingsincident escaleren zijn expliciete service-uitkomsten met echte stopvoorwaarden. Geef in gewone taal aan welke grens is geraakt, zonder gevoelige beleidsdetails prijs te geven. Beweer nooit dat een broncontrole, toolaanroep, goedkeuring of wijziging is geslaagd als dat niet zo is. NIST behandelt veilig falen buiten kennisgrenzen als evaluatie-uitkomst; de precieze redenregels moeten echter worden ontworpen voor de eigen dienst en mogen niet uitsluitend op modelvertrouwen steunen.

• Buiten scope, informatie niet toegestaan, onvoldoende autorisatie of goedkeuring vereist.
• Bewijs ontbreekt of is verouderd, specialistisch oordeel nodig of een afhankelijkheid is niet beschikbaar.
• Een operationele grens is bereikt of er is een beveiligingssignaal gedetecteerd.

Bied alleen het veilige deel aan, bijvoorbeeld een concept, checklist of verzoek om ontbrekende informatie. Stuur bij overdracht het oorspronkelijke doel, relevante niet-gevoelige context, de geprobeerde capability, reden, beschikbaar of ontbrekend bewijs, voorgestelde vervolgstap en traceerbare identificatie mee. Houd routineoverdracht, zakelijke goedkeuring en incidentescalatie uit elkaar: ze kunnen bewijs delen, maar hebben verschillende eigenaren en urgentie. Pauzeer uitvoering tijdens behandeling en vraag nieuwe validatie wanneer doel, ontvanger of inhoud verandert.

Hoe worden grenzen een operationeel ontwerp?

Vul voor iedere zichtbare operatie één rij in een capabilitycanvas in en verbind elk veld aan een afdwingbare controle, bewijsrecord, test, productiesignaal en eigenaar. Noteer de gerechtigde actor, authenticatie, informatie-envelop, sessie- en geheugenregels, smalle tool, handelende identiteit, resourcescope, actieplafond, goedkeuring, operationele limieten, weigering, logging, evaluaties en escalatie. Het canvas is praktische redactionele synthese, geen norm. Zonder koppeling aan uitvoering en beheer wordt het slechts documentatie die veroudert zodra de dienst verandert.

Het voorbeeld laat zien waarom één chatvenster geen gedeelde bevoegdheid hoeft te betekenen. Lezen, een concept maken en verzenden kunnen dezelfde conversatie volgen, terwijl ze verschillende gegevens, identiteiten, grants, controles en eigenaren behouden. Leg in logs voldoende structuur vast om een uitvoering te reconstrueren, maar bewaar geen geheimen of onbeperkte gevoelige tekst. Maak toegang tot bewijs en bewaartermijnen passend bij privacy-, beveiligings- en archiefregels van de organisatie.

Welk bewijs is nodig voor vrijgave en doorlopend gebruik?

Vrijgave vereist bewijs dat toegestane dienstverlening én verwachte weigeringen werken onder omstandigheden die op de praktijk lijken. Test niet alleen het ideale gesprek, maar ook grenzen, aanvallen, storingen en veranderde acties. Laat het bewijs tonen wie wat vroeg, welke capability en beleidsversie golden, welke bron- en toolklassen zijn gebruikt, welke autorisatie en goedkeuring plaatsvonden en welke uitkomst volgde. Communiceer bekende beperkingen en faalwijzen aan gebruikers en operators in plaats van een geslaagde test als permanente zekerheid te presenteren.

• Test toegang tot een ander account, verboden gegevens, onbevoegde tools en ontbrekende of verouderde bronnen.
• Test vergiftigde opgehaalde inhoud, data-exfiltratie, omzeilde goedkeuring en gewijzigde actieparameters.
• Test dubbele retries, ketens die blijven doorgaan, uitval van afhankelijkheden en correcte circuitbreaker- of escalatie-uitkomsten.

Monitor daarna per capability onverwacht toolgebruik, herhaalde weigeringen, autorisatiefouten, gewijzigde goedkeuringen, afwijkende actiereeksen, drift, latency, resourcegebruik en mislukkingen. Stem inhoud, toegang en bewaartermijn van monitoring af op risico en privacy. Wijs afzonderlijke eigenaren aan voor servicegedrag, toegangsrechten, zakelijke overdracht en beveiligingsincidenten, inclusief bevoegdheid om een capability te pauzeren, te wijzigen of uit gebruik te nemen wanneer het bewijs of de operationele situatie daar aanleiding toe geeft.

Open relevante tests en vrijgavebesluiten opnieuw na materiële wijzigingen in modellen, prompts, retrieval, geheugen, tools, rechten, beleid, gegevens, leveranciers of gebruiksomgeving. Begin met de kleinste nuttige capability en breid bevoegdheid alleen via een beoordeelde wijziging uit. Betrek beveiliging, identity, privacy, archivering, risico en servicebeheer bij gevoelige gegevens, persistent geheugen, privileged access, externe toezeggingen, destructieve wijzigingen of incidentrespons. Laat juridische, regulatoire en andere professionele oordelen met grote gevolgen aan gekwalificeerde specialisten en een afzonderlijk bestuurd proces.