TrueFoundry vs OpenRouter: Privacy, Tenancy en Isolatie — Wie Kan Uw Prompts Zien? (2026)

“Is OpenRouter veilig?” is de vraag die we het vaakst horen van teams die het voor één project hebben geadopteerd en nu door security worden gevraagd om het voor het bedrijf te rechtvaardigen. Het eerlijke antwoord is dat het privacy-profiel van OpenRouter op één as beter is dan zijn reputatie en op drie andere zwakker, en welke daarvan van belang is, hangt volledig af van of u een team van vijf of een organisatie van vijftig bent.

Dit artikel behandelt het hoofdstuk tenancy en isolatie van onze TrueFoundry vs OpenRouter serie: wat elk product opslaat, wie het kan zien, hoe teams binnen één implementatie worden gescheiden, wat geforceerd globaal is, of infrastructuur wordt gedeeld of toegewijd is, en de praktische limieten. Het is geschreven voor de platform engineer of security lead die die rechtvaardiging uitvoert, en elke claim is ontleend aan de openbare documentatie van de twee leveranciers. Als u eerst het bredere beeld wilt, legt onze LLM gateway introductie uit waar een gateway zich in de stack bevindt.

In één oogopslag

Is OpenRouter veilig? Wat het opslaat en wie het kan zien

Begin met het gedeelte dat OpenRouter goed aanpakt. OpenRouter logt standaard geen prompts of completions. Alleen verzoek-metadata (tijdstempels, model, aantallen tokens, latentie) wordt bewaard voor facturering en operationele doeleinden. Er is niets voor een beheerder om te lezen, tenzij iemand zich hier expliciet voor aanmeldt.

De opt-in is Input & Output Logging, momenteel in beta, in te schakelen in de Observability-instellingen van een workspace. Zodra dit is ingeschakeld, verschijnen prompts en completions op de pagina Logs; in een organisatie kunnen alleen admins dit bekijken of in- en uitschakelen, niet-admin leden hebben geen toegang tot opgeslagen inhoud, de opslag bevindt zich in een geïsoleerd Google Cloud Storage-project met afzonderlijke toegangscontroles, en alleen generaties die zijn gemaakt na het inschakelen worden opgeslagen. Het geldt niet voor verzoeken via de regionale EU- of US-endpoints, die normaal worden verwerkt waarbij logging wordt overgeslagen. Er bestaan twee afzonderlijke opt-ins die niet moeten worden verward: Input & Output Logging, dat inhoud opslaat en deze terugtoont aan uw admin, en een opt-in voor privacy-instellingen die prompt-logging inruilt voor een gebruiks-korting.

Dat is het gegevensprivacy-verhaal van OpenRouter op de eigen infrastructuur van OpenRouter, en voor een team dat “niets opgeslagen tenzij wij dat zeggen” wil, is het een oprecht goede standaard. Drie dingen staan aan de andere kant van de balans. Prompts verlaten altijd uw netwerk en steken twee grenzen over (van u naar OpenRouter, van OpenRouter naar de provider); zero-data-retention routing en in-region routing beperken wat providers bewaren en waar de verwerking plaatsvindt, niet of de gegevens het netwerk verlaten. De regionale endpoints sluiten inhoudslogging uit, dus EU-residency en audit op prompt-niveau sluiten elkaar uit. En isolatie tussen klantorganisaties is grotendeels ongedocumenteerd; de enige expliciete garantie is dat server-tool containers zijn afgebakend per account en workspace en nooit tussen tenants worden gedeeld.

Dus: is OpenRouter veilig voor een individuele ontwikkelaar? De standaardinstelling is een van de schoonste op de markt. Is het privé in de zin van wat een onderneming bedoelt, waar gegevens binnen een grens blijven en een beleid bepaalt wat er wordt bewaard? Nee, en geen enkele configuratie maakt dat zo.

Hoe OpenRouter organisaties en workspaces werken voor teams

OpenRouter voor teams betekent twee niveaus: een organisatie (het account) en workspaces daarbinnen. Er zijn geen team-, project- of omgevings-objecten. Alle organisatieleden krijgen automatisch leden-toegang tot de Default workspace, leden kunnen tot meerdere workspaces behoren met hun sleutels in elke workspace beheerd door de instellingen van die workspace, en alleen organisatie-admins kunnen workspaces maken of verwijderen of controleren wie toegang heeft tot elke workspace. Scheiding van omgevingen is workspace-by-convention: een “prod” workspace en een “dev” workspace, zonder iets in het product dat het verschil kent.

Per workspace krijgt u API-sleutels, guardrails, BYOK, routing, presets, plugins, observability, leden en instellingen. Geforceerd globaal op accountniveau: facturering en credits (één factuur, één pool), organisatielidmaatschap en rollen, management API-sleutels en gegevensbeleid op accountniveau plus toegestane providers en modellen. De overervingsregel is een goed ontwerp en tegelijkertijd een echte beperking: het beleid op accountniveau is het plafond, en een workspace kan alleen restrictiever zijn, dus een platformteam kan een globale veiligheidsondergrens instellen, maar kan een workspace niets verlenen wat het account verbiedt.

Drie bevindingen verdienen de aandacht van een security reviewer. Ten eerste spreekt de eigen documentatie van OpenRouter zichzelf tegen over sleutelisolatie: de pagina Workspaces zegt dat leden hun eigen sleutels maken en beheren, terwijl de pagina Organization Management zegt dat sleutels gemaakt door een willekeurig lid door alle leden kunnen worden gebruikt, gefactureerd aan de pool van de organisatie, waarbij admins elke sleutel kunnen bekijken. Als dat laatste het geval is, is “bekijk die van uzelf, gebruik die van iedereen” een aanzienlijk isolatie-zwaktepunt; de oudere pagina is mogelijk van vóór de workspaces, maar het is de moeite waard om na te vragen. Ten tweede is een OpenRouter organisatie beperkt tot 10 leden, beschikbaar door contact op te nemen met support, dus een evaluatie voor vijftig engineers begint met een support-ticket. Ten derde wordt noisy-neighbour gedrag niet behandeld, en omdat snelheidslimieten meeschalen met het kredietsaldo van het account en credits zich boven workspaces bevinden, verbruikt het verkeer van de ene workspace waarschijnlijk de capaciteit die door de rest wordt gedeeld.

Sleutels zijn afgebakend tot één workspace en behoren toe aan de gebruiker die ze heeft gemaakt, met een uitgavelimiet, een optioneel herstelinterval en guardrails die aan individuele sleutels of leden kunnen worden toegewezen. Budgetten worden nooit gepoold: hetzelfde dagelijkse budget toegepast op drie leden geeft ieder hun eigen budget. Alles wat verfijnder is dan workspace-plus-eigenaar wordt toegepast via gekoppeld beleid in plaats van een eigenschap van de sleutel te zijn.

Het tenancy-model van TrueFoundry: tenants, teams en virtuele accounts

TrueFoundry nestelt Control plane → Tenants → Gebruikers, Teams, Virtuele Accounts en bronnen. De tenant is de harde grens: elke tenant heeft zijn eigen gebruikers, teams, virtuele accounts, SSO-configuratie, identity providers, rollen en bronnen (modellen, MCP-servers, prompts, workspaces), en onze documentatie vermeldt duidelijk dat er geen interactie is tussen gegevens in verschillende tenants; gebruikers loggen afzonderlijk in op elke tenant en elke tenant kan zijn eigen SSO draaien (gebruikers-, team- en accountbeheer). Teams groeperen gebruikers voor toewijzing van toegang, en virtuele accounts geven services en agents hun eigen identiteit.

Er is ook geen afzonderlijk omgevingsobject, maar we documenteren de aanbeveling in plaats van het aan een afspraak over te laten: virtuele accounts per omgeving binnen één tenant voor lichte scheiding, afzonderlijke tenants (company-dev, company-prod) voor configuratiescheiding, of afzonderlijke gateway- of control-planes voor infrastructuurscheiding, afhankelijk van de implementatiemodus (meerdere omgevingen instellen). Wat geforceerd globaal is: de infrastructuur van de control plane zelf (Postgres, NATS en ClickHouse worden gedeeld in een multi-tenant control plane), de platformversie (alle tenants op één control plane upgraden samen, daarom raden we twee control planes aan voor prod en non-prod) en de licentie-afhankelijkheid (multi-tenant control plane).

Het afbakenen van sleutels verloopt via identiteit. Een token verwijst naar een principal (een virtueel account of een gebruiker), en RBAC op die principal bepaalt waar deze toegang toe heeft: op model-accountniveau, individuele modellen, MCP-servers en individuele tools, met snelheids- en budgetlimieten gekoppeld op gebruikers-, team-, virtueel-account- of modelniveau. U bakent de principal af, niet het token, wat de levenscyclus overzichtelijk houdt. Er is geen maximaal aantal tenants, teams, virtuele accounts of sleutels gedocumenteerd, en autorisatiecontroles worden in het geheugen uitgevoerd op het gateway-plane, wat er ook voor zorgt dat de gateway op ongeveer 3–4 ms extra latentie blijft en 350+ verzoeken per seconde per vCPU verwerkt over 1.000+ LLM's.

Zichtbaarheid voor beheerders: privacy by default vs privacy by policy

Dit is de rij waarin de twee producten spiegelbeelden van elkaar zijn, en het is de moeite waard om precies te zijn.

Op OpenRouter is de zichtbaarheid over verschillende workspaces heen totaal voor organisatie-admins, die overal admin-rechten hebben; niet-admin leden zien Activity en Logs op accountniveau. Maar de inhoud van prompts is standaard voor iedereen onzichtbaar, omdat deze niet wordt opgeslagen. Privacy is een standaardinstelling, afgedwongen door afwezigheid. De bediening is een knop op workspace-niveau: geen beslissing per verzoek, geen maskering vóór opslag, geen variatie per ontwikkelaar, model, omgeving of patroon.

Op TrueFoundry is de zichtbaarheid over verschillende tenants heen nihil; de grens is absoluut, en een beheerder van een self-hosted control-plane beheert tenants zonder dat hun gegevens zich vermengen. Binnen een tenant hebben admins automatisch toegang tot alle modellen en zijn verzoek- en responslogs doorzoekbaar, zodat een admin binnen een tenant de inhoud van prompts kan zien overal waar logging is ingeschakeld (gateway toegangsbeheer). We vermelden dat duidelijk omdat het antwoord een beleid is, geen afwezigheid. Logging Configs zijn benoemde regels met voorwaarden voor subobjecten, modellen en metadata; elke regel bevat een knop voor log in/uit en anonimiseringspatronen (e-mail, US SSN, creditcard, India Aadhaar en PAN, plus aangepaste regex met aangepaste vervangende tekst) die alleen op het opgeslagen exemplaar worden toegepast; bij overeenkomstige regels wint weigeren, anonimiseringen worden samengevoegd, een header per verzoek fungeert als terugvaloptie en elke trace legt vast welke regel heeft beslist (logging config). Een platformteam kan dus niets loggen voor het juridische team, loggen maar maskeren voor de klantenservice, en alles loggen voor de evaluatiepijplijn, en bewijzen welke regel op elke trace van toepassing was.

Privacy by default is beter voor een team dat nooit iets zal configureren. Privacy by policy is beter voor een organisatie die aan een auditor moet verantwoorden “wie dit had kunnen zien en wat er is gemaskerd”.

Gedeelde vs toegewijde infrastructuur

OpenRouter is gedeelde infrastructuur voor iedereen op elk niveau. Er is geen toegewijde of single-tenant optie gedocumenteerd; in-region routing is het enige verschil op infrastructuurniveau en het is geografisch, niet toegewijd, dus elke enterprise-klant in de EU deelt het EU-endpoint. Het geïsoleerde GCS-project dat wordt gebruikt voor opgeslagen prompts is componentisolatie, geen infrastructuur per tenant.

TrueFoundry dekt het hele spectrum. Managed SaaS is gedeelde multi-tenant infrastructuur, met een eigen-bucket variant voor uw traces. Hybrid geeft u een toegewijd gateway-plane in uw VPC met een gedeeld TrueFoundry control-plane, zodat prompts uw netwerk nooit verlaten. Volledig self-hosted is voor alles toegewijd, en een self-hosted control-plane kan zelf multi-tenant draaien met subdomeinen per tenant voor een platformteam dat meerdere interne tenants bedient (implementatiemodi). Meerdere gateway-planes onder één control-plane bieden scheiding op VPC-niveau, met dev- en prod-VPC's gedocumenteerd. Als u al modellen binnen uw eigen omgeving draait, legt onze gids over on-premise LLM-implementatie uit hoe de gateway daarnaast wordt geplaatst.

Binnen een gedeeld TrueFoundry gateway-plane is noisy-neighbour bescherming geregeld via snelheids- en budgetlimieten per team of virtueel account; quality of service op tenant-niveau is niet gedocumenteerd, wat hetzelfde eerlijke hiaat is als bij OpenRouter, en dezelfde vraag om aan beide leveranciers te stellen.

TrueFoundry vs OpenRouter: tenancy en isolatie rechtstreeks vergeleken

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

Wanneer kiezen voor OpenRouter

• U bent één team met een handvol workspaces, een enkele gedeelde kredietpool is prima, en niemand heeft een rol nodig tussen Admin en Member.
• “Niets opgeslagen tenzij we ons aanmelden” is de isolatie-eigenschap die u het belangrijkst vindt, en een knop op workspace-niveau is alle logging-controle die u nodig hebt.
• Uw prompts stellen geen eisen aan gegevensgrenzen, dus het doorvoeren via OpenRouter en haar providers is acceptabel voor uw securityteam.

Wanneer kiezen voor TrueFoundry

• U hebt echte tenants nodig: afzonderlijke SSO, afzonderlijke identity providers, afzonderlijke bronnen, afzonderlijke facturen en teams daarbinnen.
• Zichtbaarheid in prompts moet een beleid zijn, geen knop: loggen voor sommige teams, maskeren voor andere, onderdrukken voor de rest, en per trace bewijzen welke regel heeft beslist.
• Infrastructuur moet van u zijn op gateway-plane niveau of volledig, of prompts mogen uw VPC nooit verlaten.
• U bent met meer dan tien personen en wilt geen support-ticket tussen u en een evaluatie op echte schaal.

Voor het bredere veld van gateways die tenants, anonimiseringsbeleid en toegewijde infrastructuur bieden, zie onze gids voor OpenRouter alternatieven.

Gerelateerde artikelen

• OpenRouter Alternatieven — het bredere veld van enterprise-opties
• Enterprise AI Security met een MCP Gateway — de beveiligingslaag rond tool- en agent-verkeer
• On-Premise LLM-implementatie — modellen en de gateway binnen uw omgeving houden
• Wat is AI Governance? — het beleidskader waar de logging-regels van dit artikel binnen vallen
• Wat is een LLM Gateway? — de architecturale introductie

Conclusie

OpenRouter privacy is een sterke standaard binnen een oppervlakkige structuur: er wordt niets opgeslagen tenzij u daarom vraagt, maar alles verlaat uw netwerk, iedereen deelt de infrastructuur en het organisatiemodel stopt bij workspaces, twee rollen en tien leden. De tenancy van TrueFoundry is diepgaand en de privacy is bewust ingericht: harde tenant-grenzen, teams en virtuele accounts, een logging-beleid dat per team en per verzoek bepaalt wat er wordt opgeslagen en wat wordt gemaskerd, en infrastructuur die gedeeld of volledig van u kan zijn. Voor een klein team is de standaardinstelling van OpenRouter moeilijk te betwisten. Voor een organisatie die verantwoording moet afleggen aan een auditor, wint het beleid.

Om te zien hoe een tenant, een logging-beleid en een toegewijd gateway-plane samenkomen, kunt u de TrueFoundry AI Gateway verkennen, of een demo boeken als u nu een uitrol voor meerdere teams formuleert.