Chronos/DBWaitlist

Account

Other people’s agents

Let someone else’s coding agent work on your database: they ask, you approve what it may do, for how long.

SoonThese pages describe Chronos Cloud, which opens from the waitlist. Running Chronos yourself? Self-host docs

How it works

You share your project’s MCP address with someone. The address gives nothing by itself: their agent signs in to Chronos as them, and until you approve, all it can do is ask. You approve in a browser, pick what it may do and for how long, and its access works only for that person, that program and that sign-in. It never gets your keys, your DATABASE_URL, or anything you didn’t tick.

For people who work with you all the time, invite them to the org instead. This is for everyone else, and for the times a member’s role is more than an agent should have.

Asking

They add the server to their coding agent with your project’s address (it’s on your project’s Connect page) and sign in with their own Chronos account:

their terminal
claude mcp add --transport http chronos "https://…/?project=prj_…"

Their agent sees only request_access, access_status and redeem_access. It calls request_access with the rights it needs and a note, and gets back a link and a code like K7QX-MP2D. Owners of the project’s org get an email. The request is open for 30 minutes; the agent can ask again.

Approving

  • Open the link, or the project’s Access page. You see who asks by what Chronos verified (their email, their GitHub account), and the program’s own name for itself (programs name themselves, so it is labelled so).
  • Ask them for the code their agent shows and type it in: approve stays off until it matches. A link someone else sent you won’t have the code they read out.
  • Untick anything you don’t want to give (you can only give less than they asked), pick how long (7 days by default, 30 at most), and, if your tables share a tenant column, limit it to one tenant’s rows.
  • Approve. Their agent gets the database’s tools when it lists them again.

Owners decide. An owner can let members decide too, for every project of the org, on the Access page.

The rights

RightLets the agentComes with
schema:readsee tables and columns, never a row (schema)every grant
sql:readread with SQL, get, find, diff, history
world:writefork worlds and change its own; never mainsql:read
merge:requestput a world forward for review (request_merge); you merge it in Reviewsworld:write
production:dataall of the above on a production project; without it a production project shows only the schema
postgres:connectmake a Postgres sign-in for psql or a driver that works for an hour, with the same rights (postgres_login)sql:read

Invite codes

When you know ahead who needs access, make a code on the Access page instead: name the person by their email or GitHub username, the rights and how long. Give them the code; their agent calls redeem_access with it. A code works once, only for an agent signed in to Chronos with that verified email or that GitHub account, only while you may still approve, and for up to a day (an hour by default). It’s shown once; Chronos keeps only its hash. Codes tried count against the person trying: ten in 15 minutes and they wait.

What the agent gets

Its own database agent, ext-<login>-<project>-…, with only the rights you gave, quotas (5 worlds, 10,000 changed rows a world, 600 writes a minute, 30-second statements), your tenant, and a token that stops working when the access ends. The token never leaves Chronos: every call goes through Chronos, which checks the access first, and the database checks again.

Its worlds show in Worlds under its agent’s name. A world it puts forward waits in Reviews marked “asks for a merge”, with its note.

Revoking

Revoke on the Access page (or on Agents) ends it at once: the next call is refused, its database agent and Postgres sign-ins are disabled. Access also ends on its own when its time is up, and when they sign out of the program or remove the server. Its worlds stay for you to merge or discard.

The audit

Every call a granted agent makes, allowed or refused, and every request, decision, code and revocation, is in the Access page’s audit: who, which program and session, which database, what, which world, when, and the outcome. For SQL it keeps the kind of statement and a fingerprint, never the text. Calls by your own agents are there too. Kept 90 days on the free plan, a year on Pro.

Limits and guarantees

  • The address is not a credential. Naming a project you can’t use gives only the right to ask (and not its name), answered the same whether or not it exists, and never falls back to another project.
  • A request’s code and an invite code are short-lived and single-use; requests, lookups and wrong codes are counted and limited.
  • A valid code is not enough on its own: a request still needs your approval, and an invite works only for the person named on it.
  • Access is bound to one project, one person, one program and one sign-in, expires, and is revoked in one click.
  • Sign-in is standard OAuth 2.1 with PKCE, as the MCP authorization spec asks; MCP tokens last an hour and are refreshed, a refresh token used twice ends the sign-in, and signing the program out ends its access.
  • No secret is written to logs, errors or links.
Other people’s agents · Chronos