Security answers
The twenty questions every program's security review asks about Truestate, answered once from the shipped product and kept current. This file is the one source: it is served at /security/answers and shipped in the pilot kit. Facts only; where something is not built yet, the story and task number say so.
Last reviewed 2026-09-18.
1. What data does the tool create, and where is it stored
Plain JSON files under tracker/ in the team's own git repository: the people list with sign in emails, the configuration, one story file per feature with its tasks, one log per person per day (sessions with the agent's runtime, model, and permission mode, entries, commits, hours as timed intervals), review records per commit, the daily chain entries with their anchor receipts, and, when a policy is in force, the policy file, recorded exceptions, and break glass entries. Nothing about the record lives anywhere else. The hosted board's Postgres holds sign in accounts, share links, onboarding rows, and an audit log of who viewed what.
2. What leaves the boundary
Self hosted, with the anchor inside the boundary: nothing. Hosted, or self hosted with the public anchors: one hash per close, thirty two bytes, to the Sigstore transparency log and an OpenTimestamps calendar. No file content, no names, no prompt text, no code leaves in either mode.
3. Who can read the record
Anyone with read access to the repository, because the record is files in it. The board shows the same files to people listed in people.json after they sign in; it adds nothing a reader of the repository could not already see. Share links are read only, unguessable, revocable, and off in the pilot configuration.
4. What credentials the tool holds
A signing identity per person: the machine's own SSH key by default (made without a passphrase if none exists), or gitsign's short lived certificate, or a GPG key the program manages. A service account token for the self hosted board, with read access to the repositories; write access to issues only where tasks and Ask are wanted. The hosted board uses a GitHub App instead. Sessions carry no credential of their own: a session is attributed to the person who directed it.
5. How the record is protected from alteration
Every tracker commit is signed once the Ledger is on. Every close writes a chain entry hashing the files it wrote and the entry before it. Each entry is anchored outside the repository with a receipt stored beside it. truestate verify replays all three offline and prints a verdict; a rewritten history, an edited closed file, or a missing receipt each fails a named line.
6. Which cryptography
SHA-256 for every hash. ECDSA P-256 for the anchor signatures and the self hosted log's records; Ed25519 or ECDSA for SSH commit signatures as the key provides. The FIPS validated module pinning is story 013 task 23 and is required before a CTI pilot starts.
7. Whether prompts, code, or CUI are sent to any AI service
No. The tool records the sessions; it is not the AI service and never calls one. Prompt text is not stored in the repository unless the team turns storePrompts on, and the pilot configuration leaves it off.
8. Does it call out to the internet
Only to the anchor, which can be inside the boundary, and to the npm registry if the team installs the command line tool from it rather than from the offline tarball. The self hosted board calls the program's own git host and nothing else.
9. What happens if it is removed
The record remains in git as plain files that any reader can open; verify still runs from the tarball against them. Nothing else depends on the tool.
10. How updates are delivered and verified
Signed releases: the tarball with SHA256SUMS, a signature over it, the key to verify with, and a bill of materials; the container images by digest, never by tag alone. Check the sum and the signature before installing.
11. What logging the tool itself does
The board keeps an audit row per read through the connector and per page view by a signed in person: who, which board, when. It never logs session content, prompts, or code.
12. Does it block engineers
Three narrow cases, each logged, each with a break glass that lets one action through and never disables the rule: a session under a model the policy denies does not start; a tool the policy denies is refused; a commit with no session identity behind it fails the check once the Ledger is on. A change to a protected path without a review fails the check unless an approver records a time limited exception. Everything else is advisory: shown, never blocked. The pilot's default policy protects no paths, so on day one only the identity rule can stop anything.
13. Software bill of materials
Generated per release in CycloneDX form and included in the release and the archive. The command line tool has no dependencies.
14. Vulnerability disclosure
Email security@truestate.space. We read every report and reply within two business days, and we tell the reporter what we found and when it shipped.
15. Is it FedRAMP authorized
Self hosted inside the boundary, it runs under the program's own authorization; nothing of ours is in the path. The hosted board is not part of a federal pilot and is not FedRAMP authorized.
16. Personnel
Who at Truestate can access a pilot's data: nobody, in self hosted mode. There is no telemetry, no support tunnel, and no account of ours in the program's systems.
17. Data retention on our side
None, in self hosted mode. In hosted mode the board holds the account rows described in answer 1 until the team asks for their removal.
18. Licence and rights
The record format is documented in the product package and the program owns every file in its repository; the format has no licence of its own. The command line tool is MIT licensed. The board's source is the program's to run under the pilot agreement.
19. Support
Email the address above. truestate doctor is the first step: it prints one line per check (hooks, scheduler, person, the App or service account, the last close, the signer, the anchor) and says what to do. Attach its output.
20. Roadmap items a program may be waiting on
- CUI marking on the record and the export, and FIPS pinning: story 013 task 23.
- The receipt per commit and blame from a file to its session: story 013 tasks 17 and 18.
- The OpenTelemetry export for runtime observability tools: story 013 task 20.
- Runtime adapters beyond Claude Code (Codex, Cursor, Gemini CLI, Windsurf): story 013 task 24.
- RegScale import of the OSCAL files, the last check on story 013 task 14.
CUI and CTI
If the repository holds source with a military or space application it is controlled technical information and must be protected at moderate confidentiality and integrity. In that case the marking and FIPS work (story 013 task 23) is required before the pilot starts, the export carries the marking on its cover and every page, share links are off, prompts are not stored, and the anchor is inside the boundary.