TrueFoundry vs OpenRouter: AI-agentidentiteit en toegangsbeheer (2026)

De eerste vraag die een AI gateway moet beantwoorden is niet welk model moet worden aangeroepen, maar wie of wat de aanroep doet. Twee jaar geleden was het antwoord bijna altijd een mens met een API-sleutel. Tegenwoordig komen de meeste requests via een gateway van services, CI-pipelines en agents. Het identiteitsmodel bepaalt of een productiesysteem blijft functioneren op de dag dat de maker het bedrijf verlaat. Dat maakt identiteit van AI-agents tot een primair evaluatiecriterium in plaats van een bijzaak voor compliance, en het is precies waar de TrueFoundry AI Gateway en OpenRouter het sterkst uiteenlopen.

In dit artikel vergelijken we beide oplossingen op het volledige vlak van identiteit: menselijke identiteit (SSO, SCIM, MFA), workload- en agentidentiteit, de fijnmazigheid van authenticatie en autorisatie, MCP-authenticatie en tool-autorisatie, de levenscyclus van credentials en delegatie. Het is geschreven voor platform engineers en securityteams die een evaluatie uitvoeren, en elke bewerking is gebaseerd op de openbare documentatie van beide leveranciers. Als u de evaluatiefase al voorbij bent, kunt u een TrueFoundry-demo boeken om agentidentiteiten en RBAC op toolniveau live in actie te zien.

TrueFoundry vs OpenRouter op het gebied van identiteit: in één oogopslag

Menselijke identiteit: SSO, SCIM en MFA

TrueFoundry ondersteunt SSO via SAML 2.0 en OIDC, met handleidingen per IdP voor Okta, Microsoft Entra, Google Workspace en JumpCloud, evenals SCIM-provisioning van gebruikers en teams voor Okta, Entra en JumpCloud (SSO-overzicht). We onderhouden onze eigen gebruikers-store en federeren deze op drie manieren: SSO voor inloggen, SCIM voor de levenscyclus en Identity Providers voor de validatie van runtime-tokens, wat hieronder wordt behandeld. Een belangrijke voetnoot die hier én in onze deployment-blogpost thuishoort: standaard verloopt de inlogprocedure via onze gehoste auth-server, zelfs bij self-hosted deployments. Bij on-prem-deployments op de hogere Enterprise-tier verwijdert een Direct IdP-integratie die route — de control plane communiceert rechtstreeks met uw OIDC- of SAML-IdP en tokens worden lokaal ondertekend, waardoor authenticatieverkeer uw omgeving nooit verlaat (externe SSO).

OpenRouter SSO gebruikt SAML, met expliciete ondersteuning voor Okta, Microsoft Entra ID, Google Workspace of een willekeurige aangepaste SAML-provider, uitsluitend op Enterprise-plannen. De instelling is self-service: voeg uw e-maildomein toe, verifieer het met een DNS TXT-record, koppel de IdP, test en activeer. OIDC wordt nergens in de documentatie genoemd. SCIM wordt ondersteund met de IdP als source of truth, en SCIM Group Mappings koppelen IdP-groepen aan workspaces met een gekozen rol, inclusief een "Refresh from IdP"-actie en auditlog-vermeldingen voor verwijderingen. Eén detail bij offboarding verdient de aandacht van elk securityteam: deactivering in de IdP trekt de toegang van de organisatie in en deactiveert de sleutels die de gebruiker in de organisatie heeft aangemaakt, maar het persoonlijke OpenRouter-account en de persoonlijke sleutels van het individu blijven bestaan. Niets weerhoudt dat account er van om dezelfde modellen op eigen credits aan te roepen; de door de gebruiker aangemaakte sleutels worden gedeactiveerd in alle workspaces van de organisatie, en hun lidmaatschappen van andere organisaties blijven onaangetast. Alleen het verwijderen van het OpenRouter-account zelf beëindigt de persoonlijke toegang.

Geen van beide leveranciers documenteert native MFA. Beide delegeren dit via SSO naar de identity provider, wat de juiste oplossing is voor een onderneming, maar de verkeerde voor een team zonder IdP.

AI-agentidentiteit en workloadidentiteit

Dit is het scherpste contrast op deze agenda, en de reden waarom identiteit een inkoopvraagstuk is geworden in plaats van een beheerinstelling.

TrueFoundry kent drie primaire typen. Gebruikers beschikken over personal access tokens, waarvan in onze documentatie expliciet wordt afgeraden deze in productie te gebruiken. Virtuele accounts zijn volwaardige niet-menselijke identiteiten voor applicaties, services en CI (één per applicatie aanbevolen), met hun eigen tokens die losstaan van die van de gebruiker (virtuele accounts).

Agent Identity, momenteel in bèta, is een derde primair type dat 1:1 wordt aangemaakt wanneer een agent wordt geregistreerd. Dit wordt uitgegeven door TrueFoundry of door uw IdP, zodat een agent geen token van een gebruiker leent of zich verschuilt achter een gedeeld service-account; de uitgaande calls van een embedded agent worden beheerd, zelfs wanneer de gateway het inkomende verkeer niet afhandelt (agentidentiteit). Het bèta-label is belangrijk en dat vermelden we dan ook eerlijk: de functionaliteit is gedocumenteerd, maar nog niet GA (General Availability).

OpenRouter heeft geen afzonderlijk niet-menselijk primair type. Er is geen service-account, virtueel account of agentidentiteit; elke sleutel wordt aangemaakt door en behoort toe aan een menselijke gebruiker binnen een workspace. Wat wel bestaat, is programmatisch sleutelbeheer. Een OpenRouter provisioning key, gegenereerd in het dashboard, kan andere sleutels beheren maar geen completions aanroepen; u gebruikt deze tegen de /api/v1/keys endpoints om sleutels per ontwikkelaar of per project aan te maken, elk met een optioneel label en bestedingslimiet. Beheersleutels werken op accountniveau. Een gelabelde sleutel met bestedingslimiet is een betere hygiëne dan één gedeelde secret, maar het blijft het credential van een gebruiker. Het eigen SCIM-gedrag van OpenRouter bewijst deze koppeling: deprovision de mens, en de door hem aangemaakte sleutels worden gedeactiveerd. Een productieservice waarvan de sleutel is aangemaakt door een engineer die inmiddels is vertrokken, stopt met werken. Dat is het concrete operationele risico, en dat is de regel die u moet voorleggen aan iedereen die OpenRouter evalueert voor een vloot aan services in plaats van een team ontwikkelaars.

AI-agentauthenticatie en autorisatie: hoe fijnmazig?

Authenticatie bewijst wie er belt; autorisatie bepaalt wat ze mogen doen. In het eerste deel accepteren beide leveranciers bearer-tokens op een OpenAI-compatibel endpoint. In het tweede deel lopen ze uiteen.

De autorisatie van TrueFoundry is RBAC, geëvalueerd tegen de vastgestelde identiteit — of dat nu een gebruiker, een virtueel account of een agent is — op drie niveaus: welke modellen een entiteit mag aanroepen, welke MCP-servers deze kan bereiken en welke individuele tools binnen een MCP-server deze mag aanroepen (gebruikers-, team- en accountbeheer). Het is geen ABAC; attribuut- en op voorwaarden gebaseerde regels bevinden zich in onze guardrail-laag (Cedar- en OPA-policies), niet in het autorisatiemodel. Scoping is identiteitsgestuurd: u scoped de entiteit, niet het token, wat de levenscyclus overzichtelijk houdt wanneer tokens roteren.

De autorisatie van OpenRouter is RBAC met twee rollen. Org admins hebben beheerdersrechten over elke workspace (sleutels, guardrails, BYOK, routing, presets, plugins, observability, leden, instellingen) en alleen zij kunnen workspaces aanmaken of verwijderen; members hebben ledenrechten in elke workspace waar ze toe behoren; SCIM group mappings kiezen tussen dezelfde twee rollen. Fijnmazigere controle wordt bereikt via guardrails die gekoppeld zijn aan sleutels of leden (budgetten, allowlists voor modellen en providers, privacy- en content-controls), waarbij het policy op accountniveau geldt als een plafond dat een workspace alleen kan vernauwen. Beperking op modelniveau is mogelijk via policy; beperking op route-, tool- en parameterniveau niet. Wat tussen "admin van alles" en "member" in zit is mager: Workspace Admins kunnen nu workspace-scoped beheersleutels uitgeven die alleen binnen hun workspace werken — een echte delegatie van sleutelbeheer — maar er is nog steeds geen read-only auditor en geen budgetbeheerdersrol, en SCIM group mappings kiezen nog steeds uit dezelfde twee org-rollen. Voor een organisatie met 50 engineers die wil dat één persoon het budget van een team beheert zonder eigenaar te zijn van het account, is dit het punt om scherp in de gaten te houden.

Voor een breder overzicht van hoe agents zelf worden beheerd zodra ze geauthenticeerd zijn, behandelt onze agent gateway gids de runtime-zijde.

MCP-authenticatie en tool-autorisatie

MCP-authenticatie is het punt waar de twee producten niet langer vergelijkbaar zijn, omdat er maar één voor uw MCP-servers zit.

TrueFoundry boetseert expliciet twee lagen. Inkomende authenticatie (wie roept de gateway aan: een PAT, een virtueel account-token of het JWT van uw IdP) staat los van uitgaande authenticatie (wiers credentials de downstream MCP-server bereiken), waarbij RBAC bepaalt welke gebruikers en agents welke servers en welke individuele tools daartussen kunnen bereiken. Gebruikerstoestemming is gemodelleerd in het uitgaande traject als een OAuth-flow waarin de eindgebruiker de MCP-server autoriseert met hun eigen identiteit, van begin tot eind gedocumenteerd voor Okta en Azure Entra, met auth-overrides per server (MCP gateway auth en security, tool-goedkeuring). Als de protocolzijde hiervan nieuw voor u is, behandelt onze introductie over MCP-autorisatie dit onderwerp.

OpenRouter beheert uw MCP-servers niet. De Agent SDK kan nu een remote MCP-server koppelen aan een agent loop aan de client-zijde (@openrouter/mcp, HTTP/SSE), maar die verbinding draagt de credentials die uw applicatie heeft — er is geen model aan de gateway-zijde voor hoe een tool call de identiteit overdraagt of controleert, geen toewijzingen per tool en geen toestemmingsstap. De eigen MCP-server authenticeert u bij de catalogus van OpenRouter, wat inkomende toegang tot OpenRouter is, en geen autorisatie van uw tools. Het dichtstbijzijnde onderdeel betreft de server-geëxploiteerde tools: shell en bash draaien in containers die per account en workspace gescoped zijn en nooit gedeeld worden tussen tenants, en het engine veld van bash bepaalt of uitvoering aan de serverzijde plaatsvindt of wordt teruggegeven aan uw applicatie. Het is isolatie, geen autorisatie: geen toewijzingen per tool, geen toestemming.

Levenscyclus van credentials: uitgifte, rotatie, intrekking

Virtuele account-tokens van TrueFoundry ondersteunen automatische rotatie op een instelbaar interval met een instelbare gratieperiode voor het oude token, rotatienotificaties via e-mail of Slack, en automatische synchronisatie van geroteerde tokens naar AWS Secrets Manager en Parameter Store, GCP Secret Manager, HashiCorp Vault en Azure Key Vault (virtuele accounts). Persoonlijke tokens vervallen met de gebruiker. Vertraging bij het intrekken van tokens is niet gedocumenteerd; de configuratie synchroniseert naar gateway-planes via NATS, dus dit zou vrijwel real-time moeten zijn, maar het is een onderdeel dat u zelf moet testen.

OpenRouter heeft drie uitgifteroutes: het dashboard, de Management API via een provisioning key en OAuth PKCE. Voor inference-sleutels vervangen bestedingslimieten en reset-intervallen (dagelijks, wekelijks of maandelijks om middernacht UTC) de TTL's; er is geen vervaldatum gedocumenteerd. Beheersleutels ondersteunen nu een vervaldatum — vastgesteld bij aanmaak, niet te verlengen (maak een nieuwe sleutel aan om te verlengen), waarbij requests daarna falen met een 401 "API key expired" — en OpenRouter raadt aan om op elke beheersleutel een vervaldatum in te stellen. Rotatie is programmatische regeneratie, zonder geplande automatische rotatie of gratieperiode-mechanisme. Intrekking verloopt via het dashboard, de Management API of SCIM-deactivering; de vertraging bij intrekking is niet gedocumenteerd. Eén operationeel detail: om een lid uit een workspace te verwijderen, moeten eerst de sleutels worden verwijderd die hij of zij daar heeft aangemaakt.

Delegatie: OAuth PKCE vs runtime IdP JWT

Beide leveranciers ondersteunen delegatie, in vormen die gebouwd zijn voor verschillende typen kopers.

OpenRouter OAuth gebruikt PKCE en is verrassend goed uitgewerkt. Een app van derden stuurt de gebruiker naar openrouter.ai/auth met een callback-URL en een code_challenge; nadat de gebruiker toestemming geeft, wisselt de app de code op /api/v1/auth/keys in voor een sleutel die de credits van die specifieke gebruiker verbruikt. De autorisatiecodes zijn voor eenmalig gebruik en vervallen na 10 minuten. Geen clientregistratie, geen client secret, geen backend en localhost-callbacks op elke poort voor lokale CLI-tools. Voor consumentenapps en ontwikkelaarstools is dit een echt pluspunt en dat erkennen we dan ook volledig. Wat het niet is: het resultaat is een langdurige API-sleutel in plaats van een gescoped, verlopend token, er is geen refresh-mechanisme en delegatie vindt eenmalig plaats op het moment van autorisatie zonder identiteitsdoorgifte per request. Er is ook geen gedocumenteerde route om het JWT van uw IdP aan de inference-API te tonen; elke request bevat een door OpenRouter uitgegeven sleutel, dus de echte identiteit van de aanroeper moet downstream worden gereconstrueerd op basis van sleutellabels.

De delegatie van TrueFoundry is gebouwd voor enterprise-situaties. Met Identity Providers presenteert een externe app of gebruiker het JWT van uw IdP rechtstreeks aan de gateway; wij valideren het via JWKS en koppelen het aan een TrueFoundry-identiteit voor RBAC. Hierdoor blijft de identiteit van de bovenliggende gebruiker bij elke request behouden, zonder dat er een TrueFoundry-token gegenereerd hoeft te worden (identity providers). Het uitgaande OAuth-traject van MCP werkt als door de gebruiker gedelegeerde toegang tot downstream tools. Formele RFC 8693 token exchange is aan geen van beide kanten gedocumenteerd.

TrueFoundry vs OpenRouter: identiteit direct vergeleken

De functionaliteiten van TrueFoundry zijn afkomstig uit onze documentatie; de functionaliteiten van OpenRouter weerspiegelen de openbaar gedocumenteerde functionaliteit op het moment van schrijven.

Wanneer kiezen voor OpenRouter?

• Uw callers zijn individuele ontwikkelaars, elk met hun eigen sleutel en bestedingslimiet, en een model met twee rollen volstaat voor de manier waarop uw organisatie werkt.
• U bouwt een consumentenapp of een CLI-tool waarbij eindgebruikers voor hun eigen inference moeten betalen; de OAuth PKCE-flow van OpenRouter is de strakste implementatie van dat patroon die beschikbaar is.
• U hebt nog geen IdP in gebruik en bent niet bereid te betalen voor Enterprise om SSO en SCIM te krijgen; de provisioning keys van OpenRouter bieden u zonder extra kosten gelabelde, gelimiteerde sleutels per project.

Wanneer kiezen voor TrueFoundry?

• Services, pipelines en agents voeren het merendeel van uw calls uit en hebben identiteiten nodig die langer meegaan dan de mensen die ze hebben ingesteld. Virtuele accounts en agentidentiteiten zijn precies hiervoor ontworpen.
• Uw identity provider moet bij de request betrokken zijn, niet alleen bij het inloggen, zodat de echte identiteit van een gebruiker bij elke call de gateway bereikt zonder een door de gateway uitgegeven token ertussen.
• U hebt rollen nodig tussen "alles" en "member": een teammanager die een budget beheert, een model-accountmanager die geen eigenaar is van de tenant.
• Uw verkeer omvat uw eigen MCP-tools en agents, en tool calls moeten per tool geautoriseerd worden met toestemming van de eindgebruiker en de juiste downstream credentials.
• Rotatie moet automatisch verlopen en in uw secret manager belanden, in plaats van een herinnering in de agenda te zijn.

Voor een breder overzicht van gateways die workloadidentiteit en SSO bieden onder een Enterprise-tier, bekijkt u onze gids voor OpenRouter-alternatieven.

Gerelateerde artikelen

• Wat is MCP-autorisatie? — de achtergrond op protocolniveau bij het MCP-gedeelte
• Overzicht Identity and Access Management — introductie tot de tenants, gebruikers, teams, virtuele accounts, SSO, provisioning, identity providers en toegangsbeheer van TrueFoundry
• Agent Gateway — hoe beheerde agent-runtimes werken
• AI Agent Registry — op schaal registreren en beheren van agents
• Best practices voor MCP-serverbeveiliging — het beveiligen van de servers die uw agents aanroepen
• OpenRouter-alternatieven — het bredere veld van enterprise-opties

Conclusie

Het identiteitsmodel van OpenRouter is dat van een ontwikkelaar: mensen bezitten sleutels, twee rollen dekken de organisatie af en de beste functie stelt apps van anderen in staat om veilig het wisselgeld van een gebruiker uit te geven. Het identiteitsmodel van TrueFoundry is dat van een platform: drie primaire typen, runtime-federatie met uw IdP, rotatie die in uw secret manager belandt en autorisatie die reikt tot aan een individuele MCP-tool. Specifiek voor AI-agentidentiteit geldt dat het ene product het wel heeft en het andere niet. Die enkele regel zal de evaluatie beslissen voor elke organisatie waarvan de services en agents in de meerderheid zijn ten opzichte van het aantal ontwikkelaars.

Als u evalueert hoe agents en services zich gaan authenticeren bij uw modellen en tools, boek dan een demo om virtuele accounts, agentidentiteiten en RBAC op toolniveau te zien op de TrueFoundry AI Gateway.