Wat beveiligingsteams daadwerkelijk nodig hebben van een AI-gateway

Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
Vraag tien mensen in de beveiliging wat een AI-gateway doet en u krijgt tien verschillende antwoorden: een proxy die API-sleutels uitwisselt, een plek om prompts te loggen, een firewall voor chatbots. Niets daarvan is pertinent onjuist, maar geen enkel antwoord biedt het volledige beeld. De kloof tussen "deels juist" en "beheert daadwerkelijk AI-gebruik" is precies waar datalekken ontstaan.
Uit IBM's Cost of a Data Breach Report van 2025 bleek dat 20% van de getroffen organisaties werd gecompromitteerd door schaduw-AI, oftewel werknemers die generatieve AI-tools gebruiken die de beveiligingsafdeling nooit heeft goedgekeurd of gekend. Dit voegde ongeveer $ 670.000 toe aan de gemiddelde kosten van een datalek. Van deze organisaties ontbrak het bij 97% aan een goed toegangsbeheer, en uit een enquête van het Ponemon Institute onder 600 organisaties bleek dat 63% helemaal geen beleid voor AI-governance had. [1]
Kosteninzicht en governance vormen een probleem dat niet kan worden opgelost door simpelweg nog een tool aan te schaffen. Dit artikel doorloopt het onderwerp zoals een CISO het zou benaderen: kunt u al het AI-gebruik in uw organisatie zien en beheren, wat kunt u doen zodra u het ziet, en kan het samenwerken met de stack die u al gebruikt?
Vraag 1: Kunt u al het AI-gebruik in uw organisatie zien en beheren?
Vraag de meeste beveiligingsleiders om elke AI-tool op te sommen die binnen hun bedrijf wordt gebruikt, en ze kunnen het niet. AI-gebruik komt via ten minste vier deuren binnen, en elke deur vereist een andere oplossing.

Apps en agents die uw eigen ontwikkelaars bouwen. Het eenvoudigste geval, aangezien uw eigen teams de code beheren. Routeer aanroepen via een afgebakende, intrekbare authenticatiegegeven in plaats van een ruwe API-sleutel. TrueFoundry doet dit met een Virtual Account Token: gekoppeld aan één applicatie, zichtbaar in logs als die specifieke applicatie en afzonderlijk in te trekken.
Desktop- en CLI-tools die werknemers al gebruiken. Bij Cursor, Claude Code en Codex CLI kunt u doorgaans instellen met welk eindpunt ze communiceren. Dat maakt handhaving een configuratievraagstuk in plaats van een onderscheppingsprobleem: uitrol van TrueFoundry's gateway-eindpunt over de gehele vloot via uw MDM (Jamf, Intune).
Consumentenweb-apps. De webinterfaces van ChatGPT en Claude vormen het lastige geval: geen configuratiebestand, geen code om aan te passen. TrueFoundry lost dit op met aitori, een proxy op het apparaat zelf die werkt als een VPN-client. Deze onderschept het verkeer op OS-niveau en omleiding het naar de gateway via een apparaatcertificaat. Het is open-source: de code staat op GitHub.

AI die is ingebouwd in SaaS-tools waar u al voor betaalt. Salesforce Einstein, Slack's AI-samenvattingen en soortgelijke functionaliteiten vormen de uitzondering. De modelaanroep verlaat de servers van de leverancier nooit, dus er valt niets te onderscheppen. Geen enkele gateway, inclusief die van TrueFoundry, lost dit vandaag de dag op; de terugvaloptie bestaat uit CASB-achtige controles of de eigen beheerinstellingen van de leverancier.
Drie van de vier deuren zijn vandaag de dag op te lossen. De vierde niet, en elke leverancier die het tegendeel beweert, verdient een kritische blik.
Vraag 2: Zodra u het verkeer kunt zien, wat kunt u er dan daadwerkelijk tegen doen?
Zichtbaarheid beantwoordt de vraag "wat er gebeurt". Actie ondernemen valt uiteen in drie gebieden.
Toegangsbeheer (Access management)
De meeste mensen richten zich hierbij op één scenario: als iemand het bedrijf verlaat, hoe snel vervalt de toegang dan? TrueFoundry regelt dat via SSO met SCIM, JIT of provisioning op basis van uitnodiging, zodat een wijziging in de IdP-groep automatisch een wijziging in de toegang wordt. Maar het omvat ook authenticatie (tokens gekoppeld aan Okta, Entra of Google Workspace, die vervallen op het moment dat het IdP-account wordt gedeactiveerd), role-based access op basis van het principe van de minste rechten (least-privilege RBAC), en continu toezicht op wie op dit moment bevoorrechte toegang heeft.
Het onderdeel dat de meeste leveranciers overslaan is niet-menselijke identiteit (non-human identity). Teams bouwen agents op elk willekeurig framework (LangGraph, CrewAI, Bedrock, een zelfgeschreven script), en niets dwingt iemand om het bestaan ervan te declareren voordat deze interne tools begint aan te roepen. Dat is schaduw-IT, met het verschil dat het verborgen onderdeel acties kan uitvoeren en niet alleen gegevens kan lezen. TrueFoundry's oplossing scheidt de identiteit van een agent (wie is deze agent, verplicht voor elke agent) van de registratie (wat kan deze doen, namens wie). Voor een keten zoals van planning-agent naar research-agent naar retrieval-agent naar tool-aanroepen, gebruikt TrueFoundry token exchange: elke stap krijgt een nieuw token, de mens blijft het verantwoordelijke subobject, en elke handelende agent wordt vastgelegd in plaats van te verdwijnen achter de naam van de mens. De volledige analyse van agent-identiteit en multi-agent governance vindt u hier, inclusief de koppeling met Okta's Cross-App Access en Microsoft Entra's On-Behalf-Of.

MCP-governance en guardrails
MCP-tools voeren daadwerkelijke acties uit (schrijven naar een database, een e-mail versturen), wat een grotere impact heeft dan een chatantwoord. TrueFoundry's MCP Gateway maakt een scheiding tussen de manier waarop een aanroeper authenticeert, welke gebruiker of app specifieke servers en tools kan bereiken (op tool-niveau, niet de gehele server), en hoe de gateway uitgaand authenticeert naar de server, onafhankelijk van inkomend verkeer. Daardoor kan een private, in een VPC gehoste server worden bereikt via een tunnel zonder inkomende poorten, die centraal wordt geregistreerd in plaats van per ontwikkelaar.

Niets van dat alles vertelt u wat er in een aanroep zit. Guardrails doen dat wel door de payload zelf te lezen en te redigeren, in beide richtingen en ook voor MCP-tool-aanroepen. TrueFoundry's AI Gateway wordt geleverd met ingebouwde guardrails (detectie van PII/PHI, bescherming tegen prompt injection, contentmoderatie, detectie van geheimen, aangepast beleid via Cedar of OPA) en integreert bovendien met elke guardrail-leverancier die u al gebruikt. Meer over MCP-governance en runtime guardrails leest u hier, en meer over het identiteitsaspect vindt u hier.

Audit trail, die drie behoeften dekt
"Wij loggen alles" betekent meestal een van deze drie dingen: een live dashboard voor doorlopende zichtbaarheid, automatische vastlegging van elke prompt, respons, identiteit en kosten voor forensische reconstructie, of een schone SIEM-export (Splunk, Datadog, Grafana) voor compliance-bewijsvoering. TrueFoundry dekt alle drie vanuit hetzelfde logbestand, wat het daadwerkelijke bewijs vormt achter een SOC 2- of HIPAA-status. De volledige checklist voor audit trails vindt u hier.
Vraag 3: Vervangt dit uw beveiligingsstack, of werkt het ermee samen?
Het werkelijke bezwaar hier is meestal verander-management, niet de technologie: niemand wil tools vervangen die hun nut al hebben bewezen. Een goed gebouwde AI-gateway bevindt zich stroomafwaarts van wat u al gebruikt.
Stuur AI-gerelateerd verkeer van uw SWG (Zscaler, Netskope) naar de gateway van TrueFoundry met de identiteit van de gebruiker in een header, en de gateway verzorgt vanaf daar de governance zonder de taak van de SWG over te nemen. Jamf en Intune rollen aitori vlootbreed uit zoals elke andere agent. CrowdStrike Falcon vervult een andere rol, namelijk als vangnet dat niet-sanctioneerde AI-apps direct blokkeert op het eindpunt. Niets hiervan vraagt u om te kiezen tussen uw huidige stack en TrueFoundry; het vraagt TrueFoundry om hier naadloos op aan te sluiten.
Kunt u de leverancier vertrouwen die dit allemaal uitvoert?
Het is verstandig dit te verifiëren in plaats van er zomaar van uit te gaan. Let op SOC 2 Type II-, HIPAA- en GDPR-dekking met gepubliceerde verklaringen (die van TrueFoundry staan op trust.truefoundry.com), een gedocumenteerd schema voor toegangsbeoordeling, jaarlijkse penetratietests met bijgehouden herstelmaatregelen, en een korte, openbaar gemaakte lijst van subverwerkers.
Gerelateerde artikelen
- Multi-agent A2A governance en de agent gateway: agent-identiteit, token exchange en delegatie
- MCP Gateway, Cross-App Access en door identiteit beheerde agent-toegang: MCP-specifieke identiteit via Okta en Entra
- Enterprise AI-beveiliging met MCP Gateway runtime guardrails: handhaving van guardrails voor MCP-tool-aanroepen
- Tools voor het detecteren van schaduw-AI: het opsporen van AI-gebruik dat u niet heeft goedgekeurd
- AI-audit-checklist: het vormgeven van het audit-onderdeel uit dit artikel
Conclusie
Een AI-gateway is het evalueren waard op basis van drie vragen: kan het elk type AI-verkeer zien en beheren, biedt het u daadwerkelijke controle zodra dat verkeer zichtbaar is, en past het binnen de stack die u al heeft opgebouwd?
Als u dit vraagstuk binnen uw eigen organisatie doorloopt, bekijk dan hoe de AI Gateway van TrueFoundry het volledige plaatje aanpakt.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.















.png)

.webp)



.webp)








.webp)





