Your coding agent can build your whole app — except sign up for the services it needs
AI writes most of my code now. The agent builds the integration, the migration, the test — I stay on product decisions. But every new dependency still breaks the flow the exact same way: the agent writes the integration in thirty seconds, then stops and says:
Add yourRESEND_API_KEYto.env.
So I alt-tab out of the editor, find the dashboard, sign up, click through onboarding, verify an email, create a key, paste it into .env— and now there’s a live secret sitting in plaintext that I have to remember not to commit, that the agent forgets about and asks me for again next session. Every service. Every project.
It’s the last manual chore in AI-assisted coding, and it’s the one thing the agent couldn’t do for me. So I built the thing that does it.
What it does
You ask once: “sign me up for Clerk and wire the Backend API in.” Your coding agent (Claude Code, Cursor, Codex, Goose) drives a scoped browser that signs up for the service, handles the email verification, captures the API key, and sends it directly to an encrypted vault.
For a reviewed service flow, that removes the dashboard handoff from the coding loop. The public service catalog starts with five evidence-checked examples; the larger active registry inventory is published separately and expands only after each flow passes review.
I tried OpenAI’s Operator and browser-use for this first. They can drive a browser, but they’re general-purpose bots built to be watched, and they often stall at a signup wall, bot check, or API-key handoff. Those steps are the task. The insight that made this work: the coding agent you already have is a great planner; what it’s missing is a driver — a scoped browser and a safe place to put what it finds.
Where the key goes (the part I actually care about)
Getting the key is the easy half. The interesting question is where it lands — because the default answer, a .env file, is genuinely bad and everyone reading this has felt it. .envfiles get committed to GitHub. They get lost. They get pasted into three services and rotated in none of them. And in the AI-coding era there’s a new worst case: the key ends up in the agent’s context window, the single least contained place a secret can be.
So the design principle is: the raw secret is never handed back to the agent, and never lands in your repo.
- The vault is write-only.The key goes straight in; the agent can’t read it back out. There’s deliberately no “give me the plaintext” API — if you want the value for a
.env, you read it from the web vault yourself. - When your code needs the key, it doesn’t get the value — it calls through a proxy. You write
${SECRET}in the request; the proxy injects the real key server-side and returns only the response. The secret goes to the provider, never to you. - For a deployed app you mint an egress grant: a scoped, rate-limited, instantly-revocable token. The app holds that, not the real key. So the vault becomes a control plane — rotate once and every grant picks it up; something leaks, you revoke the grant and the next call fails closed. No re-rotation scramble.
The piece I’m quietly proud of is multi-console setup — wiring up Google OAuth, say, where you create a client in the GCP console and paste its secret into a differentconsole. The driver captures the secret in console A, seals it in-session (a handle, not the value), and types it into console B — and the plaintext never materializes in the agent’s context or the chat transcript at any point.
Getting past the signup gates
Modern signup forms are aggressively bot-gated now (Cloudflare Turnstile, Clerk, DataDome) — which is exactly where the general-purpose browser agents stall. Getting reliably through those gates, headless and unattended, was most of the actual engineering. It’s handled behind the scenes; if you enjoy anti-bot debugging war-stories, the repo’s STATE.md is a graveyard of every hypothesis I falsified getting there.
It gets faster the more it’s used
The first successful signup for a given service gets distilled into a replayable recipe and shared. The next time anyone provisions that service, it replays in about thirty seconds instead of the agent re-figuring the flow from scratch. A chore-removal tool that gets faster with use is a nice property to have.
What’s still hard (because it is)
I’d rather tell you the edges than let you find them:
- It works best with OAuth signups (Google/GitHub) — most of the modern SaaS I reach for, but not all of it.
- Some services still win — the heaviest captcha stacks, phone-verification gates, the most aggressive anti-bot dashboards. When manual signup is genuinely the realistic call, I try to say so.
- Single-use magic links are a race, and datacenter-IP session invalidation is an ongoing operational reality.
It’s beta, and free during the beta.
Try it
Trusty Squire is an open-source MCP server your coding agent drives. It plugs into Claude Code, Cursor, and Codex; you can get started here, or read the code on GitHub. Would love feedback — especially on the secret model.