Op 16 juni 2026 publiceerde Cloud Security Alliance Labs een research note over LiteLLM, een populaire open-source AI-gateway-proxy met naar eigen zeggen 95 miljoen maandelijkse PyPI-downloads. De onderzoekers beschrijven een keten van kritieke kwetsbaarheden, waaronder een pre-auth SQL-injectie met CVSS 9,3, waarmee alle in de PostgreSQL-backend opgeslagen API-sleutels en provider-credentials op afstand uitleesbaar waren. Het advies is helder: behandel alle in LiteLLM opgeslagen model- en cloud-keys als gecompromitteerd, roteer ze, en gebruik waar mogelijk runtime-injectie via externe secrets-managers in plaats van persistente opslag in de gatewaydatabase.
Deze casus is meer dan een losse bug. Een gateway die juist is bedoeld om model-API-sleutels centraal te beheren, blijkt zelf een hoog-waarde aanvalsvector. Daarmee verschuift secrets management in AI-workflows van een detail binnen "secure coding" naar een primaire beveiligingslaag. Wie centrale gateways, IDE-plugins of agents met brede credentials bouwt, creëert een single point of failure voor alle aangesloten modellen en systemen.
Waarom secrets in AI-infrastructuur een systeemrisico zijn
De LiteLLM-note staat niet op zichzelf. Op 21 juni 2026 beschreef Cloud Security Alliance Labs in een tweede research note hoe een kwaadaardige of kwetsbare IDE-plugin AI-API-sleutels uit editorconfiguratie kon lezen en doorgeven. De redenering is dezelfde als bij de gateway: zodra een credential in pluginconfiguratie staat, heeft die plugin directe leesrechten op de plaintext-secret. De aanbeveling is opnieuw om alle in ontwikkeltools geconfigureerde AI-sleutels te roteren, te migreren naar vault-gebaseerde secrets-managers en strikt te scopen, met credentials die programmatisch op runtime worden opgehaald.
Het patroon dat uit beide notes naar voren komt: persistente opslag van provider-API-keys in AI-gateways of toolconfiguratie is een structureel risico. Secrets horen thuis in dedicated vaults, met dynamische, kort-levende credentials, minimale scopes en automatische rotatie.
Van infrastructuur naar agents en workflows
Dat het geen theoretisch risico is, laat de incidentanalyse van Coasty.ai van 26 mei 2026 zien. Het blog beschrijft meerdere concrete lekken in AI-context: een student die een Gemini-API-key op GitHub lekte en zo een cloud-rekening van ruim 55.000 dollar veroorzaakte, een aanvaller die 113.000 DeepSeek-API-sleutels uit publieke repositories oogstte, en het Moltbook-incident waarbij een misgeconfigureerde Supabase-database 1,5 miljoen API-keys blootlegde. De kern van het betoog: ontwikkelaars reiken credentials aan AI-agents en tools uit alsof het low-risk testdata zijn, terwijl misconfiguraties en publieke code-deling die keys direct blootstellen.
De praktijkgids AI Agent Secrets Management Checklist (AgentSecurityAudit.com, 25 juni 2026) vertaalt dit naar ontwerpregels. Agents mogen nooit ruwe secrets in prompts, retrieval-context, memory of logs ontvangen. Secrets horen in een managed vault, worden alleen op executietijd geïnjecteerd en moeten per tool en systeem gescopeerd en regelmatig geroteerd worden. Incidentrespons bestaat volgens de checklist standaard uit revoke, rotate, search, delete en regressietesten die specifiek gericht zijn op secret-exfiltratiepaden.
Prompts, context, logs en retrieval-indices worden zo expliciet ontworpen als no-secret zones: plekken waar per definitie geen credentials terecht mogen komen. Redactie, secret-scanning en server-side credential-injectie worden vaste patronen in plaats van uitzonderingen.
Zelfs formele secrets-stores staan in de aanvalsketen
Dat een vault geen automatische garantie biedt, illustreert een incidentrapport van The Hacker News en Sysdig van 29 mei 2026. Na een compromis van een Marimo-notebook gebruikte een aanvaller een LLM-agent voor post-exploitation: hij extraheerde cloud-credentials uit de gecompromitteerde host, gebruikte die om via AWS Secrets Manager een SSH-private key op te halen en voerde vervolgens SSH-sessies uit tegen een downstream-bastion. De secrets-store zelf werd zo onderdeel van de aanvalsketen.
De les is dat het bestaan van een formele secrets-manager niet volstaat als credentials daarin te ruim gescopeerd en zonder extra controles zijn opgeslagen. Secrets management in AI-workflows gaat nadrukkelijk óók over scopes, korte TTL's en verifieerbare gebruikspatronen: wie mag welke sleutel opvragen, wanneer, en past dat bij normaal gebruik?
Governance en verifieerbaarheid als sluitstuk
De optelsom van deze bronnen wijst in één richting: secrets rond AI, of het nu model-API-keys, cloud-credentials of tokens zijn, moeten worden behandeld als kort-levende, streng gescopeerde machine-identiteiten. Ze horen niet in prompts, gateways of IDE-configuratie, maar worden via vaults en gecontroleerde toolchains uitgedeeld en geaudit.
Voor professionals die met privacygevoelige of hoog-vertrouwelijke informatie werken, is configuratie-hygiëne daarmee niet genoeg. Er is zicht nodig op welke secrets-stromen door AI-workflows lopen, welke machine-identiteiten worden gebruikt, en welke scopes en TTL's daarbij horen. Incidentpaden zoals de Marimo-agentketen moeten achteraf reconstrueerbaar zijn.
Op dat punt raakt het nieuws aan het werk van een verificatieconsole als I am Vera. Vera is geen gateway, chatbot of secrets-manager, maar een verificatielaag: de workflow is ontworpen om documenten op EU-infrastructuur te anonimiseren via de Semantic Privacy Shield voordat inhoud aan AI-modellen wordt aangeboden, en bij een mislukte privacycontrole wordt niets doorgestuurd. Zo kan Vera helpen voorkomen dat gevoelige inhoud, waaronder per ongeluk geplakte sleutels, ongefilterd bij een model belandt.
Belangrijker in het licht van deze incidenten is het principe dat het zichtbaar maken van verificatiestappen ondersteunt bij controle. Een console die AI-gebruik, context en output inzichtelijk maakt, kan organisaties helpen aantonen dat prompts en logs als no-secret zones functioneren en dat afwijkend gebruik opvalt. Vera garandeert geen correctheid en elimineert geen risico's; het professionele eindoordeel blijft bij de gebruiker. Maar juist na een keten als die rond LiteLLM is de kernboodschap onmiskenbaar: secrets management in AI-workflows moet aantoonbaar en auditeerbaar zijn, niet impliciet.