Security

#The model

Chronos assumes a coding agent will, sooner or later, do something wrong with full confidence: a bad migration, a delete with the wrong WHERE, a decision on data that changed. It doesn’t try to make the agent right. It makes the agent’s work land only where you’ve said it may, makes everything it did visible, and makes all of it undoable.

#Containing agents

• Least rights by default. Coding agents get read, fork and write_own, plus write_main and merge_own in development. They never get merge (others’ worlds), restore, or admin: they can’t change rules, agents or settings.
• Rules run inside the merge, on the rows it applies, under its locks: nothing written between a check and the merge slips past.
• The queue can’t be skipped. A held world’s hold is written where only the database writes; its agent can’t clear it.
• Everything is attributed. Every write is logged under the agent’s name (SHOW AUDIT), with the program that connected and the run that made it if tagged.
• Quotas on worlds, writes, query time and memory stop a runaway agent from taking the database with it.

#Approvals by people

Merging a held world, discarding it, undoing a merge, revealing the database password, approving a terminal’s or an MCP client’s sign-in: each needs a person signed in to the dashboard. API keys and MCP tokens, which a coding agent in your terminal can read, are refused on all of them. An approval names the version the person read, so an agent can’t slip a change in between reading and merging.

#Data and connections

• TLS everywhere: Postgres connections must use TLS (sslmode=require); the dashboard, API and MCP are HTTPS only.
• Isolation: each project’s database runs as its own process with its own files and credentials; a project’s credentials don’t reach another’s.
• The app role can read and write tables, not worlds, agents, rules or settings: a leaked .env can’t approve, merge or change who may do what.
• Backups are copies taken apart from the database, kept 7 days on the free plan.

#Credentials

• API keys, MCP tokens and agent tokens are stored only as SHA-256 hashes; none can be read back. Dashboard sign-in sessions are kept by the sign-in provider.
• Secrets Chronos must use again (database passwords, agents’ tokens, signing keys) are kept encrypted with AES-256-GCM.
• Sign-in to the dashboard is GitHub or a one-time email code: no passwords of yours to leak.
• MCP clients sign in with OAuth 2.1 and PKCE; the consent page names the program and where it returns, and only a person can allow it.

#Your app’s users

Chronos Auth keeps your users’ accounts outside your database: passwords hashed with Argon2id, refresh tokens stored as hashes and rotated on every use (a reused one ends the session), failed sign-ins slowed per email and per address, and the same answer for a wrong email as for a wrong password. No agent working in a world can read a password hash. See Auth for your app.

#What’s left to you

• Keep .env out of your repository (chronos init adds it to .gitignore), and never give DATABASE_URL to an agent.
• Set merge policies before agents touch data that matters, starting with max_deletes = 0.
• Switch a project to production when real users depend on it.
• Give each program its own application_name so DIFF … READERS shows what depends on a column.
• Review what’s held. A rule only helps if someone reads what it stops.

#Reporting a problem

Found a security issue? Report it privately through GitHub’s security advisories, with what you found and how to reproduce it, and please don’t open a public issue first. The security policy says what happens next.