Security at Trued
Early access — last updated October 25, 2026
Release status. Controls are marked built and tested, in progress, or planned. Nothing is live yet: Trued runs only on preview environments with synthetic data (in testing, not yet live).
You're trusting us with your books. Here, in plain English, is what we do with your data and what we don't.
Our commitments, in plain terms
- Your data is never sold, rented, shared for marketing, or used to train AI models.
- Connections are read-only. Nothing posts to your books without your approval.
- Each company's data is isolated. Every action is recorded in an append-only audit log. Tamper-evident protection (hash chaining and a separate owner role) is in progress.
- You can ask us to export or delete all of your data at any time. Deletion is by request, confirmed in writing.
- We never use your data to train AI models. We use our AI provider's commercial API, which by default does not use API data to train models. We are confirming that against our signed terms. Zero-retention terms are not in place yet.
- Trued supports accountants. It doesn't give tax, legal, or audit opinions, and a person always signs off.
How it works, and why that's safer
Read-only connections. We only read from your systems. How that's enforced differs by connector, and the table below says so plainly. You can disconnect at any time.
You approve everything. Trued marks flagged invoices to fix (you correct them in your billing system) and prepares drafts: a proposed accrual, a reconciliation. Nothing is posted, paid or sent until a person at your company approves it.
Every number shows its work. Each figure links to the records and the rule that produced it, so your team can check it instead of taking our word for it.
An append-only audit log. Every action and every approval is recorded, with who did it and when. Tamper-evident protection (hash chaining and a separate owner role) is in progress.
A signed-off month is locked. A signed-off month can't be re-signed or changed. The database enforces this, and a row-level-security test covers it.
Your company's data is isolated. Every row of data carries its company ID, and database row-level security on every table keeps one company from reading another's. Automated checks prove one company can't read another's data.
Encryption and keys
- In transit: HTTPS only, enforced in code for every connector.
- At rest (database): Supabase states: "All customer data is encrypted at rest with AES-256 and in transit via TLS" (supabase.com/security). That is the provider's statement, not our own test.
- At rest (your books data): per-company encryption of synced records, structured contract terms and close results is in progress, not done. Today that data relies on the database provider's encryption at rest.
- Exactly what is and isn't sealed under your company's key today. Sealed (built and tested; in testing, not yet live): connection tokens and API keys; contract PDFs; bank statement files and each bank line's description; payroll register files (deleted right after parsing) and the saved pay-run totals and department totals. Not sealed under a company key (stored as ordinary database data, protected by the provider's encryption at rest and row-level security): records synced from QuickBooks, Stripe and Ramp; structured contract terms; close results; bank line dates, amounts and bank IDs; short bank descriptions in import notices; payroll totals as quoted in the close summary (shown only to owners and reviewers); the audit log.
- A separate key for every company (connection tokens). Each company has its own data key (AES-256-GCM, envelope encryption), wrapped by a key-management service. An AWS KMS adapter is built and tested, and a local key is refused in production. That key encrypts your connection tokens. Per-company key revoke is in progress.
- Connection credentials: tokens and API keys are stored only encrypted with your company's data key, are never logged, and can't be read back by any app user, including owners. Automated tests check this.
- Secrets: secrets live only in local environment files and Vercel environment variables. Environment files are excluded from git, and only an example file is tracked. A secret scan runs before every commit, and the last scans found only fake test values. The database service-role key appears nowhere in the app's build output (checked on every build).
How read-only is enforced, by connector
| Connector | How it's enforced |
|---|---|
| Ramp | Read-only OAuth scopes (or the customer's own Ramp app with read scopes only). |
| Stripe | The customer gives us a restricted key with read-only access. Full secret keys and publishable keys are refused. Stripe can't report a key's permissions, so we verify only the reads we need, and our code never writes. |
| QuickBooks | Intuit doesn't offer a read-only permission, so the token technically allows writes. Our code blocks every write call, and tests check it. |
| NetSuite | Read-only depends on the customer assigning a view-only role; we document that for customers. Our code blocks write calls. |
| Payroll | Read-only payroll scopes, totals only (no names, SSNs or bank accounts). Payroll register uploads drop any column whose header names a person before any value is read. A personal-data column with an unrecognizable header can't be detected automatically, so we ask customers to leave those columns out. The uploaded file is sealed in a private per-company bucket and deleted as soon as the totals are saved (built and tested; in testing, not yet live). |
Where it says "our code blocks," the provider's own permission may allow more than reading. We are explicit about that difference rather than implying it's the same everywhere.
AI, and what happens to your data
Trued uses an AI model to read contracts, check records and answer questions. We send only what each task needs. Before any AI call, names, IDs and amounts are replaced with tokens, and payroll register files and bank statement files are never sent to any AI. Our AI provider is Anthropic, used through its commercial API, which by default does not use API data to train models. We are confirming that against our signed terms. Zero-retention terms are not in place yet, and the provider may keep what we send for a limited time. AI output is a draft for a person to review. Code computes all numbers, and the AI's own numbers are stripped. The AI never posts or sends anything. A short bank description from a statement that overlaps an earlier one can appear in an import notice, and notices can be shown to the AI model after amounts, numbers and known names are replaced by tokens. Removing those descriptions is being fixed.
Your control
- Export all your data, any time. During early access, email us.
- Delete all your data, any time. Email us; deletion is by request, confirmed in writing. Full cryptographic deletion, including backups, is in progress. Copies may also exist in backups, if backups are enabled, until they age out.
- Revoke any connection, any time.
What we are, and what we aren't
Trued supports accountants. It doesn't give tax, legal, or audit opinions, and it doesn't replace anyone's judgment. A person always signs off.
Certifications and testing
We plan to pursue SOC 2. No audit has started yet. We are not SOC 2 certified today, and we'll update this page when that changes. A penetration test is planned.
Security controls and their status
| Control | Status |
|---|---|
| Read-only connections (writes blocked in our code) | Built and tested; in testing, not yet live |
| Company isolation (row-level security, automated checks) | Built and tested; in testing, not yet live |
| Month sign-off lock | Built and tested; in testing, not yet live |
| The person who prepared an entry can't approve it | Built and tested; in testing, not yet live |
| Connection credentials encrypted, never logged | Built and tested; in testing, not yet live |
| AI safeguards (tokenization, AI numbers stripped, no posting) | Built and tested; in testing, not yet live |
| HTTPS only for connectors | Built and tested; in testing, not yet live |
| Tamper-evident audit log (hash chain, separate owner role) | In progress |
| Per-company encryption of books data | In progress |
| Full cryptographic deletion, including backups | In progress |
| Per-company key revoke | In progress |
| Dependency scanning in CI | In progress |
| SOC 2 | Planned; no audit started |
| Penetration test | Planned |
| MFA enforcement policy | Planned |
| Agreements with sub-processors | Planned |
Backups: daily backups apply to Supabase paid plans only, and we are not on a paid plan yet.
Our service providers (subprocessors)
| Provider | What it does for us | Data it handles |
|---|---|---|
| Supabase | Database and storage | Account and customer data |
| Vercel | Hosts the website and app | Requests and logs, including IP addresses |
| Anthropic | AI model provider | Text sent for a specific AI task |
| AWS Key Management Service | Holds the root key that wraps each company's data key | Encrypted keys only, no customer data. Planned; not yet in use |
The systems you connect (QuickBooks, NetSuite, Ramp, Stripe) are your own sources. We read from them and don't send them your data.
If something goes wrong
If we learn of unauthorized access to your data, we'll tell you without undue delay, with what we know and what we're doing about it.
Found a vulnerability? Please tell us at logan.abele@usetrued.com.
Questions
Security and privacy: logan.abele@usetrued.com. See also our Privacy Policy and Terms of Service.