Dossier — journal
The blast radius
In the last post I wrote that the factory is the product and that my job is to remove myself from it. What I left out is what that factory runs on: access.
An agent is only useful for what it can reach, so every week I hand mine a bit more. Right now a single Claude Code session on my Mac is wired to about thirty MCP servers: App Store Connect, npm, Cloudflare, Stripe, my object storage, my router, my cameras, my mail, my messages, my calendar. Six months ago it was a shell and a git repository.
That list is the blast radius. Anything that manages to run inside that session, a poisoned dependency, a prompt hidden in a web page, a tool description that lies, gets the same reach I gave the agent, and it gets it at agent speed. A human intruder with my laptop would need an afternoon to find the keys and figure out what they open. The agent already has them loaded, described, and typed.
And the radius only grows. Every MCP server published makes the next takeover cheaper to pull off and more expensive to suffer, because the damage scales with adoption on both axes at once: how fast it spreads and how much it touches.
This is no longer a thought experiment. In August 2025 a compromised release of nx shipped a postinstall script that looked for claude and gemini on the machine, ran whichever it found with the permission checks switched off, and handed it a prompt. The script then read what the assistant had found and pushed it to public repositories under the victim’s own GitHub account. The malware itself did almost nothing. The agent already installed, already trusted and already holding the keys did the work. The variants since have kept the idea and dropped the subtlety: the June 2026 node-gyp worm leaves hooks in .claude and .cursor directories so its payload runs again every time a developer opens the project.
The open source calculus has flipped
I have been publishing open source for more than a decade, so this is not a comfortable thing to write: pulling in a third-party library is now a worse deal than it used to be, on both sides of the ledger.
The risk went up. A dependency is code that runs as me, with every credential I just listed. Planting something clever in one is easier than ever, precisely because the same tools that write my code can write a very patient exploit, and a maintainer reviewing pull requests at agent volume will not catch it.
The upside went down. The whole point of a library was that rebuilding it was expensive. It is not anymore. I can have the twenty percent of a package I actually use rewritten in an hour (if not minutes) and know that it is safe and, more importantly, that it will stay that way. No update channel, no new maintainer, no postinstall script.
That does not mean open source is finished. The foundations (the runtime, the database driver, the crypto) are not going anywhere, and I will keep publishing. But the default of the last fifteen years, npm install whatever solves the problem, is finished. The long tail of small packages was always a trust decision dressed up as a convenience, and the trust part just got expensive.
Reputation is what is left
If code is cheap and provenance is what is scarce, then the question “who wrote this” matters more than it did, not less. Who is behind that package, that MCP server, that agent that wants to read my inbox. How long have they been around. What do they lose if they betray me.
I think human reputation is about to matter a great deal more. Not stars, not download counts, both of which an agent can farm. A name, a track record, a person you could actually hold responsible. Trust will have to be earned, and it will be earned slowly, which is the one thing that does not get faster.
Signed and notarized builds are no longer optional, they are the floor. Above that it comes down to a name: a GitHub account with more than a decade of commits behind it, products sold direct under my own name rather than through a storefront that hides it, and a way to reach me that does not end in a ticket queue. A solo developer asking for Full Disk Access is asking for a lot, and I know it. What I can offer in return is one person to hold responsible, and a long record of being around.
My data, under my control
Which brings me to the part I feel most strongly about. I have never liked handing my email, my messages and my calendar to a cloud agent through some obscure OAuth flow. A standing token, held on somebody else’s server, refreshed behind my back, revocable only if I remember the dashboard it lives in. Their breach is my breach, and I would not even be the one to find out.
As a freelancer this is not only about me. My clients trust me with their most precious data, and I have to make sure that I deserve it. Handing it onward to a third party I cannot audit is not a trade I get to make on their behalf.
So my rule is simple: the data stays on my machine, the permissions stay mine, and the model sees what a tool call returns, not the store it came from.
The model provider is still a third party, and I am not pretending otherwise: whatever a tool call returns, the model reads. The difference is that I can see exactly what the agent accessed, call by call, and that the access has an off switch. Nothing is delegated to a token I cannot see being used. When the MCP servers are off, the access is off, and there is no standing grant left behind on somebody else’s server waiting for the next request.
This is why I built Bastion and Cupertino
Neither of these started as a product. They started as the two problems above showing up on my own machine.
Bastion exists because every one of my MCP servers kept its credentials in a plaintext config file beside the code, readable by anything running as me and one careless git add away from being public. Bastion runs each server once for every client on the Mac, keeps the credentials in the Keychain, gates writes per profile, and records every tool call. For remote servers it runs the OAuth dance once and no client ever sees the token. Nothing arriving over the wire can name a package, a path or an argument.
Cupertino exists because I wanted an agent in my Apple apps without giving anyone a key to them. It is a set of MCP servers for Mail, Notes, Reminders, Calendar, Contacts, Messages and Safari, behind one Full Disk Access grant held by a single signed app rather than by four editors. Writes are off by default, and off means the mutating tools are not even registered, so an agent cannot see that they exist. The surfaces that reach the furthest (the screen, the keyboard) arrive switched off entirely.
Source for both is public. What is sold is the build, signed and notarized, under my own name. That last part is not a detail. It is the whole argument of this post.