What you would have to build to hold your users' credentials yourself

Vault·4 October 2026

"Connect your Google account" is a button. Behind the button, on every agent platform that acts for its users, is a system that captures credentials in four different forms, encrypts them, keeps them alive, hands them to an agent without letting the agent read them, lets the user take them back, and can answer an auditor's question about any of it. Nobody budgets for that system when they add the button.

This post is the inventory. If you are deciding whether to build it, it is the list to estimate against. If you are deciding whether to use Seekrit Vault, it is the list of what the five setup steps replace.

The inventory

Twelve rows. A reasonable engineer looks at any one of them and says "a sprint." The problem is that they are coupled: the revocation design depends on the write-back design, which depends on the refresh design, which depends on where the key lives. And the system is on the critical path of every action the agent takes for every user, so it has to work before the agent does.

The row that decides the others: where does the key live?

Every design decision in the table follows from one choice. If the key that decrypts your users' credentials lives on your application servers, then your database is a credential store, your backend is in the plaintext path, and every other row is about hardening a system that holds the thing. If the key lives somewhere your backend cannot reach, most rows get simpler and the guarantee you can offer users gets stronger.

Vault puts it in an executor: a small Worker you deploy into your own Cloudflare account from a template. The private key is generated inside its Durable Object and never exported. Seekrit holds ciphertext it cannot open. Your backend holds a platform key that can open connect links and read metadata but cannot release a credential. The trust model walks through why a breach of either side — or both — comes up short.

The five-step version

Vault's design target was a platform's first credential working in under fifteen minutes, in at most five steps, with three environment variables on the backend. Here is what that looks like against the table above.

1. Dashboard → Vault → New project, then copy the skv_… platform key.
2. Deploy the executor and declare your providers:

npx @seekrit/vault-executor init my-vault-executor
cd my-vault-executor && npm install
npx wrangler secret put EXECUTOR_TOKEN        # any long random string
npx wrangler secret put GOOGLE_CLIENT_SECRET  # one per OAuth provider, if any
npx wrangler deploy

3. Register it with a one-time code from the dashboard:

npx @seekrit/vault-executor register <code> --url https://my-vault-executor.<you>.workers.dev

4. Three variables on your backend: SEEKRIT_VAULT_KEY, VAULT_EXECUTOR_URL, VAULT_EXECUTOR_TOKEN.
5. Code:

import { Vault } from "@seekrit/sdk/vault";

const vault = new Vault();

const link = await vault.connect.create({ userRef: "u_123", providerId: "google-gmail" });
// text link.url to the user; vault.connect.get(link.id) or a webhook tells you when it completes

const res = await vault.fetch({
  userRef: "u_123",
  connectionId,
  request: { method: "GET", url: "https://gmail.googleapis.com/gmail/v1/users/me/labels" },
});

You need a Cloudflare account on the Workers Paid plan (the executor uses Durable Objects) and a seekrit organization with Vault on its plan; the unit is active connections. npx @seekrit/vault-executor status --url … tells you whether the executor is up, registered, and missing any OAuth secret.

What you still own

Buying custody does not buy the product. You still own:

• The agent and its tools. Vault is custody, not usage. There is no send_email; your agent's Gmail tool makes the request and Vault makes it authenticated.
• Your OAuth clients and their verification with each provider.
• Your browsers, if you use browser sessions: Browser Run in your account, on your plan.
• The decision of what to connect. Keep provider rules narrow; the executor enforces hosts, methods and paths, and cannot judge intent.
• What you tell your users. The Connect page says neither you nor seekrit can read their credentials; the trust model is the page to point them at for why.

That is a shorter list than the table, and every item on it is something only you could own anyway.

The guide has every step above in detail; the API reference has the three surfaces and which credential opens each.