MCP Security Risks & Best Practices in 2026

Toen Anthropic eind 2024 het Model Context Protocol uitbracht, losgekoppeld van een echt probleem. In plaats van voor elke tool die een AI agent moest gebruiken aangepaste integratiecode te schrijven, konden teams agents via een gestandaardiseerde interface verbinden met databases, API's en interne systemen. De adoptie verloopt snel. Tegen 2025 waren er tienduizenden MCP servers ingezet in enterprise-omgevingen.

Maar de snelheid van de adoptie legde een gat bloot waarop de meeste organisaties niet waren voorbereid. MCP werd ontworpen om AI agents bekwamer te maken. Het was niet ontworpen met enterprise security als eerste principe. De oorspronkelijke specificatie werd geleverd zonder een verplicht authenticatieframework. Het impliciete vertrouwensmodel ging ervan uit dat MCP servers goedaardig waren. En de tools die deze servers beschikbaar stelden, werden behandeld als de output van goed werkende systemen, niet als een nieuw aanvalsoppervlak.

Beveiligingsonderzoekers documenteerden de gevolgen al snel. CVE-2025-49596, met een CVSS-score van 9.4, toonde aan dat niet-geauthenticeerde MCP Inspector-instances konden worden misbruikt om willekeurige commando's uit te voeren. Invariant Labs demonstreerde dat een kwaadwillende MCP server geruisloos een volledige WhatsApp-berichtengeschiedenis kon exfiltreren. Het Supabase Cursor agent-incident in juni 2025 liet zien hoe een bevoorrechte agent die door gebruikers ingediende supporttickets verwerkte, kon worden misleid om integratietokens te lekken via prompt injection.

Dit zijn geen grensgevallen van slecht gebouwde experimenten. Ze vonden plaats in echte productiesystemen omdat de architectuur van MCP aanvalsoppervlakken creëert die traditionele beveiligingstools niet konden zien. 

Dit artikel behandelt de specifieke MCP security risks waarmee enterprises worden geconfronteerd, de maatregelen die deze aanpakken, en waarom de methode die u gebruikt om die maatregelen af te dwingen evenveel uitmaakt als de maatregelen zelf.

Uw AI agents hebben toegang tot alles, geldt dat ook voor uw beveiliging?

TrueFoundry dwingt identiteitsbewuste uitvoering en granulaire RBAC af binnen uw private cloudomgeving.

Demo boeken

De top 5 MCP Security Risks voor enterprises

Dit zijn de vijf MCP security risks die het meest voorkomen bij MCP-implementaties.

Toegang met te veel rechten (Over-Privileged Agent Access)

Wanneer een ontwikkelaar een AI agent voor het eerst verbindt met enterprise-systemen, grijpt deze doorgaans naar de inloggegevens waarover hij al beschikt, vaak API keys op beheerdersniveau of service accounts met brede rechten. Dat is omdat ze willen dat de agent werkt zonder autorisatiefouten tegen te komen tijdens de ontwikkeling. Het probleem is dat die brede rechten zelden worden beperkt voordat de agent in productie gaat.

Het OWASP MCP Top 10-project, dat specifiek is gestart om MCP-kwetsbaarheden bij te houden, identificeert over-privileged access als een fundamenteel risico. Wanneer een klantenservice-agent dezelfde inloggegevens heeft als een databasebeheerder, stelt een enkele succesvolle aanval op die agent niet alleen een supportwachtrij bloot. Het stelt de gehele database bloot. De impact van een inbreuk schaalt rechtstreeks met de hoeveelheid toegang die de agent heeft gekregen.

Dit is geen theoretisch probleem. Bij het Supabase-incident was een agent betrokken die werd uitgevoerd met bevoorrechte service-role-toegang en invoer verwerkte die door een aanvaller gestuurde inhoud bevatte. Het privilege-niveau was precies wat de aanval mogelijk maakte. Een agent met uitsluitend leesrechten op supportgegevens zou niet de inloggegevens hebben gehad om integratietokens te exfiltreren.

Prompt Injection via externe inhoud

Prompt injection staat op nummer één in de OWASP Top 10 voor LLM Applications 2025, en het krijgt in MCP-omgevingen een ander karakter dan bij eenvoudige chatbot-implementaties. Wanneer een agent de mogelijkheid heeft om acties uit te voeren, leidt een succesvolle injectie niet alleen tot een slechte output. Het kan echte operaties in gang zetten: e-mails versturen, API's aanroepen, records wijzigen of gegevens doorsturen naar externe adressen.

Het aanvalspatroon is indirect. De aanvaller heeft geen toegang nodig tot uw systemen. Ze sluiten kwaadaardige instructies in binnen inhoud die de agent zal verwerken als onderdeel van zijn normale werk: een PDF die moet worden samengevat, een e-mail van een klant die wordt doorgestuurd, een webpagina die wordt gelezen voor onderzoek. De agent leest de inhoud, stuit op de ingesloten instructies, en omdat er in de manier waarop taalmodellen context verwerken geen harde grens bestaat tussen data en instructies, interpreteert deze die instructies als legitiem en voert ze uit.

Beveiligingsonderzoeker Simon Willison, die dit probleem sinds 2022 volgt, schreef: "The curse of prompt injection continues to be that we've known about the issue for more than two and a half years and we still don't have convincing mitigations."

De MCP-specificatie erkent het risico zelf en merkt op dat er altijd een mens in de loop moet zijn.

Tool Poisoning en de Rug Pull-aanval

MCP agents vertrouwen tool-metadata. Wanneer een agent verbinding maakt met een MCP server en de lijst met beschikbare tools opvraagt, reageert de server met toolnamen, beschrijvingen en parameterschema's. De agent gebruikt die metadata om te beslissen welke tools hij aanroept en hoe hij ze aanroept. Tool poisoning misbruikt die vertrouwensrelatie.

Bij een tool poisoning-aanval stelt een aanvaller metadata van een tool zo samen of manipuleert deze zodanig dat er verborgen instructies in staan. De toolbeschrijving lijkt bij een visuele inspectie normaal, maar bevat ingesloten richtlijnen die ervoor zorgen dat de agent schadelijke acties uitvoert, data exfiltreert en zijn eigen rechten uitbreidt. Omdat de schadelijke inhoud zich binnen de tooldefinitie bevindt in plaats van de invoer van de gebruiker, omzeilt het input-validatielagen die alleen op de gebruiker gerichte inhoud controleren.

Invariant Labs demonstreerde in 2025 een variant hiervan, waarbij werd getoond hoe een kwaadwillende MCP server in dezelfde agentcontext als een legitieme WhatsApp MCP server tool poisoning kon gebruiken om geruisloos de gehele berichtengeschiedenis van een gebruiker te lezen en te exporteren. De aanval vereiste geen gebruikersfout en geen exploit op netwerkniveau.

Een gerelateerde aanval is de rug pull, waarbij een tool zich bij de installatie legitiem gedraagt en vervolgens geruisloos zijn gedrag wijzigt nadat de gebruiker deze rechten heeft verleend. MCP servers kunnen tooldefinities bijwerken zonder de client daarvan op de hoogte te stellen, en de meeste clients signaleren of detecteren die wijzigingen niet. 

Wildgroei van inloggegevens (Credential Sprawl) over onbeheerde MCP servers

In omgevingen zonder gecentraliseerd beheer van inloggegevens onderhoudt elke MCP server zijn eigen authenticatieconfiguratie. Ontwikkelaars slaan API keys op in omgevingsvariabelen, hardcoden OAuth-tokens in configuratiebestanden en gebruiken langdurige service account-inloggegevens omdat ze gemakkelijker te beheren zijn dan kortstondige, beperkte tokens. Onderzoek dat MCP-implementaties volgde, vond 492 openbaar blootgestelde MCP servers die basisauthenticatie of versleuteling misten.

CVE-2025-6514, een kritieke OS command injection-kwetsbaarheid in mcp-remote, een OAuth-proxy met meer dan 437.000 downloads die wordt gebruikt in integraties van Cloudflare, Hugging Face en Auth0, toonde de toeleveringsketendimensie van dit risico aan. 

Een kwaadwillend MCP-eindpunt kon een speciaal geprepareerde autorisatie-URL sturen die mcp-remote rechtstreeks doorgaf aan de systeem-shell. Dit leidde tot remote code execution op de clientmachine en bood toegang tot API keys, cloud-inloggegevens, lokale bestanden en SSH-sleutels die op die machine waren opgeslagen.

Blinde vlekken in audits die compliance verstoren

Standaard MCP servers loggen de uitvoeringscontext niet in een gestructureerd, compliance-ready formaat. Ze loggen mogelijk dat een tool is aangeroepen. Ze loggen doorgaans niet afkomstig van welke menselijke gebruiker het verzoek was, wat de redenering van de agent was op het moment van de aanroep, welke data werden geretourneerd, of dat er een toegangsbeleid werd geraadpleegd voordat de operatie werd toegestaan.

Voor enterprises die werken onder SOC 2, HIPAA of GDPR is dit geen klein gat. SOC 2 vereist bewijs van beheer- en verwerkingscontroles voor data. HIPAA vereist audit trails van elke systeemtoegang tot beschermde gezondheidsinformatie, toegewezen aan een identificeerbare gebruiker of dienst. GDPR vereist de mogelijkheid om aan te tonen welke data zijn verwerkt, wanneer en door wie. Een MCP-implementatie zonder gestructureerde audit logging voldoet aan geen van deze vereisten tegelijkertijd.

Een onderzoek uit 2025 naar het gebruik van AI-systemen in enterprise-omgevingen wees uit dat minder dan 30% van de AI-systemen beschikte over gestructureerde audit trails van agent tool-toegang. Minder dan 15% kon het gehele besluitvormingstraject voor een agentactie reconstrueren.

Wanneer zich in die omgeving een beveiligingsincident voordoet, is het onderzoek afhankelijk van forensische reconstructie uit onvolledige logs. Dit voegt weken toe aan de responstijd bij incidenten en maakt het vrijwel onmogelijk om bewijsmateriaal te leveren dat gereed is voor auditors.

Essentiële MCP Security Best Practices

De bovenstaande MCP security risks delen een gemeenschappelijke rode draad: ze vloeien allemaal voort uit het ontbreken van een gecontroleerde grens tussen AI agents en de systemen waartoe ze toegang hebben. Elke best practice hieronder is ontworpen om die grens in te stellen en af te dwingen op de laag waar de aanval plaatsvindt, niet achteraf.

Dwing identiteitsbewuste uitvoering (Identity-Aware Execution) af

De belangrijkste architectonische beslissing in elke MCP-implementatie is hoe de identiteit van de AI agent wordt beheerd. Gedeelde service accounts creëren gaten in de verantwoording die met geen enkele hoeveelheid logging kunnen worden gedicht. Als vijf agents één set inloggegevens delen, is er geen manier om een specifieke actie toe te schrijven aan een specifieke agent, laat staan aan de menselijke gebruiker die het in gang heeft gezet.

De juiste aanpak is On-Behalf-Of (OBO) authenticatie, waarbij elk verzoek van een AI agent de exacte rechten draagt en uitoefent van de menselijke gebruiker die het initiatief nam. Wanneer een ontwikkelaar gegevensbronnen bevraagt via een met MCP verbonden agent, vindt de operatie plaats met het toegangsniveau van de ontwikkelaar, niet met inloggegevens op beheerdersniveau die toevallig op de server zijn geconfigureerd. De toegang wordt begrensd door wat die persoon elders in de organisatie mag doen.

Dit vereist integratie met uw enterprise identity provider, of dat nu Okta, Azure AD of een aangepaste SSO-inrichting is. Het betekent dynamische clientregistratie en autorisatiecodeflows waarbij tokens persoonsgebonden, kortstondig en automatisch vernieuwd worden, in plaats van langdurige statische sleutels die blijven bestaan totdat iemand ze handmatig intrekt.

Pas granulaire Role-Based Access Control toe op tool-niveau

Toegangsbeheer op serverniveau is te grof voor productie-MCP-implementaties. Controleren of een gebruiker of agent een MCP server kan bereiken is een uitgangspunt. Wat u daadwerkelijk nodig hebt, is de mogelijkheid om te bepalen welke specifieke tools binnen die server door elke rol kunnen worden aangeroepen.

De praktische vereiste is dit: een klantenservice-agent moet leesoperaties kunnen uitvoeren op een CRM-server, maar geen verwijderoperaties. Een financieel agent moet betalingsrecords kunnen opvragen, maar geen uitgaande overboekingen kunnen starten. Deze verschillen kunnen niet worden uitgedrukt via toegangsbeleid op serverniveau. Ze vereisen RBAC op tool-niveau, waarbij elke tool binnen een server zijn eigen autorisatie-eisen heeft en die eisen bij elke aanroep worden geëvalueerd.

De update van de MCP-specificatie uit 2026 introduceerde incrementele scope-toestemming, waardoor clients alleen de minimale toegang kunnen vragen die nodig is voor elke operatie, in plaats van vooraf alle rechten te vragen. Het implementeren hiervan vereist een autorisatielaag die de semantiek op tool-niveau begrijpt, en niet alleen netwerkniveau-routing.

Vereis menselijke goedkeuring voor onomkeerbare acties

Agents mogen geen destructieve of hoogrisico-operaties kunnen uitvoeren zonder een menselijk controlepunt. Databaseverwijderingen, externe gegevensoverdrachten, financiële transacties, bulk-recordwijzigingen en uitgaande communicatie zijn allemaal operaties waarbij een vergissing of geïnjecteerde instructie schade kan veroorzaken die moeilijk of onmogelijk te herstellen is.

De MCP-specificatie erkent dit expliciet: er moet altijd een mens in de loop zijn met de mogelijkheid om tool-aanroepen te weigeren. Het in de praktijk implementeren hiervan betekent het annoteren van MCP tools met risicoclassificaties en het afdwingen van goedkeuringsflows voor operaties die zijn gelabeld als destructief of onomkeerbaar. De agent presenteert de beoogde actie met de bijbehorende argumenten voordat deze wordt uitgevoerd, en wacht op expliciete menselijke autorisatie.

Dit is niet alleen een veiligheidsmechanisme. Het is ook een bescherming tegen prompt injection. Een geïnjecteerde instructie die niet kan worden uitgevoerd zonder menselijke goedkeuring kan niet geruisloos data exfiltreren. De goedkeuringsstap onderbreekt de aanvalsketen op de uitvoeringslaag, zelfs wanneer detectie op de invoerlaag faalt.

Consolideer tool-verbindingen in één beheerd register

Punt-tot-puntverbindingen tussen individuele agents en individuele MCP servers veroorzaken de zichtbaarheidsgaten en governance-problemen die in het risicogedeelte zijn beschreven. Wanneer elk team zijn eigen serververbindingen beheert, is er geen centrale plek om te zien welke tools er bestaan, wie er toegang toe heeft, of wat er op dit moment in productie wordt aangeroepen.

Een centraal beheerd register veranderd dit. Tools worden één keer geregistreerd. Toegangsbeleid wordt één keer gedefinieerd en consistent toegepast. Wanneer een tool wordt bijgewerkt of buiten gebruik wordt gesteld, wordt die wijziging op één plek doorgevoerd en nemen agents deze automatisch over, in plaats van te blijven bellen naar verouderde eindpunten of vast te lopen omdat ze niet op de hoogte zijn gesteld. Beveiligingsteams krijgen één inventaris in plaats van een spreadsheet waar ze altijd achteraan lopen.

Het register beperkt ook het rug pull-risico. Wanneer tooldefinities centraal worden beheerd, zijn wijzigingen in tool-metadata van versiebeheer voorzien en auditeerbaar. Een tool die na installatie geruisloos zijn eigen beschrijving aanpast is detecteerbaar omdat het register een historie bijhoudt van hoe elke tool eruitziet bij registratie vergeleken met hoe deze er nu uitziet.

Houd uitgebreide, gestructureerde audit logs bij

Elke authenticatiegebeurtenis, token-afgifte, tool-aanroep en beleidsbeslissing moet worden gelogd met gestructureerde metadata waaronder wie het verzoek deed, welke agent het uitvoerde, welke tool werd aangeroepen, welke argumenten werden doorgegeven, wat er werd geretourneerd en of een beleid van toepassing was of werd omzeild.

Het verschil tussen het hebben van logs en het hebben van compliance-ready logs is aanzienlijk. Audit logs die toolnamen en tijdstempels vastleggen, voldoen aan een smalle technische eis. Logs die gebruikersidentiteit, agentidentiteit, de volledige verzoekcontext, toegepast beleid en output-inhoud vastleggen in een gestructureerd formaat dat op verzoek kan worden opgevraagd en geëxporteerd, voldoen aan de vereisten van SOC 2, HIPAA en GDPR. Dit zijn verschillende dingen, en in het gat daartussen vinden de meeste auditfouten plaats.

Logs moeten binnen uw eigen omgeving worden bewaard. Logs die zich in een SaaS-systeem van derden bevinden, staan niet volledig onder uw controle, kunnen niet met volledige zekerheid op verzoek worden geleverd en kunnen zelf onderworpen zijn aan beperkingen voor gegevensverwerking die in strijd zijn met wat uw compliance-framework vereist.

De tekortkomingen van huidige marktoplossingen

Er is geen gebrek aan tools die worden aangeprezen als MCP security-oplossingen. De vraag is of ze MCP security-problemen aanpakken op de laag waar die beveiligingskwetsbaarheden daadwerkelijk optreden, of dat ze generieke maatregelen toepassen op een probleem dat om iets specifieker vraagt.

• Legacy API gateways kunnen de intentie van de agent niet lezen. Traditionele API gateways zijn gebouwd voor HTTP-verkeer tussen diensten. Ze inspecteren headers, dwingen rate limiting af en passen MCP-authenticatie toe op de transportlaag. Een AI agent-taak die tool-aanroepen naar 20 verschillende MCP tools triggert, genereert verkeer dat er op netwerkniveau uitziet als een reeks legitieme, geauthenticeerde verzoeken. Er is niets in de HTTP-envelope dat onthult of die verzoeken zijn gestuurd door een gebruikersactie of door een geïnjecteerde instructie die verborgen zat in een document dat de agent drie stappen eerder heeft gelezen. Gateways die de semantiek van het MCP-protocol niet kunnen analyseren, kunnen aanvalsvectors op de semantische laag tegen AI-applicaties niet detecteren of stoppen.

• Beheerde SaaS-platformen routeren uw data via infrastructuur die u niet beheert. Cloud-hosted AI-platformen lossen het implementatieprobleem op, maar creëren een data-residency-probleem. Wanneer tool-discovery van een AI agent en MCP-interacties via een cloud van derden verlopen, verlaat gevoelige informatie bij elke interactie uw netwerkgrens. Voor organisaties met data-residency-verplichtingen onder HIPAA, GDPR of in de financiële sector creëert dit blootstelling op het gebied van AI compliance, ongeacht of het beveiligingsniveau van de SaaS-leverancier zelf voldoende is. U kunt niet aan een data-residency-vereiste voldoen door te vertrouwen op de infrastructuur van iemand anders. Dit is een acuut beveiligingsprobleem voor teams die remote MCP servers uitvoeren met toegang tot gebruikersgegevens.

• Doe-het-zelf open-source configuraties lopen vast op schaal. Het bouwen van een eigen proxy met behulp van open-source componenten vermijdt kosten voor leveranciers en geeft engineeringteams maximale controle, maar het creëert onderhoudsverplichtingen die sneller groeien dan de teams die ze beheren. Toolregistratie via statische YAML- of JSON-bestanden betekent dat elke nieuwe integratie een handmatige aanpassing, een code review en een deployment vereist. RBAC-beleid geschreven in configuratiebestanden kan niet in real-time worden gewijzigd. Audit logging vereist aangepaste instrumentatie voor elke server. Als u een handvol agents beheert, is dit te overzien. Als u er tientallen beheert, wordt het een fulltime platform-engineeringprobleem.

Legacy gateways kunnen de intentie van de agent niet lezen, uw MCP security-laag moet dat wel

Krijg semantisch bewuste governance, opslag van inloggegevens en ingebouwde SOC 2-audit trails met TrueFoundry.

Demo boeken

Agent workflows beveiligen met TrueFoundry

TrueFoundry's MCP Gateway is gebouwd op het uitgangspunt dat de maatregelen die enterprises nodig hebben om MCP veilig in productie te laten draaien, niet achteraf op bestaande infrastructuur kunnen worden gemonteerd. Ze moeten onderdeel zijn van de infrastructuur.

De gateway wordt volledig geïnstalleerd binnen de AWS-, GCP- of Azure-omgeving van de klant. Elk tool-verzoek, elke discovery-call en elk prompt-response-paar blijft binnen de netwerkgrens van de organisatie. Er is geen SaaS-routinglaag of infrastructuur van derden in het datapad. Geen externe afhankelijkheid die het risico op data-egress veroorzaakt. Dit is niet alleen belangrijk voor compliance, maar ook voor het dreigingsmodel: data die uw omgeving nooit verlaat, kan onderweg niet worden onderschept.

• OAuth 2.0 identiteitsinjectie met On-Behalf-Of flows: Agents handelen onder de exacte rechten van de verzoekende gebruiker, overgenomen via de bestaande identity provider van de organisatie. Okta, Azure AD en aangepaste SSO-inrichtingen worden direct ondersteund. Er zijn geen gedeelde service accounts. Elke tool-aanroep wordt toegeschreven aan een specifieke menselijke identiteit, wat een keten van verantwoordelijkheid oplevert die elke audit doorstaat.

• Tool-niveau RBAC afgedwongen op de gateway-laag: Toegangsbeleid wordt toegepast voordat verzoeken een model of tool bereiken. Het register toont alleen de tools die elke rol of elk team mag gebruiken, niet het volledige aanvalsoppervlak van elke verbonden server. Een support-agent ziet CRM-zoektools. Deze ziet geen opdrachten voor databasebeheer. Het verschil wordt afgedwongen op platformniveau, niet door afspraken tussen ontwikkelaars.

• Virtuele MCP Server-abstractie voor bescherming van de toeleveringsketen: Backend tool-implementaties bevinden zich achter een virtuele abstractielaag in het register. Wanneer de onderliggende implementatie van een tool veranderd, of wanneer een gecompromitteerde tool moet worden vervangen, vindt de wijziging plaats in het register zonder dat dit invloed heeft op de agents die er afhankelijk van zijn. Dit beschermt agents ook tegen rug pull-aanvallen: tooldefinities worden via het register van versiebeheer voorzien, en wijzigingen in tool-metadata worden bijgehouden en zijn auditeerbaar.

• Human-in-the-loop goedkeuringsflows voor hoogrisico-operaties: Tools kunnen worden voorzien van risicoclassificaties. Operaties die zijn gelabeld als destructief of onomkeerbaar vereisen expliciete menselijke autorisatie voor uitvoering. Dit is configureerbaar per tool en per rol, zodat teams goedkeuring kunnen vereisen voor het verwijderen van databases, terwijl leesoperaties zonder onderbreking kunnen doorgaan.

• Gestructureerde audit logs bewaard binnen uw eigen omgeving: Elk verzoek wordt gelogd met volledige metadata: gebruikersidentiteit, agentidentiteit, model, tool, argumenten, respons, toegepast beleid, latentie en kosten. Logs worden bewaard in de eigen infrastructuur van de klant en kunnen in gestructureerd JSON-formaat worden geëxporteerd voor integratie met Grafana, Splunk, Datadog of een bestaande observability-pipeline. Innovaccer, dat maandelijks ongeveer 17 miljoen AI-inferentieverzoeken verwerkt onder HIPAA in AWS GovCloud, gebruikt de gestructureerde telemetrie van TrueFoundry via OpenTelemetry en bekijkt deze in Grafana, zonder dat er ooit gevoelige data hun cloudgrens verlaat.

Wilt u TrueFoundry’s AI Gateway ervaren? Boek vandaag nog een demo!

Conclusie: MCP veilig maken voor productie

MCP heeft het integratieprobleem opgelost. Het heeft het governance-probleem niet opgelost. De tienduizenden MCP servers die in 2025 in enterprise-omgevingen zijn ingezet, hebben enorm veel nieuwe mogelijkheden gecreëerd, en een even aanzienlijke uitbreiding van het aanvalsoppervlak waar de meeste organisaties niet op waren ingericht.

De incidenten die al hebben plaatsgevonden, waaronder Supabase, Asana, Atlassian en de mcp-remote CVE, werden niet veroorzaakt door slechte engineering. Ze werden veroorzaakt door een architectuur die geen rekening hield met de beveiligingseisen van enterprise-productieomgevingen. Het basisprotocol is niet gebouwd met die eisen in gedachten.

Het aanpakken van MCP security risks op een manier die daadwerkelijk werkt in productie, betekent het afdwingen van maatregelen op de infrastructuurlaag: identiteitsbewuste uitvoering, toegangsbeheer op tool-niveau, gecentraliseerd beheer van inloggegevens, menselijke goedkeuring voor destructieve operaties en gestructureerde audit logs die in uw eigen omgeving worden bewaard. Dit zijn geen optionele functies voor gereguleerde sectoren. Het zijn de basiseisen voor het draaien van AI agents die in aanraking komen met bedrijfs-kritische systemen.

TrueFoundry zorgt voor de uitrol van al die maatregelen binnen uw eigen cloud. Uw data blijft waar uw governance van toepassing is. Uw audit logs zijn van u om te genereren, te bevragen en te exporteren volgens uw eigen planning.