Your AI agent has API keys. What else has API keys?
Every other piece of software with internet access on the same host. Every process that can read the environment. Anyone who can inject instructions into the agent's input — a document, an email, a field in a form. And now, increasingly, any attacker who knows what the popular frameworks do by default — because the popular frameworks all do the same thing.
That's the threat model most production AI systems are running with right now. The AI has credentials. Something tricks the AI. The credentials leave.
How every major framework handles this
LangChain powers approximately 57% of production agent deployments. Its credential model: environment variables loaded at startup, available for the entire session. The agent has them, the tools have them, the memory has them — everything in the process can reach them. CrewAI does the same. AutoGen does the same. OpenAI's Assistants API does the same.
This isn't a bug. It's a design choice that made sense when agents were mostly demo apps and the session was a few seconds long. It made less sense as agents started running multi-hour workflows touching live financial systems. It makes even less sense now that prompt injection is a documented, weaponized attack class.
Composio — one of the larger agent tooling platforms — put it plainly in their own documentation: "If you pass an API key or a bearer token directly to the LLM, a clever prompt-injection attack could trick the agent into revealing it." They're right. And most of the industry is still doing exactly that.
Aembit did a survey of why the pattern persists. Three forces: SDK design favors long-lived credentials because it's simpler, agents need multiple LLM providers with different auth schemes so you end up with a pile of keys, and development velocity pushes teams toward "make it work" over "make it safe." All three are real. None of them are good reasons to hand an AI agent the keys to your ERP system.
What goes wrong when it does go wrong
In June 2025, Microsoft patched CVE-2025-32711 — CVSS score 9.3. The attack, called EchoLeak, targeted M365 Copilot. Attackers embedded instructions in ordinary Word documents. When Copilot read the document, it followed the instructions: exfiltrate data from OneDrive, SharePoint, and Teams. No user interaction required. Zero clicks. The documents just sat there in shared storage waiting for Copilot to open them.
Microsoft patched it server-side. But the vulnerability wasn't in the document format or the file transfer protocol. It was in the architecture: an AI agent with active credentials processing untrusted content. That combination is the attack surface. You can patch specific exploits. You can't patch the category without changing the design.
In early 2026, a misconfiguration in a widely used AI gateway project — OpenClaw, 135,000 GitHub stars — left gateway tokens exposed on 21,000 instances within two weeks of a release. This wasn't a sophisticated attack. It was a default configuration that left credentials readable. Someone checked.
GitGuardian's 2026 report found 29 million new hardcoded secrets in public repositories in 2025. AI services were up 81% year-over-year. Eight of the ten fastest-growing categories of leaked secrets were AI-related. The more consequential number: 64% of secrets leaked in 2022 are still valid today. They never got rotated.
And this is the ambient environment. Obsidian Security found that 73% of production AI deployments contain prompt injection vulnerabilities. OWASP's LLM Top 10 for 2025: Prompt Injection is still the number one risk. Sensitive Information Disclosure moved from sixth to second. The industry has been talking about these risks for two years and the deployment patterns haven't changed much.
Only 10% of organizations have a well-developed strategy for managing non-human and agentic identities. The other 90% are figuring it out as they go.
That's from Okta's survey data, surfaced by Aembit. One in ten. In a world where agents are actively being deployed against financial systems, HR databases, and customer data — one in ten organizations has thought through what those agents are allowed to touch and under what conditions.
What we do instead
The AI brain — the Claude Code SDK layer that does the actual reasoning — holds zero credentials. No API keys. No passwords. No OAuth tokens. Nothing stored, nothing in environment variables, nothing it could hand over even if it wanted to.
When the agent needs to do something — pull an invoice from Business Central, send an email, look up a vendor record — it calls a tool container. Tool containers are separate Docker containers, one per category: one for Business Central, one for email, one for web access. The agent doesn't have credentials for any of them. The tool container does, and it keeps them inside its own process.
The tool container fetches credentials per-request from Azure Key Vault. They exist in memory for one call. They're never written to disk. When the call completes, they're gone. The next call starts fresh.
Before the tool container will retrieve anything from the vault, it checks a signed HMAC token minted by the supervisor — a proof that says "this request is acting as Alice, and the supervisor authorized it." The AI brain can't forge that token. It just sends a request. The tool container decides whether to act on it.
And critically: the Business Central container can't reach the email container's credentials. Different containers, different vault access, different permission scopes. A compromised BC container is bad. But it can't pivot to email credentials, and it can't reach the bank feed, and it can't access the customer data store. The blast radius has a hard ceiling.
The accounting principle you already know
The person who approves payments doesn't have the checkbook. This is separation of duties. It's been in the accounting standards for decades. It's in the COSO framework. Every audit committee knows it.
The logic is simple: the person with authorization authority shouldn't also have execution authority. Not because they're dishonest — because if they're compromised, coerced, or mistaken, the damage is bounded. The checkbook is a separate control.
We apply the same principle architecturally. The AI agent has authorization-like capability — it decides what to do. It doesn't have execution credentials — it can't actually do it unilaterally. The tool container is the checkbook. The vault is the safe. The HMAC token is the countersignature.
This isn't a new idea. It's a very old idea applied to a new system.
The counterarguments
This adds latency. The Key Vault hop within Azure's network adds under 5 milliseconds. Agent reasoning — the part where the model is actually thinking — takes 10 to 30 seconds. The credential fetch is noise. It's not measurable in any user-facing metric.
This is overengineered for a small deployment. For a demo app, yes. For a system that touches client financial data — invoices, bank reconciliations, accounts payable — the calculation is different. One compromised agent in a naive architecture could reach every client's credentials simultaneously. The architecture cost is fixed. The exposure without it is not.
Most agents don't need this level of isolation. True. Most agents don't have access to your bank account. The trend, though, is toward agents that do more — OWASP added "Excessive Agency" as a new critical risk in their 2025 LLM Top 10 precisely because agents are gaining more action capability. The time to build the right architecture is before the agent can do real damage, not after.
The industry is starting to catch up. The OWASP Agentic AI Top 10 dropped in December 2025. The Cloud Security Alliance published its Agentic Trust Framework in February 2026, and its segmentation principle maps directly to what we're doing. NIST launched its AI Agent Standards Initiative the same month. The frameworks now exist. The deployment patterns are still catching up.
The question isn't what your AI agent can do. It's what it can do if someone tricks it.
If a malicious document, a crafted email, or a prompt injection attack gets past the model's guardrails — what's the worst case? If the answer includes "access every API key in the environment and call any system the agent is connected to," that's not a guardrails problem. That's an architecture problem.
Guardrails can be bypassed. An agent that holds no credentials cannot leak credentials it doesn't have. That's not a clever insight. It's just physics.