Secrets management voor AI-workflows wordt een primaire beveiligingslaag

U bent nu verantwoordelijk voor het aantonen dat credentials in AI-workflows niet in prompts, logs of configuratie belanden, maar via vaults met korte levensduur en strikte scopes worden verdeeld. Dit is geen detail meer — het is kernarchitectuur.

An analysis of 3 August 2026 of secrets management in AI-workflows argues that persistent storage of provider API keys in gateways and tool configuration is a structural risk that must be treated as a primary security layer. The case in point is a chain of critical vulnerabilities in a widely-used open-source AI gateway that exposed all stored model and cloud credentials via SQL injection. In our assessment, this means you can no longer treat secrets management as a coding detail — you must design it as infrastructure, with visibility into which machine identities flow through each workflow, what scopes they carry, and whether they survive longer than a single execution.

Welke aanvalsvectoren ontstaan wanneer credentials centraal worden opgeslagen?

Een gateway die juist bedoeld is om model-API-sleutels centraal te beheren, kan zelf een hoog-waarde aanvalsvector worden. Op 16 juni 2026 werd een reeks kritieke kwetsbaarheden in een populaire open-source AI-gateway gepubliceerd, 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. Dit was geen theoretisch risico: alle in de gateway opgeslagen sleutels moesten als gecompromitteerd worden behandeld.

Hetzelfde patroon verschijnt in andere tooling. Op 21 juni 2026 werd beschreven hoe een kwaadaardige of kwetsbare IDE-plugin AI-API-sleutels uit editorconfiguratie kon lezen en doorgeven. Zodra een credential in pluginconfiguratie staat, heeft die plugin directe leesrechten op de plaintext-secret. De redenering is identiek: centralisatie van secrets in een enkel systeem creëert een single point of failure voor alle aangesloten modellen en systemen.

Incidentrapporten tonen aan dat dit geen theoretische dreiging is. Een student die een Gemini-API-key op GitHub lekte, veroorzaakte een cloud-rekening van ruim 55.000 dollar. Een aanvaller oogstte 113.000 DeepSeek-API-sleutels uit publieke repositories. Een misgeconfigureerde database blootlegde 1,5 miljoen API-keys. Het patroon is consistent: 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.

Welke foutmodi moet u voorkomen?

• Plaintext secrets in prompts en context — credentials die agents of modellen in hun input ontvangen, kunnen in logs of output terechtkomen.
• Persistente opslag in gateways en IDE-configuratie — centralisatie van secrets in een enkel systeem creëert één aanvalsvector voor alle aangesloten workflows.
• Overgescoped machine-identiteiten — credentials die meer rechten dragen dan nodig voor een specifieke taak, vergroten de blast radius bij compromis.
• Secrets in retrieval-indices en memory — langdurig opgeslagen context kan gevoelige data bevatten die later wordt blootgesteld.
• Afwezigheid van automatische rotatie — credentials met lange levensduur geven aanvallers meer tijd om ze uit te buiten.
• Onvolledig incident response — revoke, rotate, search en delete moeten specifiek gericht zijn op secret-exfiltratiepaden, niet alleen op algemene containment.

Welke controles moet u kunnen aantonen?

1. Secrets worden alleen op executietijd geïnjecteerd — credentials verlaten de vault niet totdat een workflow ze daadwerkelijk nodig heeft.
2. Prompts, logs en retrieval-indices zijn aangewezen no-secret zones — redactie en server-side credential-injectie voorkomen dat secrets in deze lagen terechtkomen.
3. Elke machine-identiteit is gescopeerd per tool en systeem — credentials dragen alleen de rechten die nodig zijn voor hun specifieke doel.
4. TTL's zijn kort en automatische rotatie is actief — credentials hebben een vaste levensduur en worden regelmatig vervangen.
5. Incidentpaden zijn achteraf reconstrueerbaar — u kunt aantonen welke secrets-stromen door welke workflows liepen en wie ze opvroeg.

Wat gebeurt er als een vault zelf wordt gecompromitteerd?

Het bestaan van een formele secrets-manager biedt geen automatische garantie. Een incidentrapport van 29 mei 2026 beschrijft een aanvalsketen waarin een gecompromitteerde host werd gebruikt om cloud-credentials uit een secrets-manager op te halen, die vervolgens voor post-exploitation werden misbruikt. De secrets-store zelf werd onderdeel van de aanvalsketen.

De les is dat scopes, korte TTL's en verifieerbare gebruikspatronen niet optioneel zijn. Secrets management in AI-workflows gaat nadrukkelijk ook over wie welke sleutel mag opvragen, wanneer, en of dat past bij normaal gebruik. Een vault zonder deze controles is een versterkte deur zonder slot.

Hoe maakt u secrets management zichtbaar en auditeerbaar?

Voor professionals die met privacygevoelige of hoog-vertrouwelijke informatie werken, is configuratie-hygiëne niet genoeg. U moet zicht hebben op welke secrets-stromen door AI-workflows lopen, welke machine-identiteiten worden gebruikt, en welke scopes en TTL's daarbij horen. Incidentpaden moeten achteraf reconstrueerbaar zijn.

Tooling kan u helpen bij het afdwingen van verificatiestappen en het zichtbaar maken van AI-gebruik, context en output. Maar tooling garandeert geen correctheid en elimineert geen risico's — het professionele eindoordeel blijft bij u. Juist na een keten als die rond LiteLLM is de kernboodschap onmiskenbaar: secrets management in AI-workflows moet aantoonbaar en auditeerbaar zijn, niet impliciet. Wat u kunt automatiseren, automatiseer; wat u niet kunt automatiseren, maak zichtbaar.