The Time I Leaked My Own Password

Welcome back. This issue comes to you from the packing stage: I’m preparing to leave for someplace warm, where I will be conducting serious field research into palm trees, relaxation, and the ancient art of being unplugged. The projects are riding in the backseat for the next couple weeks while I do a bit of an unplug, but I still hope to bring you the weekly newsletter right on schedule.

And that makes this the perfect week for something overdue. This newsletter is called Wundervault Weekly. It lives at wundervault.com. And in twelve issues I have never once properly explained what Wundervault actually is. You’ve seen the name on the masthead every Saturday. Today you get the story. And like most good stories about security products, it starts with me doing something dumb.

March on the left, July on the right. The rest of this issue is how we got from one to the other.

Step one: leak your own password

Earlier this year I was deep in OpenClaw, the agent framework longtime readers met all the way back in our very first issue, Exploration and the 21st Century. I wanted my agent to do real work: call APIs, log into accounts, actually touch the systems I use every day. And real work needs real credentials. So I did the obvious thing. I pasted a password into the chat.

It worked, by the way. The agent logged in and did the job. It took about a minute for the second realization to land: that chat was Telegram, which means my credential was now sitting on someone else’s server. It was also in the conversation history that gets sent to the model provider on every single turn, and in whatever logs live in between. I hadn’t shared a password with my assistant. I had published it, quietly, to a small crowd of computers I don’t control.

◆  Rule №1  ·  learned the hard way Anything you paste into an AI chat should be treated as copied to machines you don’t control. The chat window is not a safe place for secrets. It is the least safe place you use all day.

My next move was to go looking for a password-sharing site, the kind that gives you a one-time link that self-destructs after it’s read. Those exist, and there are plenty of them, but most were built a decade ago, in an era when the thing on the other end of the link was always a human with a browser. My reader wasn’t a human. It was an agent, and those interfaces simply weren’t built for it.

And that’s when I got the feeling every builder chases: a brand-new problem, created by a brand-new technology, with the same technology sitting right there volunteering to fix it. The tool that caused my leak got hired to clean it up. A few evenings later I had the earliest version of Wundervault, back then called Burnbox: a one-time secret sharing site that my agent could actually use. Encrypted, burns on read, nothing stored after. It worked. Well. It mostly worked, and the word “mostly” is about to do a lot of heavy lifting.

The robot did not follow the rules

Here is what I learned next, and if you build anything with AI you will learn it too: these systems are non-deterministic. Ask the same model the same thing twice and you can get two different answers. That’s not a bug you file, it’s how the technology works. And the sibling problem is worse: an AI does not always follow the rules you put in front of it. My burn instructions were clear. Retrieve the secret, use it, never repeat it, never store it. Most of the time the agent obeyed. Some of the time it happily echoed the secret right back into the chat, which put me exactly where I started, minus several evenings.

So my retrieval mechanism had created a new problem: the retriever didn’t listen. These are ongoing, permanent realities of building for AI. You don’t fix non-determinism with a sternly worded prompt. You design around it, and the way I designed around it was with something called an MCP server.

MCP stands for Model Context Protocol, and it is the closest thing agents have to a universal wall socket. Instead of the agent visiting a website and improvising like a very confident intern, it calls a named tool with defined inputs and defined outputs. The part that matters for security: the tool itself is real code running on a server, and real code is deterministic. It does the same thing every time. So the trick is to wrap the unpredictable model in predictable machinery, and to make sure the dangerous part happens inside the machinery, where the model can’t improvise.

In Wundervault that means the secret never enters the chat at all. When my agent needs to deploy something, it doesn’t ask for the API key. It asks the vault to run the command, and the vault decrypts the key, injects it directly into that process, wipes it from memory the moment the process starts, and hands the agent back only the result. The agent gets the outcome without ever seeing the credential. It cannot leak what it never saw, and no amount of non-determinism can change that.

Trust me, I can’t read it

Turning a weekend one-time-link site into that vault meant growing up fast. Accounts, so an agent can have long-term access instead of a single burn. Long-term storage, so your secrets are there next week. And the moment you store other people’s credentials for the long term, you inherit a very reasonable question: why on earth would I trust you?

The honest answer is that you shouldn’t have to, which is why Wundervault is built zero-knowledge. The plain version: your secret is encrypted on your device, with a key derived from a passphrase that never leaves you, before anything is sent to us. What lands on our server is ciphertext, which is a polite word for gibberish. We store gibberish, we back up gibberish, and if someone ever stole our entire database they would be the proud owner of gibberish. We could not read your secrets if we were curious, compromised, or ordered to. The server isn’t trusted, it’s blind.

◆  Zero-knowledge, in one line We rent you the safe-deposit box, but there is no master key. You hold the only one. That is not a policy promise, it’s math.

Wundervault today

So that’s what Wundervault grew into: an MCP secret vault that gives AI agents production access without exposing the secrets themselves. The one-time burn-on-read sharing that started it all is still there, free, no account needed. On top of it sits the vault: agents get scoped, audited access, secrets are injected into commands instead of pasted into chats, and risky actions can be gated behind an explicit human approval before they run. Every retrieval lands in a tamper-evident audit log.

I want to be honest about what this has taken, because the animation below makes it look breezy. This is an ongoing development project and it has been a lot of work: security hardening passes, an interface redesign, audit logging, approval flows, onboarding rewrites, and a steady stream of fixes that nobody will ever notice because that’s the point of fixes. It gets worked on most weeks, and it will keep getting worked on. Four months of that looks like this:

Four months of evolution on one loop. Every version was built the way regular readers would expect: by describing it to an AI and iterating.

Here is everywhere Wundervault lives right now, each one updated and maintained as the project moves:

wundervault.com  ·  the vault, the free one-time sharing, the docs, and this newsletter. The quickstart gets an agent set up with one command.

npm  ·  the @wundervault/mcp-server package, the piece your agent actually talks to, plus a companion context package.

MCP Registry  ·  listed in the official Model Context Protocol registry, the directory agent platforms check first.

Smithery & Glama  ·  the community MCP directories where people go browsing for agent tools.

GitHub  ·  the MCP server is open source under AGPL-3.0, so you can read exactly what touches your secrets and run it yourself. Trust through source code, not vibes.

◆  One small favor The hope is that this tool one day earns wide adoption, and that spreads one reader at a time. If you know someone experimenting with AI agents, send them this issue and tell them to try it before they paste a password into a chat window. Ideally about five minutes before.

Below the fold this week: why my benchmark faith in MiniMax is cracking, an honest explainer on distillation and how the Chinese open-weight labs use it, and a brand-new American player called Inkling that showed up three days ago.

Until next week,

◆  Below the fold  ◆

A benchmark that flattered, a shortcut called distillation, and the ex-OpenAI CTO who just put real weights on the table.

My benchmark faith is cracking

Now for the part of the week where I air a grievance. Longtime readers know I run a stable of models and pick per job, a philosophy I laid out in last week’s issue. One member of that stable has been MiniMax, an open-weight model from a Chinese lab that I use for agentic grunt work across OpenClaw and Hermes. On paper it was a steal: benchmark scores flirting with the frontier at a fraction of the price. After months of real usage, I’m losing faith. The day-to-day work is clearly not what the leaderboards promised. The gap between the benchmark story and the Tuesday-afternoon story is wide enough to park a truck in, and I don’t think my truck is the only one parked there.

To understand why that gap exists, you need one concept: distillation. Factually, it works like this. You take a big, expensive “teacher” model, generate huge piles of its questions-and-answers, and train a smaller, cheaper “student” model to imitate those outputs. Done honestly, it’s a legitimate and genuinely useful technique; every major lab distills its own big models into its own small ones. The controversy is about whose teacher you imitate. Chinese open-weight labs have leaned on distillation hard, and openly: DeepSeek, for example, shipped versions of its R1 reasoning model distilled into other base models. OpenAI has publicly accused DeepSeek of training on ChatGPT outputs against its terms of service, and frontier labs have since tightened access over exactly this concern. None of that is a courtroom verdict, and to be fair, these labs have shipped real engineering innovation of their own. But synthetic teacher data from someone else’s frontier model is a load-bearing ingredient in a lot of open-weight releases.

Here’s the downside of that approach, and it maps exactly onto my experience. A distilled student learns the teacher’s answers, not the teacher’s understanding. That produces models that are phenomenal at looking like the teacher on familiar, benchmark-shaped questions and noticeably more brittle on the messy, off-script, forty-step agentic work where nobody wrote the answer key. The student’s ceiling is the teacher, minus translation loss. Which is precisely the shape of my complaint: great on the test, wobbly on the job. The benchmarks weren’t lying, exactly. They were measuring the one thing the model was optimized to be good at: the benchmark.

A new player: Thinking Machines

Which is why a release from three days ago has my attention. Thinking Machines Lab was founded by Mira Murati, OpenAI’s former CTO, who left and raised a two billion dollar seed round before shipping a single product, which at the time looked either absurd or extremely confident. On July 15 we found out which: they released Inkling, their first model, and it’s open weight.

Quick decoder, since I’ve been throwing this term around all issue. A model’s weights are the billions of learned numbers that make it work. An open-weight model publishes those numbers so anyone can download the model, run it on their own hardware, and fine-tune it for their own needs, instead of renting it through somebody’s API. It’s not the same as fully open source, since the training data and code stay private, but it means the model is genuinely yours to run. Until now the open-weight shelf has been stocked overwhelmingly by the Chinese labs I just spent three paragraphs side-eyeing. Inkling is a serious US-built alternative on that shelf.

thinkingmachines.ai this week: a very quiet homepage for a very loud release.

The claim I wanted to check: is this really a from-scratch model, not a distillation? Mostly yes, with one honest asterisk. Inkling was pre-trained from scratch, a mixture-of-experts design with 975 billion total parameters, about 41 billion active per task, trained on 45 trillion tokens of text, image, audio, and video. No teacher model. The asterisk: for the post-training polish, they did use outputs from other open-weight models, including Moonshot’s Kimi K2.5, to bootstrap early data, and they say the next model will be fully self-contained. I find the asterisk oddly reassuring. They disclosed it themselves, in public, unprompted, which is more transparency than this corner of the industry usually manages. They’re equally upfront that Inkling is not the strongest model you can get, open or closed. The pitch is a well-rounded model you can truly customize, not a leaderboard crown.

I haven’t run it yet. There’s a palm tree with my name on it and I intend to honor that commitment. But an open-weight option that earns its benchmark scores from scratch instead of inheriting them is exactly the thing my MiniMax experience has been begging for, and when I’m back at a real keyboard, Inkling gets a tryout in the stable.

That’s the week. Same time next Saturday, hopefully with sand in fewer of my devices.

“Begin at the beginning,” the King said, very gravely, “and go on till you come to the end: then stop.”
— Alice in Wonderland