On 16 June 2026 Cloud Security Alliance Labs published a research note about LiteLLM, a popular open-source AI gateway proxy that reportedly has 95 million monthly PyPI downloads. The researchers describe a chain of critical vulnerabilities, including a pre-auth SQL injection with CVSS 9.3, through which all API keys and provider credentials stored in the PostgreSQL backend could be read remotely. The advice is clear: treat all model and cloud keys stored in LiteLLM as compromised, rotate them, and where possible use runtime injection via external secrets managers rather than persistent storage in the gateway database.
This case is more than an isolated bug. A gateway intended precisely to manage model API keys centrally turns out to be a high-value attack vector itself. As a result, secrets management in AI workflows shifts from a detail within "secure coding" to a primary security layer. Anyone building central gateways, IDE plugins or agents with broad credentials creates a single point of failure for all connected models and systems.
Why secrets in AI infrastructure are a systemic risk
The LiteLLM note does not stand alone. On 21 June 2026 Cloud Security Alliance Labs described in a second research note how a malicious or vulnerable IDE plugin could read AI API keys from editor configuration and pass them on. The reasoning is the same as with the gateway: once a credential sits in plugin configuration, that plugin has direct read rights to the plaintext secret. The recommendation is again to rotate all AI keys configured in development tools, migrate them to vault-based secrets managers and scope them strictly, with credentials fetched programmatically at runtime.
The pattern that emerges from both notes is this: persistent storage of provider API keys in AI gateways or tool configuration is a structural risk. Secrets belong in dedicated vaults, with dynamic, short-lived credentials, minimal scopes and automatic rotation.
From infrastructure to agents and workflows
That this is not a theoretical risk is shown by the incident analysis by Coasty.ai of 26 May 2026. The blog describes several concrete leaks in an AI context: a student who leaked a Gemini API key on GitHub and thereby caused a cloud bill of over 55,000 dollars, an attacker who harvested 113,000 DeepSeek API keys from public repositories, and the Moltbook incident in which a misconfigured Supabase database exposed 1.5 million API keys. The core of the argument: developers hand credentials to AI agents and tools as though they were low-risk test data, while misconfigurations and public code sharing expose those keys directly.
The practical guide AI Agent Secrets Management Checklist (AgentSecurityAudit.com, 25 June 2026) translates this into design rules. Agents must never receive raw secrets in prompts, retrieval context, memory or logs. Secrets belong in a managed vault, are injected only at execution time and must be scoped per tool and system and rotated regularly. According to the checklist, incident response consists as standard of revoke, rotate, search, delete and regression tests aimed specifically at secret exfiltration paths.
Prompts, context, logs and retrieval indices are thus explicitly designed as no-secret zones: places where, by definition, no credentials should end up. Redaction, secret scanning and server-side credential injection become fixed patterns rather than exceptions.
Even formal secrets stores sit in the attack chain
That a vault offers no automatic guarantee is illustrated by an incident report from The Hacker News and Sysdig of 29 May 2026. After a compromise of a Marimo notebook, an attacker used an LLM agent for post-exploitation: he extracted cloud credentials from the compromised host, used those to retrieve an SSH private key via AWS Secrets Manager and then ran SSH sessions against a downstream bastion. The secrets store itself thus became part of the attack chain.
The lesson is that the existence of a formal secrets manager is not sufficient if credentials within it are scoped too broadly and stored without additional controls. Secrets management in AI workflows is emphatically also about scopes, short TTLs and verifiable usage patterns: who may request which key, when, and does that fit normal usage?
Governance and verifiability as the final piece
The sum of these sources points in one direction: secrets around AI, whether they are model API keys, cloud credentials or tokens, must be treated as short-lived, strictly scoped machine identities. They do not belong in prompts, gateways or IDE configuration, but are handed out and audited via vaults and controlled toolchains.
For professionals working with privacy-sensitive or highly confidential information, configuration hygiene is therefore not enough. Visibility is needed of which secrets flows run through AI workflows, which machine identities are used, and which scopes and TTLs go with them. Incident paths such as the Marimo agent chain must be reconstructable after the fact.
At this point the news touches on the work of a verification console such as I am Vera. Vera is not a gateway, chatbot or secrets manager, but a verification layer: the workflow is designed to anonymise documents on EU infrastructure via the Semantic Privacy Shield before content is offered to AI models, and if a privacy check fails, nothing is forwarded. In this way Vera can help prevent sensitive content, including accidentally pasted keys, from reaching a model unfiltered.
More important in the light of these incidents is the principle that making verification steps visible supports control. A console that renders AI usage, context and output transparent can help organisations demonstrate that prompts and logs function as no-secret zones and that deviant usage stands out. Vera guarantees no correctness and eliminates no risks; the professional final judgement remains with the user. But precisely after a chain such as the one around LiteLLM, the core message is unmistakable: secrets management in AI workflows must be demonstrable and auditable, not implicit.