TBAC: Task-Based Access Control voor het agent-tijdperk

De meeste toegangsbeheermodellen in productie gaan nog steeds uit van een stabiele principal: wie vraagt het, welke attributen of relaties horen daarbij en waar geeft dat recht op? Rollen beantwoordden dat voor het organigram, attributen voor de context en relaties voor sociale grafieken. AI-agents veranderen de vraag zelf — de identiteit van een agent is stabiel, maar zijn werk niet: ingezet per taak, met voor elke taak een ander ingesteld permissieprofiel, werkend op machinesnelheid en instructies volgend die zijn ingebed in de data die hij leest. Het model dat het huidige moment vereist vraagt: welk werk voer je op dit moment uit? Die vraag heeft een naam met een lange geschiedenis — task-based access control, oftewel TBAC, in de jaren 90 voorgesteld door Thomas en Sandhu en nu in aangepaste vorm nieuw leven ingeblazen voor agentic AI. Dit artikel bekijkt de familie van toegangsniveaus op een eerlijke manier, legt uit waarom agents elk model onder druk zetten, introduceert TBAC en de moderne formuleringen ervan, en brengt het gelaagde resultaat in kaart op de gateway-constructs die het implementeren, waarbij de TrueFoundry-koppeling wordt gebaseerd op publieke documentatie.

Ines, een security architect, kreeg het beoordelingsverzoek dat elk securityteam dit jaar krijgt: keur een support-agent goed die tickets leest, de besteldatabase raadpleegt en terugbetalingen onder de vijftig euro uitvoert. Haar instinct was gebaseerd op twintig jaar ervaring: maak een rol aan. Maar de rol support-agent voelde tijdens de lunch al verkeerd aan. Een rol wordt eenmalig toegewezen en beschrijft een stabiele functie; deze agent had de permissie voor terugbetaling alleen nodig tijdens terugbetalingstaken, de database alleen voor de klant van het specifieke ticket, en niets daartussenin. Erger nog: hij zou alles wat ze hem toewees continu behouden, over elke parallelle instantie heen, op machinesnelheid — en als een kwaadwillend ticket hem zou vertellen iets creatiefs te doen met zijn permissies, zou hij dat zomaar kunnen opvolgen. Het rolmodel gaf haar twee slechte opties: te veel rechten toekennen en permanente blootstelling accepteren, of te weinig rechten toekennen waardoor de agent niet meer werkt. Ze wilde een derde optie: permissies samengesteld per taak, afgestemd op de objecten van de taak, actief voor de duur ervan en verdwenen zodra het klaar is. Die derde optie bestaat, op papier, al van voordat ze aan haar carrière begon.

1. Een korte geschiedenis van de BAC's

Elke generatie van toegangsbeheer bevat een aanname over de principal. Het vroegste onderscheid — discretionary control (DAC), waarbij eigenaren van bronnen toegang verlenen, versus mandatory control (MAC), waarbij een centrale autoriteit labels toekent en toegang vrijgeeft — ging uit van mensen met een bepaalde autorisatie. RBAC, in de jaren 90 geformaliseerd door Ferraiolo, Kuhn en Sandhu en later gestandaardiseerd, koppelde permissies aan rollen in plaats van aan individuen: een ontwikkelaarsrol krijgt toegang tot repositories, een artsenrol krijgt toegang tot patiëntendossiers. De dieperliggende aanname: principals hebben stabiele functies die veranderen op de tijdschaal van een organisatie — wat geldt voor werknemers, en waarom RBAC in de meeste bedrijven nog steeds leidend is.

ABAC — attribute-based access control, canoniek behandeld in NIST SP 800-162 — verving het zoeken op rollen door beleidsevaluatie over attributen van het subject, de bron, de actie en de omgeving: toestaan als afdeling = finance en classificatie ≤ intern en tijdens kantooruren. Het biedt flexibiliteit ten koste van de complexiteit van het opstellen van beleid, en zoals analyses van agent-beveiliging opmerken: het evalueert context goed, maar begrijpt niet inherent de intentie achter een verzoek. ReBAC — relationship-based access control, populair gemaakt door Google's Zanzibar-paper — leidt permissies af uit relaties in een grafiek: je kunt dit document bewerken omdat je eigenaar bent van de bovenliggende map. Daarnaast bestaan PBAC als overkoepelende term voor beleidssystemen en just-in-time toegang vanuit bevoorrecht toegangsbeheer — een voorproefje, uit de menselijke wereld, van tijdsgebonden permissies. Elk van deze modellen beantwoordt de vraag "wie ben je, en waar geeft dat je recht op?" — ingesteld voordat het werk begint. Dat is precies de aanname die agents schenden.

2. Waarom agents identiteitsgericht toegangsbeheer doorbreken

De druk is structureel en de literatuur over agent-beveiliging is tot een eenduidige diagnose gekomen. Ten eerste: agents hebben geen stabiele functie. Ze worden ingezet voor specifieke taken, werken binnen wisselende databereiken, voeren taken uit op machinesnelheid en draaien in parallelle instanties — een rol als "klinische documentatie-agent" die toegang geeft tot een PHI-repository kan niet uitdrukken dat deze instantie geautoriseerd is voor deze drie dossiers voor dit specifieke consult, zoals een ABAC-versus-RBAC-analyse het formuleert. Ten tweede: agents kunnen daadwerkelijk gebruiken wat ze bezitten, programmatisch en op grote schaal. De benadering van Oso is hierin het scherpst: werknemers negeren het overgrote deel van hun permissies; agents doen dat niet. Te ruime toewijzing van rechten, wat bij mensen alleen slordig is, wordt een actief aanvalsoppervlak bij een principal die zijn permissieruimte op machinesnelheid kan verkennen. Ten derde: agents kunnen worden beïnvloed via taal. Prompt-injectie betekent dat instructies binnenkomen via de data die een agent leest, waardoor een permanente permissie een permanent doelwit is — het confused-deputy-probleem via een taalinterface.

Ten vierde, en het minst onderkend: delegatieketens maken verantwoording onduidelijk. 'On-behalf-of'-stromen verhogen ongemerkt de rechten — de agent erft de volledige sessieomvang van de gebruiker, inclusief permissies die irrelevant zijn voor de taak — en overdrachten tussen meerdere agents dragen autoriteit over zonder herbeoordeling. Richtlijnen uit de praktijk wijzen steeds meer op het binden van de verzoekcontext: elke vervolg-call bevat de oorspronkelijke gebruiker, de taak en het autorisatiebesluit, omdat de privilegegrens moet verschuiven van het moment van inloggen naar het moment van het verzoek. De prijs van dit niet doen is terug te zien in de literatuur over datalekken: sectorrapporten die verwijzen naar IBM's 2025 Cost of a Data Breach-onderzoek tonen aan dat het overgrote deel van de organisaties met AI-gerelateerde beveiligingsincidenten niet beschikte over het juiste AI-toegangsbeheer, en SpyCloud's rapportage over identiteitsblootstelling uit 2026 wijst op grootschalige lekken van API-sleutels en tokens, waaronder inloggegevens die gekoppeld zijn aan AI-tools. De modellen die voor mensen zijn gebouwd, houden volgens deze rapporten geen stand voor agents.

3. De komst van TBAC: een oud idee waarvan de principal eindelijk is gearriveerd

Task-based access control is niet nieuw — wat het hernieuwde succes ervan geloofwaardig maakt. In de jaren 90 stelden Roger Thomas en Ravi Sandhu task-based authorization controls voor als een verschuiving van subjectgerichte naar activiteitgerichte autorisatie: permissies gebundeld in taken, toegekend als de minimale set die een specifieke activiteit vereist, actief voor de duur ervan, en opgebruikt of ingetrokken naarmate de workflow vordert. Het idee was zijn infrastructuur vooruit — de workflowsystemen uit de jaren 90 hadden het niet dringend genoeg nodig. Agents wel. Een recent arXiv-paper over risico-adaptief toegangsbeheer voor agentic systemen bouwt voort op TBAC "vanwege de natuurlijke afstemming met het doelgerichte karakter van AI-agents" — een agent is, anders dan een werknemer, echt gelijk aan zijn huidige taak.

De moderne formuleringen breiden het origineel in twee richtingen uit. De benadering van Cisco Outshift — tool-, transactie- en task-based access control — positioneert TBAC expliciet als de laag voorbij RBAC, ABAC en ReBAC voor agentic AI: autorisatie die niet is afgestemd op wie de agent is, maar op de tools die hij mag aanroepen, de transacties die hij mag voltooien en de taak die hij uitvoert. De grens van het onderzoek verkent hoe de "taak" überhaupt wordt beoordeeld: het werk op arXiv gebruikt een LLM als een onzekerheidsbewuste beoordelaar van de vraag of een actie de geautoriseerde taak dient — veelbelovend, pril en eerlijk over de openstaande vragen. Tussen de consensus in de praktijk en het onderzoek ontstaat een werkdefinitie. TBAC in het agent-tijdperk betekent: een permissiebundel per taak (minimale tools en data voor dit doel), tijdsbinding (kortstondige, taak-specifieke inloggegevens met TTL's in minuten), vastlegging van delegatie (de taak bevat wie deze heeft geautoriseerd en namens wie), en transactie-controlepunten (onomkeerbare stappen krijgen een expliciete goedkeuringsstap). Niets daarvan vervangt de oudere modellen — het bevindt zich erbovenop, wat het ontwerpinzicht is dat in de volgende secties concreet wordt gemaakt.

4. Het gelaagde model: waar elke BAC zijn plaats behoudt

De vakliteratuur is unaniem over één punt: het volledig vervangen van RBAC is noch noodzakelijk, noch raadzaam. De modellen vullen elkaar aan, en in een LLM/RAG/MCP-stack heeft elk zijn eigen plaats. RBAC blijft de buitenste grens — welke teams en services in de eerste plaats toegang hebben tot welke modellen, MCP servers en agents; grofmazig, auditeerbaar, gevormd naar het organigram, precies wat een buitenste grens moet zijn. ABAC-achtige policies worden tijdens request-tijd uitgevoerd — team, omgeving, dataclassificatie en kosten-metadata bepalen of deze aanroep, in deze context, wordt voortgezet; in RAG is dit waar document-level permissies zich bevinden, zodat retrieval de rechten van de opvragende gebruiker respecteert in plaats van die van de pipeline. ReBAC beheert de structuur van de data zelf — eigenaarschap en overerving — wat het meest van belang is waar agents content-graphs zoals drives en wiki's doorkruisen. TBAC bindt het werk: de tool-bundel per taak, het taakgebonden credential, het delegatie-record, het controlepunt bij onomkeerbare acties.

Als een stack gelezen, beantwoorden de modellen vier vragen over één agent-verzoek: mag deze principal hier überhaupt komen (RBAC), is dit verzoek acceptabel in deze context (ABAC), staat de datastructuur het toe (ReBAC), dient deze actie de geautoriseerde taak binnen de gestelde grenzen (TBAC). Handhaaf alle vier op één controlepunt, met één audit-record dat ze samenbindt, en u hebt wat het agent-tijdperk vereist. Dat punt is de gateway — en hier stopt het argument conceptueel te zijn, omdat deze constructies bestaan als gedocumenteerde, geleverde functionaliteiten.

5. De Mapping: Eisen van TBAC als Gedocumenteerde Gateway-constructies

Neem de vier TBAC-eisen uit Sectie 3 naast de officiële documentatie van TrueFoundry. De permissiebundel per taak mapt op de Virtual MCP Server: volgens de authenticatie- en beveiligingsdocs kunt u "ook een Virtual MCP Server maken, waarmee u een subset van tools uit verschillende MCP servers kunt blootstellen" — precies een gecureerde, minimale tool-bundel samengesteld voor een bepaald type werk in plaats van het volledige recht van een identiteit. De identiteitsgrens mapt op de gedocumenteerde gelaagdheid: "elke gebruiker/applicatie heeft een token nodig om met de gateway te praten — zodat de gateway de gebruiker kan identificeren en vervolgens autorisatieregels kan opleggen," waarbij toegangsbeheer op gateway-niveau bepaalt "welke gebruikers toegang hebben tot welke MCP servers" (dezelfde docs). Inkomende identiteit, autorisatiebesluit en uitgaand credential zijn onafhankelijke vlakken — het credential dat de gateway bereikt is nooit het credential dat de downstream tool bereikt.

Tijdsduurbinding en delegatie mappen op het credential-model. De Agent Harness-documentatie vermeldt dat er nooit API keys of credentials in agent-definities worden geplakt — agents verwijzen op naam naar MCP servers terwijl "de gateway credential-injectie, token-verversing en gebruikersdelegatie afhandelt," en met per-gebruiker OAuth "zal elke gebruiker zijn eigen token hebben" en verleent de server alleen waar die gebruiker toegang toe heeft (docs). Delegatie structureel vastgelegd: de agent handelt met het afgebakende token van de autoriserende gebruiker, niet met een god-mode service key. Transactionele controlepunten mappen op human-in-the-loop goedkeuringspoorten, die gevoelige tool-aanroepen pauzeren voor expliciete goedkeuring. En de grens per agent is gedocumenteerd bij de Agent Gateway: token- of kostengebaseerde quota "per agent, workflow of omgeving," RBAC over wie agents mag deployen, uitvoeren of wijzigen, en — het audit-anker van TBAC — alle agent-acties, zowel model-aanroepen als tool-invocaties, gelogd en auditeerbaar.

De gelaagde BACs als gateway-configuratie — één agent, vier vragen (illustratief)

6. Compliance: Waarom de Gelaagdheid Auditeerbaar Is, Niet Alleen Veilig

Toegangsbeheer bewijst zijn nut dubbel — incidenten voorkomen en governance aantonen — en dat tweede is waar gereguleerde ondernemingen leven. Het gelaagde model heeft een compliance-verhaal omdat elke laag een record achterlaat op één controlepunt: elk verzoek gelogd met gebruikstoeschrijving op token-niveau, alle door agents geïnitieerde tool-acties geauditeerd, en RBAC-wijzigingen centraal toegepast over alle clients zonder hernieuwde deployment. TrueFoundry's gepubliceerde compliance-status ondersteunt de infrastructuur zelf: SOC 2 Type 2 en HIPAA-compliance, met deployment als SaaS, self-hosted, on-prem of air-gapped, zodat het handhavingspunt zich binnen de grens van de klant bevindt wanneer regelgeving dat vereist — volgens de AI Gateway productdocumentatie werken dataverwerkingsregels zoals PII-maskering overal waar de gateway draait, en "verlaat geen enkele data uw domein."

Dit is specifiek van belang voor TBAC omdat de moeilijkste auditvraag van het model — waarom heeft de agent deze aanroep gedaan, en viel dit binnen zijn geautoriseerde taak? — alleen te beantwoorden is als taakcontext, identiteit, policy-besluit en actie in één trace belanden. De vakliteratuur noemt dit de causaal-ketengat: teams loggen de API-aanroep maar verliezen het autorisatieverhaal eromheen. Een gateway die de aanroeper authenticeert, RBAC controleert, metadata-policy toepast, het afgebakende credential injecteert en het audit-record in één enkele stap wegschrijft, dicht dit gat. Het is waard om duidelijk in plaats van in overtreffende trap te zeggen: dit is het gelaagde, agent-bewuste toegangsmodel dat het huidige tijdperk vereist, geïmplementeerd op enterprise-niveau. Of het "het meest moderne" is, is een marketingvraag; dat het gedocumenteerd, geleverd en auditeerbaar is, is een verifieerbaar feit.

7. Eerlijke Beperkingen: Wat TBAC (Nog) Niet Is

Drie grenzen houden dit geloofwaardig. Ten eerste, geen enkel platform levert TBAC als een kant-en-klaar vinkje, inclusief TrueFoundry — wat bestaat zijn de afdwingbare primitieven die het model vereist: afgebakende bundels, identiteit per agent, gedelegeerde credentials, goedkeuringen, audit. Het samenvoegen hiervan tot autorisatie per taak is ontwerpwerk dat het platform mogelijk maakt, geen schakelaar. Ten tweede, taak-inferentie is echt moeilijk. De zuiverste vorm van TBAC gaat ervan uit dat het systeem weet welke taak wordt uitgevoerd; agents vervagen dat, en de LLM-as-judge grens is veelbelovend maar nog pril, met open problemen die de auteurs zelf erkennen rond onzekerheid en manipulatie — een judge die via prompt-injection kan worden misleid is een bewaker waar overheen gepraat kan worden. Ten derde, de oudere modellen zijn drager van het systeem: RBAC blijft de buitenste grens en ABAC dient als runtime-context; rollen schrappen om taakgebaseerde zuiverheid na te jagen ruilt een auditeerbare grofmazige controle in voor een onbewezen fijnmazige. TBAC is de nieuwste laag van een stack, geen opvolgende ideologie.

8. Waar Dit Eindigt: Ines' Derde Optie

De review van Ines sloot af met de derde optie die ze wilde, gebouwd uit gedocumenteerde onderdelen. De support agent kreeg een eigen identiteit — een virtueel account, geen geleende menselijke sessie — met RBAC dat precies één ding verleent: een Virtual MCP Server die lookup en refund blootstelt, twee tools gecureerd uit een server met twintig tools. De aanroepen draaien op OAuth-delegatie per gebruiker, dus het raakt alleen waar de klantcontext van het ticket recht op geeft; de uitgaven zijn begrensd door quota; en de ene onomkeerbare actie, de terugbetaling, pauzeert boven een bepaalde drempel voor menselijke goedkeuring. Elke invocatie belandt in een auditlog die identiteit, policy-besluit en actie samenbindt — de causale keten die haar incident-response-proces nodig heeft. Geen permanente god-mode rol, geen kapotte agent: permissies verzamelen zich rond het werk, begrensd in omvang, tijdsduur en blast radius. Het idee uit de jaren 90, draaiend op infrastructuur uit 2026.

Dat is de eerlijke lijn van TBAC. "Wie ben je?" diende toegangsbeheer veertig jaar lang omdat principals mensen waren. Agents maakten "wat ben je nu aan het doen?" de bindende vraag, en het antwoord is geen nieuw acroniem dat de oude vervangt — het zijn de oude modellen correct gelaagd, met taakgebonden constructies bovenop, gehandhaafd op het ene punt waar elke model- en tool-aanroep toch al langs komt. De gateway is gebouwd om dat punt te zijn. Het agent-tijdperk is wat de jaren 90 eindelijk gelijk heeft gegeven.

9. Veelgestelde Vragen

Is TBAC een standaard zoals RBAC? Nee. RBAC kent een formele standaardisatie; TBAC is een onderzoekstraditie — het werk van Thomas en Sandhu uit de jaren 90 — die nu opnieuw tot leven is gewekt in agent-security onderzoek en vakliteratuur (de formulering van Cisco Outshift, het door LLM beoordeelde TBAC-model op arXiv). Beschouw het als een ontwerppatroon met een sterke stamboom, niet als een certificeerbare specificatie. De waarde ervan ligt in de vraag die het afdwingt: dient deze actie de geautoriseerde taak, binnen de gestelde grenzen?

Moeten we RBAC vervangen door TBAC voor onze agents? Nee — en geen enkele serieuze bron raadt dit aan. RBAC blijft de auditeerbare buitenste grens; attribute policies behandelen de runtime-context; op TBAC geïnspireerde constructies binden het werk. De praktische stap is additief: agent-identiteiten, tool-bundels per taak, gedelegeerde credentials per gebruiker, poorten op het onomkeerbare, audit op één punt.

Hoe is dit van toepassing op RAG, en niet alleen op tools? Retrieval is ook toegangsbeheer: documenten dragen rechten met zich mee, en de permissies van de opvragende gebruiker — niet de service account van de pipeline — moeten bepalen wat retrieval teruggeeft. Dat is ABAC/ReBAC-terrein op de datalaag, aangevuld bij de gateway door delegatie per gebruiker (de queries van een agent dragen de afgebakende identiteit van de gebruiker downstream) en guardrails zoals PII-maskering in het respons-pad.

Wat is de hefboomwerking van de eerste stap? Geef elke agent een eigen identiteit zonder ingebouwde credentials. Quota, RBAC, delegatie en audit haken allemaal aan op identiteit — en het is de gedocumenteerde standaard op een beheerde runtime: volgens de Agent Harness docs van TrueFoundry verwijzen agents op naam naar modellen en tools terwijl credentials centraal in de gateways leven. Een agent die u niet individueel kunt identificeren, kunt u niet individueel beheren.

Kan een LLM beoordelen of een actie de taak dient? Dat is de actuele onderzoeksvraag. Het arXiv TBAC-werk maakt gebruik van een onzekerheidsbewuste LLM-judge en is open over niet-opgeloste problemen; de conservatieve productiehouding bestaat uit deterministische grenzen — bundels, quota, goedkeuringen, kortstondige scopes — met LLM-oordeelsvorming als een extra signaal, nooit als de enige poortwachter bij een onomkeerbare actie.

Referenties

• Thomas, R.K. en Sandhu, R.S. — task-based authorization controls (TBAC), het fundament uit de jaren 90: permissies gebundeld in taken, minimale rechten voor de duur van een activiteit. Geparafraseerd met bronvermelding. https://profsandhu.com/confrnc/ifip/i97tbac.pdf
• "Uncertainty-Aware, Risk-Adaptive Access Control for Agentic Systems using an LLM-Judged TBAC Model" (arXiv:2510.11414, 2025) — de moderne herleving in onderzoek, voortbouwend op TBAC vanwege de "natuurlijke afstemming met de doelgerichte aard van AI agents." https://arxiv.org/abs/2510.11414
• Cisco Outshift — "Tool, transaction, task-based access control (TBAC): Securing agentic AI beyond RBAC, ABAC, and ReBAC"; plus praktijkanalyses van Oso ("Why RBAC Is Not Enough for AI Agents"), Kiteworks (ABAC vs. RBAC for agents), en tianpan.co (task-scoped credentials, request-context binding) — allemaal geparafraseerd met bronvermelding.
• IBM Cost of a Data Breach-onderzoek (2025) en SpyCloud Identity Exposure Report (2026), zoals overgenomen in agent-security-rapportages uit de sector — de empirische kloof: AI-incidenten gecorreleerd met ontbrekende AI-access controls en grootschalige blootstelling van AI-tool credentials. Hier geciteerd via secundaire sectoranalyses; raadpleeg de primaire rapporten voor exacte cijfers.
• TrueFoundry MCP Gateway Authentication & Security docs — inbound auth, gateway-layer access control, Virtual MCP Servers, per-user OAuth; Agent Harness docs — geen credentials in agent-definities, credential injection, delegation, approvals.
• TrueFoundry Agent Gateway en AI Gateway — per-agent quota, agent-level RBAC, audit logging, metadata-filtered policies, guardrails, en deployment/compliance-postuur (SOC 2 Type 2, HIPAA; SaaS/self-hosted/on-prem/air-gapped).

Ines is een illustratieve compositie, geen specifiek persoon, organisatie of review. De geschiedenis van access-control en analyses uit het agent-tijdperk zijn geparafraseerd met bronvermelding naar de geciteerde standaarden, papers en vakliteratuur; geciteerde fragmenten zijn korter dan vijftien woorden en voorzien van bronvermelding. Statistieken van derden (IBM, SpyCloud) zijn gerapporteerde cijfers uit het geciteerde onderzoek zoals doorgegeven in industrie-analyses. TBAC is een ontwerppatroon en onderzoekslijn, geen gecertificeerde standaard, en geen enkel platform levert het als een enkele functie; TrueFoundry-functionaliteiten zijn geciteerd uit openbare documentatie en productpagina's op het moment van schrijven — verifieer dit met de huidige documentatie op truefoundry.com/docs. Het configuratiefragment is vereenvoudigd voor de leesbaarheid en is geen letterlijk productschema.

‍

‍