TL;DR AI gateways keep credentials out of agents’ environments, but concentrate them in the service making requests on their behalf. Protecting the keys is not enough if an attacker can control that service. The gateway needs isolation from its host and a way for users to verify that it runs the code they approved.
Table of contents
A hot wallet needs access to signing keys to process withdrawals. An AI gateway needs access to provider credentials to serve requests. Both depend on software that decides when and how those secrets can be used.
On October 29, 2026, attackers took about $6.3 billion from Binance, most of it in roughly twenty minutes. It is the largest crypto theft on record, about four times Bybit’s $1.5 billion in 2025. Binance’s preliminary account points to a compromised DevOps engineer’s laptop, from which the attacker reached a service container that could submit withdrawals. Binance has since reported further points of breach, and says it has found no evidence that private keys leaked. On Ethereum, the attacker used EIP-7702 to delegate a hot wallet to its own sweeper contract. On nine other chains, TRM assesses, Binance’s own signing infrastructure produced valid signatures for the attacker.
The keys stayed safe. The system that used them did what it was asked.
We spent a decade protecting secrets with HSMs, MPC, multisig and vaults. Attackers adapted: they don’t need the key if they can reach whatever is allowed to use it. And the number of things allowed to use keys is exploding, because of how we now build software.
More agents, more access to protect
Every agent behind that code runs with something: a shell, a GitHub token, cloud credentials, a model API key. GitGuardian’s 2026 report found 28.6 million secrets leaked on public GitHub in 2025, with commits co-authored by Claude Code leaking at roughly twice the baseline rate.
The attacks have followed the agents. In August 2025, the malicious Nx packages turned developers’ own AI command-line tools into secret scanners. A month later, postmark-mcp became, per Koi Security, the first known malicious MCP server, quietly copying every email it sent. Coding agents in CI were shown to leak their tokens to anyone who could write a convincing GitHub issue. Simon Willison’s “lethal trifecta” names the structural problem: an agent with private data, untrusted input and a way to talk to the outside world can be turned against you.
None of this required a new class of exploit. It required speed. Workloads change daily, permissions are granted in a hurry so the agent can get on with its task, and every grant outlives the reason it was made.
The industry’s answer: centralize the keys
The sensible response is to take credentials away from agents and put a broker in the middle. The agent asks; the broker holds the key, checks who is asking, injects the credential, and logs what happened.
Tailscale’s Aperture, an AI gateway on your tailnet, is one of the best examples. In its own words, “API keys stay in the server configuration, never on developer devices.” Identity comes from Tailscale’s control plane rather than from the client, so an agent cannot claim to be someone else. Every request is tied to a Tailscale identity and a device, with optional per-user limits and a full log.
I like these tools. Moving long-lived keys off thousands of laptops and CI runners is a real improvement. But look at what the pattern does to the threat model. It takes every provider key, every OAuth token and, in Aperture’s case, by default, “full request and response bodies” (prompts that routinely contain source code and secrets), and concentrates them in one service. That service is now the most valuable target in the organization. Aperture runs as a hosted service managed by Tailscale, which holds the stored keys and can restore a deleted gateway from backup for seven days. Encryption at rest and in transit protects stored keys and traffic. The remaining question is how keys are protected while the gateway uses them. The weak point is the key in use, decrypted in memory on every request, and customers have no way to check who can reach it there. Hardening the proxy is entirely the operator’s job; everyone else takes it on trust.
A separate incident involving LiteLLM shows why the gateway itself needs protection. In October 2026, attackers used stolen maintainer GitHub tokens to publish a poisoned release of LiteLLM, one of the most widely used open-source AI gateways. According to StepSecurity, the stealer used the proxy’s own database client to read the tables that hold stored provider keys. The images carried a valid signature from LiteLLM’s real signing key. This was after the project had hardened its release pipeline following a compromise in March 2026. A valid signature proved who published the release, not what was in it.
A credential proxy is control. Control without proof just moves the question. Instead of “who has access to the key?”, we now ask “who has access to the proxy?” And the answer is the same as at Binance: an operator, with a laptop, under pressure to ship.
Isolate the chokepoint, prove what it runs
The chokepoint is the right idea: a signer that decides what gets signed, a gateway that decides which agent gets which key. What they lack is isolation from the people and machines around them, and a way to prove what they are running. This is what we build at Caution.
Isolation. Run the chokepoint inside a hardware enclave. On Caution today that means AWS Nitro Enclaves, with Intel TDX, AMD SEV-SNP and TPM 2.0 in active development. The enclave’s memory is unreachable from the host and the administrators of the cloud account. A compromised DevOps laptop can stop the workload. It cannot read the enclave’s memory, and if it swaps in different code, the measurements change and the new build gets no secrets.
Proof. An enclave alone is not enough: the hardware only attests to a hash, and attestation without reproducible builds is theater. Caution builds on StageX, a Linux distribution bootstrapped from a 181-byte seed, so the base image, CautionOS and the kernel rebuild bit for bit. Anyone can run caution verify from their own machine. It sends a fresh nonce to the live enclave, checks the signed attestation, rebuilds the image from the source commit and compares the measurements. If the code running is not the code that was reviewed, the check fails.
Keys bound to code, not people. With Locksmith, the key to a secret is split among a quorum of holders, and each share is released only after the enclave’s attestation is verified. Once running, the decrypted secret lives only in measured code, not in a config file someone can export.
Anchoring trust in a signing key instead fails the moment that key leaks: in June 2026, Taiko’s bridge lost about $1.7 million because its SGX check trusted an enclave signed by a key that sat in a public repository, even in debug mode. Clients that connect over STEVE, our attested channel, and pin its measurements talk to the proxy they verified, not to whatever answers on that address.
Apply this to the two cases above. A signer running as attested code enforces its policy whichever container calls it, and no operator can quietly route around it. Anton Livaja made the full case for that recently. A gateway in an enclave holds every provider key without anyone being able to read them, and its users can check, rather than hope, that it runs the version they reviewed.
An enclave will faithfully enforce a bad rule, and attestation only proves it did so as designed. It also won’t stop a hijacked agent from misusing access the policy grants it. But a policy that can’t be bypassed and can be audited beats one on a box any administrator can modify.
What this does not solve
Verification moves trust; it doesn’t remove it. Our own security assumptions are explicit. Caution does not prove your code is correct or your repository is clean. AWS Nitro is in the trusted computing base today; multi-hardware attestation, where several vendors must agree on a workload’s state, is on our roadmap and not yet shipped.
Your application must build deterministically, and requests are hidden from the host only when end-to-end encryption is on. Physical attacks on TEEs are real. The difference is that each of these is a named assumption you can inspect, instead of an operator you are asked to trust.
Make the gateway verifiable
The usual objection is that this is for mature teams guarding unusually sensitive data, and that confidential computing is hard to start with. Neither holds anymore. Every team running coding agents guards sensitive data: the credentials those agents hold are exactly what the Nx and LiteLLM attackers went after. And starting is no longer a research project: caution init, git push caution main, caution verify. Even the hardest part, making a build deterministic, is work a coding agent can now take on. When protection is this close to hand, going without it isn’t a trade-off. It’s exposure.
Agentic development will not slow down, and it shouldn’t. But every agent we add is another process that can be talked into something, and every broker in front of them is another place where one compromised laptop becomes a ten-figure loss. Trust is something we extend to people. Machines, and the chokepoints that guard them, should be verified.
Isolate the workload. Control what it can do. Prove what it runs.
