Security & trust
Built like the evidence depends on it.
A firm's license rides on this system, so its safety properties are structural — enforced by the database, the ledger, and the policy engine, not by good intentions.
Isolation
Tenant isolation by construction
Multi-tenancy is enforced structurally, not by convention. Every query path runs behind Postgres row-level security scoped to the tenant, so an application bug cannot become a cross-tenant data leak — the database itself refuses cross-tenant reads and writes.
Within a firm, each client's memory and conventions are separated: one client's coding history never informs another's unless the firm explicitly marks a convention as firm-wide.
Privacy
Text identifiers are masked before inference
Every inference payload passes through a masking gateway before it reaches a model. In the text of a prompt, Social Security numbers, EINs and bank account numbers are replaced with stable pseudonymous tokens; the re-identification map stays in our infrastructure, and model responses are re-hydrated there. Names and postal addresses in the text are not masked today.
The larger limitation, stated plainly because it matters: masking operates on text only. Images and scans — the PDF pages and receipt photos sent for vision extraction — go to the model provider as-is, so every identifier visible on a scanned statement or payroll summary reaches the provider unredacted. Zone redaction of document images is planned and not yet built.
Inference runs through the providers' commercial APIs, under terms that do not use the content to train models, and we never use client financial data to train models ourselves. Prompts carry only the fields a task needs, and the same text masking applies to logs. The providers are named on the sub-processor list.
Ledger
An immutable ledger
Finalized entries are never edited in place. The finalized ledger is append-only double-entry; corrections are explicit adjusting or reversing entries linked to the original, so the record of what changed — and why — is itself part of the books.
Closing a period locks it: the service refuses new journals and in-place edits against a closed period, and corrections go through the same sign-off workflow as everything else.
Accountability
The decision log
Every agent action is recorded with its trigger, the retrieved context, the tool calls and their results, each factor of the autonomy decision, the verification-gate result, the outcome, the human who resolved it if any, and the pinned model version and configuration.
The log is append-only — the application role holds insert and select rights and nothing else. A reviewer can see exactly what the agent saw and why a gate passed or failed.
Control
Governed autonomy & sign-off
The agent is a preparer, never an authorizer. Every binding action carries an approval token that only the policy engine can issue; the services that touch the ledger verify that token's signature and refuse to act without it. Tokens are Ed25519-signed, single-use, and bound by hash to the exact request body they authorize, so an approved action cannot be swapped for a different one.
A material item that fails a verification gate can only proceed by an explicit, attributed, logged human override — never by the agent retrying until it passes. Finalizing a period always escalates to a human.
A kill switch drops any firm or client to fully supervised mode instantly, without losing state or work in progress.
Baseline controls
The table stakes, stated plainly
In transit
TLS 1.3 at the edge
At rest
Provider-managed encryption on all volumes and object storage
Credentials
AES-256-GCM field-level encryption for connector secrets and the PII vault
Access
Role-based access control; client accounts are scoped to a single client and default-denied everywhere else
Audit trail
Append-only financial audit log: who changed what, when, and under which approval
Ledger
Double-entry in TigerBeetle; finalized transfers are immutable and reconcilable to the trial balance
Backups
Nightly encrypted off-box backups of Postgres, the ledger, and evidence, with a published restore procedure
Sign-in
TOTP two-step sign-in available to every account; sign-in pauses after repeated failed attempts; password resets and new-device sign-ins are announced by email
Residency
Client data is stored and processed in one region (Ashburn, Virginia, USA); inference by the US model providers on the sub-processor list is the sole disclosed exception
Not yet built
What we don't claim
These are on the roadmap and are not available today. We list them because a firm evaluating this system needs the gaps as much as the guarantees.
- SSO (OIDC/SAML) for firm staff — TOTP two-step sign-in is live today; single sign-on is not
- Zone redaction of document images before vision extraction
- Separate access logging — who viewed what — with anomaly alerting
- Multi-region cells with tenants pinned to a cell
- Ledger replication across three nodes
- KMS-backed key custody with automated rotation
- SOC 2 Type II audit
The third parties that touch customer data are listed, with what each receives, on the sub-processor list. Want the deeper story on how autonomy itself is governed? Read about the governor, or join the waitlist and ask us directly.