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

De werkelijke grens van een AI-assistent staat niet in zijn systeemprompt, maar in het uitvoerbare servicecontract rond het model. Een prompt kan zeggen dat de assistent geen bericht mag verzenden, terwijl een gekoppelde tool en een te ruime identiteit dat technisch wel toelaten. Ontwerp daarom niet één algemene machtiging voor het volledige product. Begrens elke zichtbare capaciteit afzonderlijk: welke informatie ze mag gebruiken, welke toolbewerking ze kan oproepen, onder welke identiteit ze handelt, hoe ver haar actie reikt en wanneer ze moet stoppen. Zo wordt de bedoelde werking vóór de lancering controleerbaar en blijven latere uitbreidingen bespreekbare wijzigingen in plaats van verborgen promptaanpassingen.

Wat mag de assistent precies doen?

Leg eerst een servicecharter van één zin vast en splits dat vervolgens op in concrete capaciteiten. Een bruikbaar patroon luidt: “Voor [bevoegde gebruikers] mag de assistent [toegelaten takenpakket] uitvoeren met [goedgekeurde informatie] om [toegelaten resultaat] te produceren, maar hij mag niet [expliciete niet-doelen of ingrijpende beslissingen].” Benoem daarnaast de gebruiksomgeving, kennisgrenzen, menselijke controle, risico-eigenaar en verboden uitkomsten voordat een tool wordt aangesloten. NIST ondersteunt het documenteren van zulke doelen en grenzen; de uitwerking per capaciteit is een praktische redactionele synthese, geen formele NIST- of OWASP-verplichting.

• Vervang “help klanten” door afzonderlijke bewerkingen zoals een dossier zoeken, een antwoord samenvatten en een reactie opstellen.
• Maak “beheer aanvragen” concreet als lezen, velden bijwerken, een conceptbeslissing voorstellen of een goedgekeurde handeling uitvoeren.
• Noteer per bewerking het succesresultaat en de uitkomsten die de service uitdrukkelijk niet mag veroorzaken.

Die opsplitsing voorkomt dat een onschuldige leesvraag automatisch verzendrechten of toegang tot andere dossiers erft. OWASP beveelt minimale toolfunctionaliteit aan: een gerichte bewerking is beter begrensbaar dan een open mailbox-, database-, browser- of shelltool. Begin dus met de kleinste capaciteit die zelfstandig bedrijfswaarde levert. Voeg een nieuwe bevoegdheid pas toe als haar eigen gegevensscope, uitvoeringspad, tests, meetpunten en verantwoordelijke klaarstaan; een vage uitbreiding van het woord “helpen” is geen controleerbare wijziging.

Welke informatie mag elke capaciteit gebruiken?

Een contextlimiet is eerst een informatie-envelop en pas daarna een technisch aantal tokens. Leg per capaciteit vast welke systemen, recordtypes, classificaties, objectfilters, periodes en gebruikersrechten gegevens toelaten, hoe actueel een bron moet zijn en welke gegevens nooit in de context mogen belanden. Maak ook duidelijk welke conclusies of acties uit die informatie zijn toegestaan. Meer context creëert immers geen extra bevoegdheid en maakt ontbrekend, verouderd of onbevestigd bewijs niet waar. Als noodzakelijke informatie ontoegankelijk, afwezig of te oud is, moet de assistent dat zeggen, zijn antwoord kwalificeren of stoppen.

• Scheid betrouwbare service-instructies van externe berichten, documenten, bijlagen, API-antwoorden en opgehaalde tekst.
• Beperk zoekresultaten tot objecten die de gebruiker voor die specifieke taak al mag bekijken.
• Registreer bronidentificatoren en actualiteit zonder volledige gevoelige context onbeperkt in logs te kopiëren.

Behandel sessiehistoriek en persistent geheugen als twee verschillende voorzieningen. Voor beide zijn regels nodig over geschiktheid, isolatie per gebruiker en sessie, maximale omvang, verval, verwijdering en gegevens die nooit bewaard worden. Valideer informatie voordat ze persistent wordt en bescherm haar integriteit. Concrete limieten volgen uit de eigen privacy-, beveiligings- en archiveringsregels; de voorbeelden uit beveiligingsrichtlijnen zijn geen universele standaardwaarden. Geheugen kan de continuïteit verbeteren, maar verruimt de machtiging niet en mag nooit een stille route worden waarlangs oude instructies of gegevens tussen gebruikers lekken.

Hoe dwingen identiteit, tools en rechten de grens af?

Authenticatie, autorisatie en goedkeuring zijn drie afzonderlijke beslissingen die buiten het taalmodel afdwingbaar moeten blijven. Authenticatie stelt vast wie de gebruiker, client, agent of workload is. Autorisatie bepaalt welke bewerking die identiteit op welke beschermde resource mag uitvoeren. Goedkeuring aanvaardt één concreet voorgestelde actie. Kies daarom bewust tussen gedelegeerde rechten van de gebruiker en een streng beheerde workloadidentiteit; leen nooit stilzwijgend het geprivilegieerde account van een operator. De toolgateway en het achterliggende systeem moeten iedere bewerking en resource opnieuw controleren, ook wanneer de conversatie overtuigend klinkt.

• Bied smalle bewerkingen met gevalideerde parameters aan in plaats van algemene toegang tot een mailbox, databank, browser of shell.
• Beperk werkwoorden, resources, objecten, velden, bestemmingen, duur van referenties en het bedoelde tokenpubliek in het uitvoeringspad.
• Stel servicespecifieke grenzen in voor tempo, herhalingen, ketendiepte, batches, kosten, looptijd, dubbele uitvoering, terugdraaien en noodstops.

Voor beschermde MCP-integraties illustreren minimale scopes en resourcegebonden tokens hoe autorisatie aan de bedoelde server kan worden gekoppeld. Die protocolregels zijn niet automatisch van toepassing op elke andere toolarchitectuur. Het bredere principe blijft wel overeind: prompts en natuurlijke-taalregels zijn geen autorisatiecontrole. Het model mag een bedoeling helpen interpreteren, maar kan geen recht creëren. Veilige standaardinstellingen, minimale bevoegdheid en onafhankelijke noodbeveiligingen moeten de uitvoerbare grens dragen wanneer de assistent externe toestand kan veranderen.

Een gesprek mag doorlopend aanvoelen, maar zijn bevoegdheid hoort uit kleine, afzonderlijk afgedwongen capaciteiten te bestaan.

Hoe ver mag een capaciteit handelen?

Geef elke capaciteit een expliciet actieplafond en versterk de onafhankelijke controles naarmate ze meer externe toestand kan veranderen. Een praktische redactionele ladder loopt van antwoorden of samenvatten, over aanbevelen en een voorstel maken, naar een concept opstellen, een afgebakende omkeerbare wijziging uitvoeren en uiteindelijk een ingrijpende externe actie veroorzaken. Daarnaast bestaat een verboden niveau voor beslissingen die deze service nooit mag nemen. De ladder is geen universele risicoclassificatie: de organisatie moet gevolgen, bevoegde beoordelaars en technische waarborgen per service bepalen.

• Antwoord of samenvatting: alleen lezen binnen de informatie-envelop en duidelijk stoppen wanneer bewijs ontbreekt.
• Aanbeveling of voorstel: toon basis en onzekerheid, maar voer de voorgestelde stap niet uit.
• Concept: schrijf uitsluitend naar een niet-definitieve werkruimte met een aangewezen beoordelaar.
• Omkeerbare wijziging: beperk objecten en velden en voorzie validatie, bescherming tegen duplicaten en herstel.
• Ingrijpende externe actie: toon een controleerbaar voorbeeld en valideer machtiging en actiegebonden goedkeuring vóór uitvoering.
• Verboden beslissing: laat de capaciteit technisch ontbreken en verwijs naar een gekwalificeerde mens of afzonderlijk bestuurd proces.

Houd een antwoordconcept dus los van verzenden, een herstelbare dossierwijziging van verwijderen en een voorstel van een verantwoordelijke beslissing. Voor een ingrijpende actie bindt u de goedkeuring aan de actor, tool, doelresource, genormaliseerde parameters, het tijdstip en de vervaldatum. Een gewijzigde ontvanger of inhoud vereist nieuwe validatie. Goedkeuring herstelt nooit een ontbrekend recht, verruimt geen permanente toestemming en maakt een verboden beslissing niet toegestaan. Betalingen, toegangsverlening, destructieve handelingen, productiewijzigingen, professionele oordelen met grote gevolgen en materiële externe verbintenissen blijven onder passende gekwalificeerde menselijke en deterministische beleidscontrole.

Wat gebeurt er wanneer de assistent een grens bereikt?

Ontwerp weigering, veilige gedeeltelijke hulp, menselijke overdracht en beveiligingsescalatie als volwaardige service-uitkomsten met echte stopvoorwaarden. Gebruik herkenbare redenen: taak buiten scope, informatie niet toegelaten, onvoldoende machtiging, goedkeuring nodig, bewijs ontbreekt of is verouderd, specialistisch oordeel vereist, afhankelijkheid onbeschikbaar, operationele limiet bereikt of beveiligingssignaal gedetecteerd. Formuleer de grens helder zonder gevoelige beleidsdetails prijs te geven. De assistent mag nooit beweren dat een broncontrole, tooloproep, goedkeuring of wijziging gelukt is wanneer dat niet zo is.

• Bied alleen het veilige deel aan, bijvoorbeeld een concept, checklist of verzoek om ontbrekende informatie.
• Geef bij overdracht doel, relevante niet-gevoelige context, gebruikte capaciteit, reden, beschikbaar of ontbrekend bewijs, volgende stap en traceeridentificator mee.
• Houd gebruikershulp, zakelijke goedkeuring en een beveiligingsincident als afzonderlijke routes met eigen verantwoordelijken en urgentie.
• Stop de uitvoering zolang de bevoegde eigenaar handelt en valideer opnieuw wanneer de voorgestelde actie intussen verandert.

Niet elke grens vraagt dezelfde bestemming. Een ontbrekend beleidsantwoord gaat naar de inhoudelijke eigenaar, een zakelijke verbintenis naar de verantwoordelijke beslisser en een vermoeden van gegevensexfiltratie of bevoegdheidsverhoging naar het incidentpad. OWASP noemt ook geheugenvergiftiging, recursief toolmisbruik en omzeiling van goedkeuring als relevante misbruikscenario’s. Het incidentplan moet daarom verantwoordelijken, escalatie- en herstelscenario’s en bruikbare auditgegevens bevatten. Een vriendelijke overdrachtszin zonder bestemmeling, bevoegdheid of stopstatus is geen operationele escalatie.

Hoe worden de grenzen een werkbaar ontwerp?

Vul één rij van een capaciteitscanvas in per zichtbare bewerking en verbind elke rij met technische controles, bewijs, tests, meetpunten en een eigenaar. Leg de bevoegde actor en authenticatie, informatie-envelop, sessie- en geheugenregels, smalle toolbewerking, uitvoerende identiteit, resourcescope, actieplafond, goedkeuring, operationele grenzen, weigering, logrecord, evaluaties en escalatie vast. Vermijd een rij als “de assistent heeft toegang tot het CRM”; beschrijf bijvoorbeeld “een toegelaten supportdossier samenvatten”. Dit canvas is praktische redactionele synthese op basis van NIST- en OWASP-principes, geen document dat op zichzelf een controle uitvoert.

De drie rijen mogen één gespreksscherm delen, maar niet automatisch dezelfde data, tools of rechten. Kies per rij een meetpunt dat het beoogde gedrag én de grens zichtbaar maakt: toegelaten zoekresultaten en geweigerde dossieroverschrijdingen, markeringen van niet-onderbouwde conceptclaims en hun beoordelingsuitkomst, of geslaagde verzendingen en afwijzingen wegens gewijzigde parameters. De eigenaar moet afwijkingen kunnen onderzoeken en de capaciteit kunnen pauzeren, aanpassen of stopzetten. Zonder die koppeling blijft het canvas documentatie die na de workshop veroudert.

Welk bewijs is nodig voor vrijgave en verder gebruik?

Geef de assistent pas vrij wanneer bewijs aantoont dat toegelaten dienstverlening én verwachte weigeringen werken in omstandigheden die op de inzet lijken. Test gewone taken naast toegang tot andere accounts, niet-toegelaten tools, verouderde bronnen, vergiftigde opgehaalde inhoud, verboden gegevens, omzeilde goedkeuring, gewijzigde parameters, dubbele herhalingen, uitgevallen afhankelijkheden, pogingen tot gegevensexfiltratie en ontsporende toolketens. Communiceer bekende beperkingen en faalwijzen aan gebruikers en beheerders. Een geslaagde testset is bewijs voor een bepaalde versie en omgeving, geen blijvende verzekering tegen nieuwe combinaties of wijzigingen.

• Maak reconstrueerbaar wie wat vroeg, welke capaciteit en beleidsversie golden, welke bron- en toolklassen zijn gebruikt en welke autorisatie- en goedkeuringsbeslissingen volgden.
• Bewaar actie, uitkomst, relevante versies en een traceeridentificator, maar geen geheimen of onbeperkte gevoelige conversatiecontext.
• Volg onverwacht toolgebruik, herhaalde weigeringen, autorisatiefouten, gewijzigde goedkeuringen, afwijkende actiereeksen, drift, vertraging, resourcegebruik en storingen per capaciteit.
• Wijs afzonderlijke eigenaars aan voor servicegedrag, toegangsrechten, zakelijke overdrachten en beveiligingsincidenten.

Heropen de getroffen tests en het vrijgavebewijs na materiële wijzigingen aan modellen, prompts, retrieval, geheugen, tools, rechten, beleid, data, leveranciers of gebruiksomgeving. Pas de diepgang van de herbeoordeling aan de geraakte capaciteiten en hun risico’s aan, maar behandel een promptwijziging nooit als louter tekstredactie wanneer ze gedrag kan veranderen. Start met de kleinste nuttige capaciteit en breid bevoegdheid uit via beoordeelde wijzigingen. Betrek beveiliging, identiteit, privacy, archivering, risico- en service-eigenaars bij gevoelige informatie, persistent geheugen, bevoorrechte toegang, destructieve wijzigingen, externe verbintenissen en incidentrespons; routeer gereglementeerde of andere professionele oordelen met grote gevolgen naar bevoegde specialisten en een afzonderlijk bestuurd proces.