I lost €1,500 to an AI agent. So I built something about it.
The incident
A friend of mine lost €1,500 in one night because a coding agent read his .env file and leaked his OpenAI key. Bots scanned GitHub, found the key in a cached context, and drained his account before he woke up.
He revoked the key. Generated a new one. Put it back in his .env.
And moved on.
That last part is what got me.
The problem
Every solution I found had the same assumption: the key ends up in your app's memory at runtime.
Better storage, better encryption, better access control. But the key is still there. In memory. Readable. Visible to your AI coding tool, your dependencies, your logs.
The question wasn't "where do I store my keys?"
It was "how do I make sure my key never touches my code at all?"
The architecture
I spent a few weeks thinking about this.
The idea I kept coming back to: what if the key never entered the app? What if something sat between the app and the API, and injected the key at the last possible moment, just before the HTTP request left?
The app would call a local proxy instead of OpenAI directly. The proxy would hold the key, attach it to the request, and forward it. The code would never see the key. The AI tools reading the code would never see the key.
And if the key leaked somehow, it would be bound to a specific host. Unusable anywhere else.
That became Elding.
The hard parts
Building it raised harder questions than I expected.
Latency. Adding a proxy to every request means adding a hop. I had to make sure that hop was fast enough to be invisible in practice. It is, but it took work.
Trust. Asking developers to route their API traffic through a third-party proxy is a big ask. I had to think hard about what “trust” means in this context, and how to make the architecture auditable.
Dev experience. If it’s painful to set up, nobody uses it. The whole thing had to work with minimal code changes, identical in dev and prod.
elding proxy -- node app.js
import OpenAI from "openai";
import { configure } from "[@elding](/elding)/sdk";
const openai = new OpenAI(
await configure("OPENAI_API_KEY", "https://api.openai.com")
);
// the real key never enters your application
Same code. Everywhere.
What Elding does today
Local proxy for dev, cloud proxy for prod. Your key never enters your codebase. Host-lock per key, so a stolen key is useless outside its intended environment. AES-256-GCM encryption. Full audit log. Rotation without redeployment.
It works. And it took about three months to get to a state I was comfortable putting in front of other people.
Looking for beta testers
Ideally people who use Cursor, Copilot, or any AI coding tool in a project that also calls external APIs. People who have a .env file and have maybe wondered, at least once, whether that’s a problem.
It’s free. I want honest feedback more than anything else.
If that’s you: elding.app
The €1,500 in your opening had a thief attached to it, which makes it the easier of the two ways that money disappears. The same bill arrives with a key that never leaked: the agent hits a rate limit, retries, one tool call fans out into a few hundred more, and nobody notices until morning because there is no ceiling anywhere in the path. Host-locking ends the stolen-key version completely and does nothing for that one. Your proxy is the only component in the stack that sees every outbound request before it leaves, so it is the natural place to enforce a per-key spend ceiling and a requests-per-minute cap, which is a broader pitch than secret isolation alone because it also covers the boring way people lose money. Does Elding meter spend per key today, or is host-binding the only enforcement?
What I'd be careful with is that solving the original failure can sometimes make a different trust assumption become invisible.
Not because the architecture is wrong.
Because the thing users are worried about and the thing they're ultimately trusting aren't always the same thing.
That's the part I'd be most curious about here.
That’s exactly the tension we’re trying to resolve. The proxy solves the
technical problem: the key never comes into contact with the process. But you’re right: the trust assumption shifts—it doesn’t disappear. It shifts from “I trust my infrastructure” to “I trust Elding.”
That’s why we’re working on a self-hosted proxy—for those who
want to eliminate this presumption of trust entirely. What invisible presumption of trust do you perceive in this case?
I don't know that I'd trust my own answer to that from a thread alone.
What makes it interesting to me is that users can describe a trust concern one way while making adoption decisions based on something slightly different.
Those aren't always the same thing.
That's probably where I'd spend most of my attention if I were evaluating the problem.
Nice concept. I'm wondering: have you found that AI coding tools (Cursor, Claude Code, Copilot, etc.) are actually the biggest source of secret leaks today, or are Git commits and misconfigured deployments still the main issue in practice?
Git commits are still the #1 source, no question. But AI tools introduced something new: the key doesn't need to be committed to leak. It just needs to be read by a process you don't fully control. That surface didn't exist two years ago and most developers haven't updated their threat model yet.