Guides · Concepts
The human boundary
An agent builds everything. A few gestures need a human, because their consequence falls on someone else, or because they hand out a value that can never be taken back. This page lists them, and explains the two mechanisms behind them.
The rule#
A gesture whose effect is irreversible or reaches beyond what the call names — destroying data that cannot be rebuilt, exposing a table to everyone, handing out or withdrawing an access, redirecting every user of an app — confirms in two steps. When the consequence falls on someone other than the caller, it also requires a signed-in human: the owner of the account.
Confirming in two steps#
The first call answers 428 confirmation_required. Nothing has happened. The body carries will_destroy, a summary of the consequence, and a confirmation_token. The second call — same call, same arguments, plus the token — executes. The token is single-use, lives 5 minutes, and is bound to the exact subject and its state: if the target changed in between, the API answers 428 again with a fresh summary. A token that no longer counts is treated as absent, never as a 409.
The gestures that confirm, for everyone, human or agent: destructive SQL (a statement that does not name its target), changing a table's preset, deleting a project, deleting an end user, issuing a password-reset link, changing the app URL, deleting oneself as an end user, the four governance gestures of a space (delete, add or remove a member, transfer the admin role), and more than 40 deletions by one account key on one project within 5 minutes.
Requiring a signed-in human#
The human is proved by X-Account-Session: the session of your own dashboard sign-in. Without it the API answers 401, definitive, and issues no token. The refusal comes before the ownership check, so it reveals nothing about whether the target exists.
Always, whoever the caller is:
| Gesture | Tool | Why a human |
|---|---|---|
| Change or clear the app URL | set_app_url | it redirects every user of the app |
| Delete a project | delete_project | everything in it is destroyed |
| Delete an end user | delete_user | their data is destroyed, and they cannot confirm |
| Issue a password-reset link | reset_password | it hands the caller a way to take over an account |
| Export a project | — | an exposure cannot be taken back |
| Create or rotate a secret key | create_key, rotate_key with sk | its value is delivered to the caller |
Open a table that holds rows to users or anon | set_table_preset | rows were deposited under a promise |
| Destructive SQL with the account key | run_sql, apply_migration | the account key acts for a human who has to be there |
| More than 40 deletions in 5 minutes with the account key | delete_row, delete_file | a volume of targeted deletions is an untargeted one |
| Set the value of a secret, of a project or of the account | no tool | the value must never pass through an agent |
| Remove a shared secret, close it to limited keys, or apply it to the functions already running | no tool | it changes what every function of the account reads |
| Connect, list or disconnect a GitHub installation | no tool | it carries the logins of your organizations |
| Unlink a repository from a project | no tool | it withdraws a deployment right |
| — | every publishable key now opens the app to sign-ups |
What needs no human, by decision: revoking any key (cutting off a leaked key must not wait), reading the names of a project's secrets and of the account's shared ones (never a value, never a digest), removing a secret of a project, deploying or destroying an edge function, deploying or removing a site, linking a repository, creating or rotating a publishable key, destructive SQL with a project's own secret key (the server confirms itself), closing a preset or widening writes, every governance gesture of a space.
Twenty-nine of the 38 tools run on the account key alone; four always need a human; five conditionally. The tool index marks each one.
Handing a session to a local agent#
For a working session you can lend your own authority to a local MCP server: put your dashboard session token — the access token of your sign-in — in the MANYBASES_ACCOUNT_SESSION variable of its configuration. The token lives about one hour and is not refreshed: past it, every guarded call answers 401 Invalid or expired account session; sign in again and replace the value. It moves the boundary for a session; it never abolishes it.
The remote connector has no such channel: its OAuth login issues a key, not a session, and the human gestures above are refused to it exactly as to a local agent. The consent screen says so before you install it — see Connect an agent.
What this protects, and what it does not#
The two-step confirmation protects from inattention and races, not from intent: a scripted loop that reads the summary and confirms passes. The human requirement protects what a human must own: the ak_ has no way to fabricate an account session, and no output of the API — body, header, hint, SQL history, export — ever contains one. What the machine hosting the agent can reach by other means is outside the API's reach.