Security

Last updated 27 September 2026.

This page answers the five questions a security officer asks, in order, in everyday words. Everything here is true of the shipped product on the day above. The full security model is in the product documentation and available on request.

1. What data exists

  • The record: JSON files under a tracker folder in your own repository. Per person per day: the plan, the tasks started, blocked, and done, the commits, and the timed intervals of each session with the agent identity that ran it (runtime, version, model, tools, permission mode; null when the runtime cannot say).
  • Review records: one small file per reviewed commit naming the person who reviewed it and when.
  • The chain: one file per day holding the hash of every record file written that day and the hash of the previous day, with the receipt from the transparency log beside it.
  • Tasks, notes, decisions, and questions: GitHub issues in your repository, with labels.
  • On our side: accounts (the emails that sign in), the App installation for each repository, the boards a person can open, an audit log of board actions, the waitlist, and messages sent through the site. Never the record.

2. Where it lives

  • The record, the reviews, and the chain live in your git and nowhere else. There is no database for the record.
  • The hosted board reads your repository through a GitHub App your organization installs once, with three permissions: contents read and write, issues read and write, metadata read. The App's private key never leaves our servers and is never in the browser; a short lived token is minted for each request.
  • What we read is cached for a few minutes and dropped whenever you make a change, so what you see is current.
  • Accounts and the audit log live in a managed Postgres database in the United States.

3. Who can read it

  • Only people listed as members of a repository can see its board. Membership is a file in your own repository, kept by your team.
  • Sign in is by a link sent to your email. Your identity on the board is that email, matched against the member list, never a display name someone could change.
  • Anyone who is not a member sees a page that does not exist, not a locked door. The board's existence is not confirmed to outsiders.
  • A share link is read only, revocable, and shows hours and names only if the person who made it turned them on. An evidence export replaces names with roles and leaves hours out unless the exporter asks for them.
  • A question typed on the board is answered by an agent with read only tools. The question's text is treated as untrusted: the agent is told to answer it, never to follow instructions inside it.

4. What leaves the boundary

  • One hash per day, sent at the nightly close to a public transparency log (Sigstore Rekor, with OpenTimestamps as a second anchor), and the receipt that comes back. The hash reveals nothing about the record's contents.
  • An enterprise can point that anchor at its own log instead. Self hosted and air gapped installs are coming next as a template; the record and the scripts are the same either way.
  • The hosted board sends nothing else anywhere. No analytics on the board, no third party form tools, no marketing pixels.
  • A record marked as CUI stays inside the boundary. The hosted board and the connector refuse it and answer not found, as for a record that does not exist, so a marked team runs self hosted or air gapped. The marking itself, with its designation, is printed on every page of every export and changes only through a signed commit; it ships in the release after 0.4.0.

5. How it is verified

  • Every tracker commit is signed, with Sigstore by default or GPG where a team already has keys. The validator checks signatures on every tracker commit and fails the build on an unsigned one from the day signing was required.
  • The cryptography is FIPS approved algorithms, named: SHA-256 (FIPS 180-4) for every content hash and the chain, ECDSA P-256 (FIPS 186-5) for the signatures on anchor receipts and for signing keys under the fips setting, and Ed25519 (FIPS 186-5) for the default SSH signing keys. We ship no cryptographic module of our own; on a host in FIPS mode, the runtime's validated module does the work. Git's own object ids are carried as references only; what verify checks is the SHA-256.
  • One command, run in any clone with no network, replays the chain, checks every signature, and checks every anchor receipt, then prints one line per day and a verdict. An assessor runs it, not us.
  • The control map lists, per NIST SP 800-53 control, what the record provides and the ordinary case in which it is insufficient. It is evidence for controls, never a compliance claim. Read it on the Ledger page.
  • Every action taken on the board is checked in the same order, every time: that the request came from the board and not another site, that you are signed in and a member, that the request is well formed, and that you have not exceeded a sensible rate. Only then does it touch your repository, and only the issues it created. It never edits your code.
  • Nothing the nightly close does can deploy code. Production ships only through a deliberate step after the tests pass.

The longer list

A program's security review asks more than five questions. The twenty we are asked most, answered from the shipped product, are at /security/answers.

Reporting a problem

If you find a security issue, email security@truestate.space. We read every report and reply within two business days.