RBAC vs ABAC: Het juiste toegangsbeheermodel kiezen voor AI Agents

Wat RBAC daadwerkelijk is

Role-based access control (RBAC) voegt een gestructureerde tussenlaag toe tussen gebruikers en permissies. Je geeft Priya niet rechtstreeks de mogelijkheid om een geheime groep te lezen. In plaats daarvan definieer je een rol, zoals Secret Group Viewer, die deze permissie bevat, en wijs je Priya toe aan die rol.

Het RBAC-model bestaat uit drie kerncomponenten:

De meerwaarde zit in de indirectie. Wanneer het beveiligingsteam besluit dat kijkers geen geheime waarden meer mogen inzien, bewerken ze één rol en verandert de toegang voor elke viewer tegelijk. NIST heeft dit model tientallen jaren geleden gestandaardiseerd, wat verklaart waarom elke cloudconsole een rollenpagina heeft.

De kwetsbaarheid ligt echter ook in deze indirectie. Rollen zijn statische verzamelingen. Als een permissie alleen mag gelden vanaf een zakelijk IP-adres, of alleen voor records in de regio van de aanvrager, kan traditionele RBAC dit niet uitdrukken. Teams lossen dit op door steeds meer rollen aan te maken: analyst-eu, analyst-eu-readonly, analyst-eu-readonly-prod. Dit leidt tot role explosion, de meest genoemde reden waarom organisaties naar ABAC kijken.

Wat ABAC daadwerkelijk is

Attribute based access control verwijdert het benoemde pakket van permissies. In plaats van te controleren welke rol een subject heeft, evalueert het tijdens het verzoek een policy-expressie op basis van vier categorieën attributen:

Een policy ziet er bijvoorbeeld zo uit: sta lezen toe wanneer subject.department == resource.owning_team en resource.classification != "restricted" en env.network == "corp". NIST SP 800-162 vormt de officiële specificatie; in de praktijk wordt ABAC geïmplementeerd via een policytaal zoals XACML, Rego of Cedar achter een autorisatiedienst.

ABAC biedt aanzienlijk meer expressiviteit. Eén goed geformuleerde regel kan honderden rollen vervangen en relaties ondersteunen die RBAC niet kan uitdrukken, zoals: "de arts die aan deze patiënt is toegewezen."

Deze flexibiliteit brengt echter een prijs met zich mee. Policies zijn code: ze vereisen beoordeling, tests, versiebeheer en inzicht in de onderlinge wisselwerking tussen regels. Bovendien heeft de eerste vraag die een auditor stelt — wie heeft toegang tot deze data? — geen direct opvraagbaar antwoord meer. Je moet elk subject doorlopen en de policy voor ieder subject afzonderlijk evalueren. Sommige engines bieden hiervoor reverse-query-functionaliteit; in de praktijk wordt dit echter zelden toegepast.

Verschillen tussen RBAC en ABAC in één oogopslag

Wat deze tabel niet direct laat zien: ABAC vereist een belangrijke randvoorwaarde, namelijk betrouwbare attributen. Een policy die gebaseerd is op resource.data_region is zo betrouwbaar als de discipline waarmee tags worden toegekend. De meeste organisaties die met ABAC starten, ontdekken dat ze een probleem hebben met ongetagde data voordat ze een autorisatieprobleem hebben. Bovendien sluiten de twee modellen elkaar niet uit — in productieomgevingen wordt RBAC vaak als basis gebruikt, aangevuld met specifieke attribuutvoorwaarden.

Veelgemaakte fouten bij de keuze

Role explosion zien als een reden om van model te veranderen. Role explosion is meestal een probleem met scoping, niet een tekortkoming van het model. Als je analyst-team-a, analyst-team-b en analyst-team-c hebt aangemaakt, heb je geen attributen nodig — maar één analyst-rol die afzonderlijk wordt gekoppeld aan de resources van elk team. Veel van de problemen die aan RBAC worden toegeschreven, ontstaan doordat toegang op tenant-niveau wordt verleend waar een koppeling aan een specifieke resource hoorde te staan.

Kiezen voor expressiviteit die niet geauditeerd kan worden. ABAC maakt het mogelijk regels te schrijven die een compliance-team niet kan controleren. Die afweging kan soms verdedigbaar zijn, maar mag nooit per ongeluk gemaakt worden. Vraag jezelf vooraf af wie de periodieke toegangscontrole gaat uitvoeren en op welke wijze.

Vergeten dat toewijzingen combineren. Een subject kan zowel rechtstreeks toegang hebben als deze overerven via een team; het verwijderen van de ene toewijzing heft de andere niet op. Dit wordt complexer als er een policy engine bovenop wordt geplaatst, omdat twee systemen dan onafhankelijk van elkaar toegang kunnen verlenen.

Permissies instellen voor de mens, maar de agent negeren. Alle beveiligingsmaatregelen aan de menselijke kant zijn in feite cosmetisch als de door hen gebouwde agent draait op een gedeeld servicetoken met toegang tot de gehele tenant.

Wilt u gescopte toegang in de praktijk zien?

Start TrueFoundry en wijs een rol toe op één specifieke resource in plaats van de hele tenant — het kost ongeveer twee minuten.

Gratis aan de slag

Waarom AI agents een casus voor ABAC lijken

Een AI agent is een niet-menselijk subject waarvan de effectieve bevoegdheid niet vaststaat. Het kan in de ene stap een openbare repository uitlezen en in de volgende stap een klantrecord bewerken. Het handelt op verschillende momenten voor verschillende gebruikers. De invoer kan kwaadwillig beïnvloed zijn — een gecompromitteerde issue-inhoud kan de agent sturen naar een tool die niet aangeroepen had mogen worden. En in tegenstelling tot een mens, twijfelt een agent niet of een actie verstandig is.

Vertaal dat naar een vereiste en het leest als een opzet voor ABAC: sta deze tool-aanroep toe wanneer de actieve gebruiker toegang heeft tot het doel, de tool niet-destructief is en het verzoek niet afkomstig is uit niet-vertrouwde inhoud. Drie attributen, één regel. Waarom wordt dit in de praktijk dan zelden zo ingericht?

Omdat de attributen op het beslissingsmoment niet betrouwbaar beschikbaar zijn. De vraag "is dit verzoek afkomstig uit niet-vertrouwde inhoud" is geen eenvoudig veld, maar een complex vraagstuk. Of de actieve gebruiker toegang heeft tot het doelsysteem is vast te stellen — maar de meest efficiënte en correcte manier om dat te verifiëren, is door het doelsysteem aan te roepen met de authenticatiegegevens van die gebruiker zelf, in plaats van het permissiemodel na te bouwen in een policy engine met het risico op verouderde gegevens.

Daarnaast weegt het auditbaarheidsvraagstuk het zwaarst bij AI agents. Beveiligingsaudits richten zich primair op agent-permissies. Het antwoord "de policy geeft onder deze specifieke voorwaarden toestemming" levert minder zekerheid dan een tabel die aantoont dat deze agent de rol MCP Server User heeft op drie specifieke servers.

Agents vereisen dus beperktere toegang dan mensen en een transparantere structuur. ABAC biedt weliswaar de gewenste beperking, maar vermindert de controleerbaarheid. Daarom zien we in de praktijk vooral het volgende patroon: RBAC met strikte scoping op resourceniveau, gecombineerd met gerichte contextuele controles waar de runtime-situatie dat vereist.

Hoe dit werkt in TrueFoundry

TrueFoundry maakt gebruik van RBAC met resource-scoped role bindings. Het is bewust geen ABAC policy engine. Het model beantwoordt één duidelijke vraag: wie kan wat doen, en waar?

• Een subject is de identiteit die toegang krijgt: een gebruiker, team, virtual account of agent.
• Een resource is het object dat wordt benaderd: een model provider account, MCP server, agent, cluster, workspace, repository of secret group.
• Een rol is een benoemde verzameling toegestane acties.

Het toewijzen van een rol aan een subject voor een specifieke resource maakt een role binding aan. Toegang wordt los van de configuratie van de resource beheerd, waardoor permissies aangepast kunnen worden zonder hernieuwde deployment.

Toewijzingen worden rechtstreeks vanuit de resource beheerd — open het menu met de drie puntjes en selecteer Access Control:

Kies vervolgens een of meer subjecten en een rol. Het venster toont de acties die bij elke rol horen, zodat duidelijk is welke rechten worden verleend:

De beschikbare rollen variëren per resourcetype: Manager en User voor een model provider account; MCP Server Manager, MCP Server User en MCP Server Approver voor een MCP server; Agent Manager en Agent Access voor een agent. Clusters, workspaces en secret groups kennen elk hun eigen niveaus voor beheerders, leden en kijkers.

Drie scopes

Rollen werken op drie verschillende niveaus:

Admin en Read-Only Member kunnen niet worden bewerkt. Member kan dat wel — dit is de basisrol die elke gebruiker krijgt, die standaard alleen cluster:ReadCluster, environment:ListEnvironments, settings:ListSettings, user:ListUsers, repository:CreateRepository, secret-group:CreateSecretGroup en agent:CreateAgent bevat. Deze rol geeft geen toegang tot individuele modellen, MCP-servers of workspaces; die toegang wordt verkregen via resource-bindings of teamlidmaatschappen.

Teamrollen komen binnen deze structuur het dichtst in de buurt van een attribuutvoorwaarde. Team Member bevat virtual-account:ReadVirtualAccount, maar de scope is beperkt tot Virtual Accounts die eigendom zijn van teams waar de gebruiker daadwerkelijk lid van is. De permissie is voor iedereen gelijk; de verzameling toegankelijke objecten verschilt per persoon.

Dit is scoping op basis van eigenaarschap, niet op basis van ABAC: er is geen policy-expressie of attribuutevaluatie, maar een vaste relatie tussen een team en diens resources. Dit dekt de situaties af waarin anders vaak naar attributen wordt gegrepen, terwijl het model overzichtelijk blijft.

Aangepaste rollen voor fijnmazige permissies

Wanneer de ingebouwde tenant-rollen niet aansluiten bij de behoeften, kunt u aangepaste rollen samenstellen uit de permissiecatalogus. Elke permissie volgt de structuur resource:Action, gegroepeerd per resourcetype:

Een belangrijk uitgangspunt hierbij is: permissies in aangepaste rollen gelden voor alle resources van het geselecteerde type. Een aangepaste rol met mcp-server:ReadMcpServer geeft toegang tot elke MCP server binnen de tenant, niet tot een specifieke selectie. Gebruik voor een enkele resource de pagina Access Control van die specifieke resource. Wanneer dit verschil niet goed wordt toegepast, kan een rol die bedoeld was voor één server onbedoeld leestoegang geven tot de gehele tenant.

Contextuele toegangscontroles

TrueFoundry voegt op vier specifieke punten contextbewustzijn toe. Geen van deze punten maakt gebruik van attribuut-policies, en elk onderdeel is direct te controleren:

De tweede optie vervult in de praktijk de functie die men vaak van ABAC verwacht. Wanneer een agent via OAuth per gebruiker een tool aanroept voor een specifieke gebruiker, evalueert de externe dienst de werkelijke rechten van die gebruiker. Zo hoeven de access control lists van GitHub niet in een aparte policy engine te worden nagebouwd; er wordt rechtstreeks gebruikgemaakt van de rechten in het bron-systeem. Het MCP access control-model bouwt hier rechtstreeks op voort.

Een belangrijke kanttekening: Virtual Account-tokens geven elk verzoek identieke toegang. Ze zijn geschikt voor communicatie tussen diensten onderling, maar niet voor situaties waarin gebruikersafhankelijke permissies vereist zijn.

Twee praktijkvoorbeelden

Twee scenario's uit de documentatie illustreren de toepassing van dit model.

Een auditor alleen-lezen toegang verlenen. Wijs Read-Only Member toe via Access > Users. Dit is een ingebouwde tenant-rol die leestoegang biedt voor ondersteunde resourcetypes en niet kan worden bewerkt. Dit borgt de integriteit van de auditrol. Om een groep auditoren toegang te geven, kan de rol aan een team worden toegewezen, zodat nieuwe leden de rechten automatisch overerven. Als de auditor slechts enkele specifieke resources mag inzien, kent u geen tenant-rol toe, maar verleent u de viewer- of access-rol op de betreffende resources afzonderlijk.

Gebruikers MCP-servers laten aanmaken zonder ze Admin te maken. De neiging bestaat vaak om de rol Admin toe te wijzen, omdat het aanmaken van een server een permissie vereist die Member mist. Maak in plaats daarvan een aangepaste rol aan met uitsluitend mcp-server:CreateMcpServer:

Wijs deze rol vervolgens toe via Access > Users of Access > Teams:

De werking is als volgt: met Create MCP Server kan een gebruiker een nieuwe server aanmaken. Dit geeft geen automatische toegang tot al bestaande servers. Na het aanmaken van een server kent de maker zichzelf de rol MCP Server Manager toe via de Access Control-pagina van die specifieke server.

De bevoegdheid om resources aan te maken en de bevoegdheid om ze te beheren blijven gescheiden. Een ABAC-policy zou hetzelfde kunnen bereiken, maar vereist een zorgvuldige controle van de regels. In dit model betreft het twee heldere vermeldingen in twee tabellen. Dit patroon is eveneens toepasbaar op kleinere permissies: om gebruikers toegang te geven tot gateway-instellingen zonder Admin-rechten, bewerkt u Member en voegt u gateway-controls:ListGatewayControls toe.

Klaar om uw eerste agent af te bakenen?

Maak een aangepaste rol aan, koppel deze aan één MCP server en zie precies waar uw agent toegang toe heeft.

Start gratis op TrueFoundry

Aandachtspunten in de praktijk

Toewijzingen combineren; het verwijderen van de ene heft de andere niet op. Een subject kan toegang krijgen via een rechtstreekse toewijzing én via een teamlidmaatschap. Indien gecontroleerd moet worden waarom een gebruiker toegang heeft tot een resource, dienen zowel de directe bindings als de overgeërfde rechten via teams gecontroleerd te worden.

Het bewerken van een standaard teamrol geldt voor alle teams. Team Member en Team Manager worden bewerkt onder Access > Default Roles; aanpassingen hierin werken wereldwijd door. Het toevoegen van virtual-account:ManageVirtualAccount om één team tokens te laten ophalen, verleent die mogelijkheid aan leden van elk team. Ieder individu blijft weliswaar beperkt tot de eigen teams, maar de functionaliteit wordt breed beschikbaar.

Tenant-rollen combineren met team tenant-rollen. Een gebruiker heeft een direct toegewezen tenant-rol. Als deze gebruiker ook lid is van een team met een tenant-rol, is de effectieve permissie een combinatie van beide. De totale bevoegdheid van een gebruiker is daardoor niet altijd enkel uit het individuele gebruikersprofiel af te lezen. Teams kunnen handmatig worden aangemaakt, worden gesynchroniseerd vanuit uw IdP via SCIM, of worden toegepast met tfy apply op een team YAML-bestand, waarbij een IdP claim value direct kan worden gekoppeld aan een team.

Aanbevolen artikelen

• API Auth and RBAC in the AI Gateway — hoe deze rollen worden afgedwongen op gateway-verkeer
• MCP Access Control: Securing AI Agents with an MCP Gateway — permissies op tool- en serverniveau in de praktijk
• Enterprise MCP Access Control — het schalen van het model over meerdere servers en teams
• What Is an MCP Gateway: Architecture and Use Cases — de positie van het handhavingspunt in de architectuur
• Building an AI Governance Framework — het bredere beleidskader rondom toegangsbeheer

Conclusie

De discussie over RBAC versus ABAC hoeft niet complex te zijn. ABAC is de juiste keuze wanneer toegang daadwerkelijk afhangt van meetbare en betrouwbare runtime-context, en wanneer er capaciteit is om policy-code te onderhouden en te beheren. Voor de overige situaties volstaat RBAC met een correcte scoping op resourceniveau, met het voordeel van een direct controleerbare structuur.

AI agents stellen specifieke eisen aan toegangsbeheer — een striktere scoping dan voor menselijke gebruikers, authenticatie per gebruiker in plaats van gedeelde tokens en menselijke goedkeuring bij risicovolle acties. Hiervoor is geen volledige policy engine vereist; het vraagt om rollen die gekoppeld zijn aan individuele resources in plaats van de gehele tenant, aangevuld met gerichte controles tijdens de uitvoering.

Dat is wat TrueFoundry biedt. De keuze voor RBAC zorgt voor een heldere structuur: wanneer bij een audit wordt gevraagd welke toegang een agent heeft, levert dat een direct overzicht op in plaats van een complexe berekening.

Bepaal de scope van uw eerste agent op TrueFoundry

Gratis te starten