A database your agent cannot destroy

The shape of the request has changedCopy Anchor Link

A year ago the first thing a new project needed from us was a dashboard: sign up, click create, copy the connection string. Increasingly the first thing it needs is a URL that a coding agent can fetch. The person is still there, but they are one step removed. They pasted a prompt into Claude Code or Cursor and said "set up a database for this", and now the agent is the one reading our site.

That agent needs three things from a database provider. A way to find out what the product is. A way to act on the account. And a way to hand the person back something that works. We publish all three, and this post is about why it turned out to be easy.

Why it was easyCopy Anchor Link

Because there is nothing new for the agent to learn.

A CapyDB project is a database cell: plain Postgres behind a plain postgres:// URL. There is no proprietary data API, no SDK, no dialect. An agent that knows how to write a migration for Postgres, or wire up Drizzle, or run psql, already knows how to use a cell. Everything it has read about Postgres transfers unchanged, which is the difference between a task that works on the first attempt and one that needs three rounds of documentation lookup.

The lifecycle around the cell is a real HTTP API with a real audit trail. The MCP server and the CLI call the same control plane the dashboard calls, with the same permissions and the same audit entries. Nothing was built as an "agent surface" that behaves differently from the human one.

One prompt, one approvalCopy Anchor Link

The bootstrap prompt on the home page is three lines:

Set up a CapyDB Postgres database for this project.
Fetch https://capydb.dev/agents.md and follow the instructions for your environment.
You'll need me once: to approve access in a browser tab. Everything else is yours.

It deliberately contains no instructions of its own. The real runbook lives at capydb.dev/agents.md, versioned with the product, so the steps the agent follows are always current and a prompt copied months ago does not rot. The runbook routes by what the agent can actually do:

• A shell (Claude Code, Cursor, Copilot CLI): install the CLI and run capydb create --yes --output json. That one command authenticates, creates the project, waits for the cell, links the directory, and writes DATABASE_URL into a gitignored env file.
• MCP but no shell: add @capydb/mcp. The first tool call returns a browser approval link; after that the tool surface does the rest.
• A WebMCP-capable browser looking at the dashboard: no setup at all. The page registers tools on the session the person is already signed in with.
• A chat window and nothing else: a guided path that walks the person through sign-up and key creation, and generates the wiring code for their framework.

In every path the person appears exactly once, in a browser tab, to approve access. Identity and money stay human: the agent never creates the account, never sees a checkout form, never handles a card. The key minted by that approval covers the whole organization, expires after 90 days, and shows up under API keys labelled "AI agent" so it can be revoked the moment a run goes wrong.

The full walkthrough is in Set up with an AI assistant.

No account at allCopy Anchor Link

Sometimes the agent should not stop to ask for an account. It is exploring an idea, running a test suite, reproducing a bug. For that the MCP server exposes create_ephemeral_database, which needs no login: a real cell with its own credentials, TLS, and both connection strings, destroyed after 72 hours unless someone claims it.

If the work turns out to be worth keeping, the agent hands the person a claim link. Claiming moves the database into their workspace with its data intact. That is the one step that needs a human, and it is optional. Ephemeral databases has the details and the limits.

What the agent cannot doCopy Anchor Link

This is the part we care most about, and it is gated by construction rather than by prompt engineering.

Unscoped writes are refused before they run. An UPDATE or DELETE with no top-level WHERE, or a TRUNCATE, sent through the SQL API is refused in the control plane. The refusal carries the remedy (scope the rows, or rehearse against a preview), so a model can fix its own call without another round trip. The dashboard's SQL console opts out per request, and so does capydb sql --allow-unqualified-writes, because a person typing that has already expressed intent; the MCP server never does. The guard is deliberately narrow: it does not look at DROP, and it cannot see statements sent over a direct connection with psql or the DATABASE_URL. For everything riskier than that, the tool description tells the agent to take a restore point first, and the agent safety loop is the pattern: checkpoint, apply, verify, and on failure restore into a preview where the pre-change data can be inspected and repaired.

Restoring into a preview, never over production. A restore from an agent tool lands in a preview database. Overwrite restore exists as an operation, and it is deliberately not exposed as an agent tool on any surface: not in MCP, not in WebMCP, not in the runbook. The control plane refuses it outright on production projects; on a non-production project it needs an org-wide key or an org admin, plus a single-use approval token minted for that one restore. Deleting a production project needs the same kind of token, which an org-wide key can mint - so scope the agent's key to its project.

Previews carry a TTL. An experiment cannot quietly become a bill. Every preview an agent creates expires on its own.

Every action is attributed. Each call an agent makes appears in the workspace audit log under the key that made it, and that key is one revocation away from doing nothing.

None of these guardrails were added for agents. They were already the guardrails for people, because a person at 3 AM makes the same mistakes an agent makes at any hour. The agent story is the second sentence of the cell story: because the primitive is boring Postgres run well, handing it to an agent needs nothing new.

Where to startCopy Anchor Link

• Paste the prompt from the agents page into your assistant.
• Add the MCP server to an editor you already use.
• Read the safety loop before letting an agent migrate anything you care about.