Toegangsbeheer voor AI Agents: Least-Privilege voor elke Agent

Wat is Toegangsbeheer voor AI Agents?

Toegangsbeheer voor AI-agents is de verzameling policies die bepaalt of een bepaalde caller een bepaalde resource mag bereiken. Het beantwoordt de vraag "is dit toegestaan", terwijl guardrails antwoorden op "wat zit erin".

Dat onderscheid is belangrijk om vast te houden, omdat de twee mechanismen op verschillende manieren falen en u ze allebei nodig heeft.

• Toegangsbeheer is de uitsmijter bij de deur. Het controleert of deze agent, gebruiker of dit team überhaupt geautoriseerd is om dit model of deze MCP-tool aan te roepen.
• Guardrails zijn de metaaldetector. Zodra een call is doorgelaten, inspecteren ze de prompt, de output en de tool-argumenten op injections, PII, secrets of onveilige bewerkingen.

Een agent kan volledig geautoriseerd zijn om uw database-MCP-server aan te roepen en alsnog verleid worden om een destructieve query te sturen. Toegangsbeheer zei ja tegen de server, en alleen een guardrail op de argumenten merkt op wat de query werkelijk doet. Als u de toegang echter te ruim afbakent, vertrouwt u volledig op de metaaldetector. Least privilege is wat het aantal toegestane calls in de eerste plaats klein houdt.

De twee niveaus van toegangsbeheer in TrueFoundry

TrueFoundry dwingt toegang af op twee niveaus, en het begrijpen van deze verdeling is het meeste werk.

Rollen op resourceniveau (collaborators)

U voegt een gebruiker, team of virtual account toe als collaborator rechtstreeks op een resource, en kiest een rol die hun toegang beperkt tot alleen die resource. De rollen zijn specifiek voor het resourcetype:

Dit is waar least privilege zich bevindt. Verleen een agent alleen Agent Access voor de MCP-servers die zijn taak nodig heeft, maak één team een User op het model-account dat het mag aanroepen, en voeg een MCP Server Approver toe wanneer een tool goedkeuring moet vereisen voordat deze wordt uitgevoerd. Er is voor niets van dit alles een aangepaste rolcreatie nodig.

Rollen op tenantniveau

Rollen op tenantniveau gelden voor de gehele tenant en worden geconfigureerd onder Access, en vervolgens Roles. Ze beheren tenant-brede acties zoals het aanmaken van resources, het beheren van gebruikers en het weergeven van elke resource van een bepaald type. TrueFoundry wordt geleverd met twee rollen: Admin, wat volledige controle geeft en beperkt moet blijven tot een klein aantal mensen, en Member, die standaard nergens toegang toe heeft en expliciet resourcetoegang moet krijgen toegewezen. Wanneer die twee te ruim of te beperkt zijn, maakt u een custom role aan.

Rollen kunnen zowel aan teams als aan individuele gebruikers worden gekoppeld, en de effectieve rechten van een gebruiker zijn de combinatie van hun eigen rol en elke rol die is geërfd van hun teams. Voor organisaties die identiteitsgroepen synchroniseren via SCIM, komen die groepen binnen als TrueFoundry-teams en kunnen ze rechtstreeks rollen toegewezen krijgen, zodat toegang dezelfde single source of truth volgt die uw IdP al beheert.

Hoe toegangsbeheer werkt voor MCP Tools

De MCP Gateway scheidt drie zaken die teams meestal door elkaar halen, en het gescheiden houden ervan is wat least privilege op toolniveau praktisch maakt.

‍

Het belangrijke onderdeel voor agents is de middelste laag. Toegangsregels kunnen worden verfijnd tot op individuele tools binnen een server, zodat u een agent de read-only tool ask_question van een database-server kunt verlenen, terwijl u de tool inhoudt die erin schrijft. Omdat de gateway voor elke call staat, geldt dezelfde regel voor elke caller van die tool, inclusief agents, zonder dat er iets per agent opnieuw hoeft te worden geïmplementeerd.

Least-Privilege afdwingen in de praktijk

Least privilege is minder een feature en meer een gewoonte die de gateway eenvoudig maakt om vol te houden. Een paar patronen leveren de meeste waarde op.

• Één identiteit per workload, strak afgebakend. Geef elke applicatie zijn eigen virtual account en elke agent zijn eigen agent identiteit, en verleen vervolgens aan elk alleen de model-accounts en MCP-tools die ze werkelijk gebruiken. Gedeelde, ruim afgebakende credentials zijn wat de blast radius groot maakt.
• Baken agents af op hun functie, niet op die van hun bestuurder. Een customer-support agent moet de support-tools bereiken en niets in de buurt van financiële gegevens of admin-endpoints, zelfs niet wanneer de persoon die hem gebruikt bredere toegang heeft. Machtigingen op agentniveau maken die scheiding werkelijkheid.
• Gebruik approver-rollen voor gevoelige tools. De MCP Server Approver-rol plaatst een mens in de loop voordat tools met een hoge impact worden uitgevoerd, wat vaak veiliger is dan een harde toestemming of weigering.
• Geef de voorkeur aan teams boven toewijzingen per gebruiker. Wijs rollen eenmalig toe aan een team en beheer het lidmaatschap, zodat toegang overzichtelijk blijft naarmate mensen en agents komen en gaan.

Voor autorisatie die afhankelijk is van request-context in plaats van een statische rol, ondersteunt de gateway policy-as-code guardrails met Cedar en OPA bij de pre-tool hook. Hiermee kunt u fijnmazige regels uitdrukken, bijvoorbeeld door een tool-call alleen toe te staan wanneer request-metadata deze markeert als een niet-productieomgeving. In productie authenticeren applicaties met een afgebakend Virtual Account-token in plaats van een persoonlijk token, en kunnen ze elke call taggen met metadata die de policies lezen:

Waarom agent-toegang afdwingen bij de gateway

U zou kunnen proberen deze controles in elke agent in te bouwen, maar de reden om dat niet te doen is dekking. Wanneer toegang wordt afgedwongen bij de gateway, erft een nieuwe agent die een reeds beheerd model of MCP-server aanroept automatisch de toegangsregels, zonder dat er iets aan de code van de agent hoeft te worden toegevoegd. Agents gebouwd op LangGraph, CrewAI, AutoGen of een custom loop routeren allemaal via dezelfde control plane en krijgen dezelfde policies.

Het houdt ook toegangsbeslissingen op een plek waar ze geauditeerd kunnen worden. Elke call draagt de identiteit van de caller en de bereikte resource bij zich, zodat u vanaf één plek de vraag kunt beantwoorden "welke agents kunnen aan deze tool komen" in plaats van tientallen repositories te moeten doorzoeken. Toegangsbeheer, agent identiteit en guardrails vormen vervolgens samen één beheerd pad voor calls: identiteit zegt wie er aanroept, toegangsbeheer zegt of de call is toegestaan, en guardrails inspecteren wat deze bevat. De gateway voegt hierbij slechts enkele milliseconden overhead toe, dus het plaatsen van alle drie in het kritieke pad vertraagt agents niet.

Het resultaat is toegangsbeheer dat zich gedraagt als infrastructuur. Het wordt uniform toegepast, is in beheer bij het platformteam en wordt afgedwongen binnen uw eigen AWS-, GCP- of Azure-account, wat SOC 2-, HIPAA- en GDPR-reviews haalbaar maakt.