Trooth

Every connection to trooth.co and api.trooth.co uses TLS 1.2 or later. HTTP Strict Transport Security is sent on every response with a two-year max-age, includeSubDomains and preload, and plain HTTP is not served.

Evidence: next.config.mjs security headers; the response headers of https://trooth.co, readable by anyone.

Customer data is stored in a managed PostgreSQL database (Neon, on AWS us-east-1) that encrypts every volume and backup at rest with AES-256. Trooth's own nightly export of that database is encrypted with AES-256 before it leaves the runner.

Evidence: .github/workflows/db-backup.yml (gpg --symmetric --cipher-algo AES256); Neon's published security documentation.

Every table that holds tenant data has row-level security enabled with a policy, and the application connects as a runtime role that cannot bypass it. A build gate fails the deploy if a table is added without a policy.

Evidence: db/rls.sql; scripts/check-rls-coverage.mjs and scripts/check-db-roles.mjs, both in the verify:deploy gate list.

A harness signs in as three real accounts in three workspaces and sends each one foreign and forged identifiers into every covered surface, asserting a refusal each time. It ran green against a production-configured deployment on 2026-09-17, after three earlier runs each found something that was fixed the same day.

Evidence: tests/tenant-isolation.api.test.mjs; .github/workflows/e2e-isolation.yml, run #5.

Credentials live in Vercel and Cloudflare encrypted environment configuration. A secret scan runs on every commit in the build, and TruffleHog runs on every push in a separate workflow.

Evidence: scripts/check-secrets.mjs in verify:deploy; .github/workflows/security-scan.yml.

The only path to production is a GitHub Actions workflow that runs 152 build gates on the commit, compiles it, and uploads the prebuilt output. Direct deploys from a laptop are refused by the workflow's own checks, and the platform's automatic branch deploys are turned off for production.

Evidence: .github/workflows/deploy.yml; vercel.json (git.deploymentEnabled.main: false).

The production database is exported every night, encrypted with a passphrase the workflow refuses to run without, and retained for 30 days. The workflow fails rather than upload an unencrypted copy.

Evidence: .github/workflows/db-backup.yml; run #47 on 2026-09-18.

A separate workflow restores a backup into a fresh database and checks that the tables and row counts come back. It ran successfully on 2026-09-10 and is scheduled monthly.

Evidence: .github/workflows/db-restore-rehearsal.yml; run #1 on 2026-09-10.

Preview deployments run on their own hosts with their own configuration and never receive the production domain. The database used for the live row-level-security proof in the build is a throwaway server on the runner, not production.

Evidence: .github/workflows/deploy.yml (the PostgreSQL service and the production-host refusal).

An external monitor checks trooth.co, api.trooth.co and the health route on a schedule, a second monitor runs in GitHub Actions, and the result is published on a public status page with incident history and email subscriptions.

Evidence: .github/workflows/uptime.yml; https://trooth.co/status.

Trooth publishes a written information security policy set of nineteen policies covering information security, access control, passwords and authentication, data classification, encryption, secure development, vulnerability management, logging and monitoring, incident response, business continuity, backup and retention, asset, risk and vendor management, acceptable use, personnel, physical security, data residency and AI governance. Each policy is owned by the founder, dated, public, and carries a six-month review date.

Evidence: Nineteen published policies, POL-01 to POL-19, effective 2026-09-18, next review 2027-03-18, on the Resources tab under Policies. They supersede the signed set of 2026-05-25.

The founder owns every security decision, approves policy changes and holds the only production write access. Anyone else granted access signs a confidentiality and acceptable-use agreement first, and every vendor that processes Trooth data signs a data processing agreement.

Evidence: Information Security Policy, section 4; Access Control Policy, section 4.

Trooth keeps a register of every external service it depends on, an inventory of information assets by classification, and generated inventories of the application's routes, components and public files that the build regenerates and compares on every deploy.

Evidence: docs/rebuild-package/EXTERNAL_SERVICE_REGISTER.md and SECURITY_ASSET_INVENTORY.md; check:manifests, check:components and check:assets in verify:deploy.

Every third party that processes customer personal data is listed publicly with its purpose and processing region. Customers receive 30 days' notice of a new sub-processor and may object for reasonable cause.

Evidence: https://trooth.co/subprocessors; Data Processing Addendum; Vendor and Third-Party Risk Management Policy.

Identified risks are recorded with likelihood, impact, the control that addresses each one, and the evidence for that control. The register is re-read whenever the gate list or the known-limitations record changes.

Evidence: docs/rebuild-package/RISK_REGISTER.md, checked for staleness by check:docs on every build.

No contractor or agent receives access to Trooth systems before signing a confidentiality and acceptable-use agreement. As of the date on this page Trooth has no employees or contractors with system access; the rule applies to the first one.

Evidence: Information Security Policy, section 4; Acceptable Use Policy (internal).

Every person with production access completes security awareness training within thirty days of receiving access and annually after that, with the completion recorded.

Becomes attested when: Becomes attested when the founder's first completion record exists. Target: 2026-10-31.

Human accounts, service accounts, sub-processor access and issued tokens are reviewed every 90 days and the review is recorded.

Becomes attested when: The policy requires it; the first recorded review has not been performed. Becomes attested when the first review record exists. Target: 2026-10-31.

Background checks are performed on new hires before they receive production access, where lawful in the hire's jurisdiction.

Becomes attested when: Trooth has no employees. The policy and the process are written for the first hire and become attested with it.

Incidents are classified into four severities with response times from fifteen minutes to twenty-four hours. The plan covers detection, acknowledgment, containment, eradication, recovery, communication on the status page and by email, and a written post-mortem within seven days for the highest severity.

Evidence: Incident Response Policy; docs/rebuild-package/INCIDENT_RUNBOOK.md; the incident history at https://trooth.co/status.

If personal data is compromised, affected customers and, where required, supervisory authorities are notified within 72 hours of Trooth becoming aware, as the Data Processing Addendum commits.

Evidence: Data Processing Addendum at https://trooth.co/dpa; Incident Response Policy, section 5.

Recovery objectives are set at four hours to restore service and twenty-four hours of maximum data loss, matched to the nightly backup. The plan names the failure scenarios, the recovery path for each, and what happens if the founder is unavailable.

Evidence: Business Continuity Statement at https://trooth.co/continuity; docs/rebuild-package/DISASTER_RECOVERY_PLAN.md and BUSINESS_CONTINUITY_PLAN.md.

A change reaches production only as a commit on the main branch that has passed the type check, the lint, the unit suites and the 152 gates that check headers, authorization, database roles, row-level security, secrets, request validation, rate limits, accessibility, documentation and more. A failing gate means nothing is uploaded.

Evidence: package.json gates array; scripts/run-gates.mjs; .github/workflows/deploy.yml.

Dependencies are watched by Dependabot and audited for high and critical advisories on every push; static analysis runs on every push; and a published policy sets remediation timelines of 24 hours for critical findings in production, 7 days for high, 30 for medium and 90 for low.

Evidence: .github/dependabot.yml; .github/workflows/security-scan.yml (pnpm audit, TruffleHog, semgrep); Vulnerability Management Policy.

Researchers can report to security@trooth.co under a published policy that welcomes good-faith research and states the safe harbor. The address and the policy are advertised in the site's security.txt.

Evidence: https://trooth.co/security/vulnerability-disclosure-policy; https://trooth.co/.well-known/security.txt.

Application errors are captured with every event scrubbed of personal data before it leaves the server, and material actions in the product land in an append-only audit ledger whose entries are hash-linked so that a removed or altered row is detectable.

Evidence: instrumentation.ts and lib/sentry-scrub.ts; check:ledger and check:observability in verify:deploy.

Trooth operates no physical infrastructure. Its data is held in facilities operated by Amazon Web Services (through Neon and Vercel) and Cloudflare, each of which publishes independent audit reports for the physical and environmental controls of its facilities.

Evidence: Sub-processor list; Shared Responsibility Model (Resources tab).

An end-to-end incident drill is run at least annually and documented, exercising detection, the status page, customer communication and the post-mortem.

Becomes attested when: The policy schedules the first drill for January 2027. Becomes attested when the drill record exists; the founder intends to bring it forward to 2026-10.

Every AI-assisted feature Trooth operates is named in a published model card with its intended use, its users, its inputs and outputs, its approach and its limitations.

Evidence: https://trooth.co/model-card; AI System Fact Sheet (Resources tab).

A public policy states where generative AI is and is not used in the product, which decisions are always made by a person, and that Trooth does not use customer content to train models.

Evidence: https://trooth.co/ai-policy; https://trooth.co/ai-disclosure.

Trooth does not use customer content, connected-integration data or account information to train foundation models, and does not sell or share it so that others can. Pages carry noai and noimageai robots directives.

Evidence: Privacy Policy, https://trooth.co/privacy; AI Disclosure, section on automated access.

Trooth has classified each AI-assisted feature against the EU AI Act's risk categories and documented its role as a provider, the applicable transparency obligations and how each is met.

Evidence: EU AI Act Transparency and Risk Classification (Resources tab); EU AI Act statement.

Trooth signed the European Commission's AI Pact commitments ahead of the AI Act's application, and the Commission lists Trooth on its public roster of signatories.

Evidence: https://digital-strategy.ec.europa.eu/en/policies/ai-pact; EU AI Pact commitments (Resources tab).

A drafted answer, a suggested mapping or any other AI-assisted output is labelled as such in the product, and an observation Trooth witnessed is never labelled as an AI draft.

Evidence: AI Disclosure, sections 2 and 3; test:ai-features in verify:deploy.

AI-assisted features draft; they do not send, publish, sign, approve or delete. Every action of those kinds requires a person's explicit confirmation in the product.

Evidence: AI Disclosure, section on decisions always made by a person; test:publish-authorization and test:approval-authority in verify:deploy.

Text that arrives from a third party, such as a questionnaire, a page Trooth crawled or a document a company uploaded, is treated as data and never as an instruction to an AI-assisted feature. A build gate keeps the isolation in place.

Evidence: lib/untrusted-content.ts; check:untrusted-content and test:untrusted-content in verify:deploy.

Trooth maps its AI governance activities to the four functions of the NIST AI RMF and publishes the mapping with the gaps it still has.

Evidence: NIST AI RMF conformance statement (Resources tab).

Trooth's AI-assisted features run open-weight models on Cloudflare Workers AI, inside the same network that serves the product, under terms that exclude Trooth's inputs and outputs from model training. No customer content is sent to a consumer AI service. Cloudflare is on the sub-processor list.

Evidence: Sub-processor list (Cloudflare, Inc.); AI System Fact Sheet; Cloudflare's published Workers AI data-use terms.

Authenticator-app TOTP is built in and free for every account, including buyer accounts. It is a property of having a Trooth login, never a paid feature.

Evidence: Settings, Security, in the product; tests/auth-journey.test.mjs.

Passwords are stored as salted PBKDF2 hashes and upgraded transparently as work factors rise. Sign-in and signup are hardened against account enumeration with equalised timing and lockout on repeated failures.

Evidence: Security Overview (Resources tab); the sign-in behaviour is observable from outside on every attempt.

Sessions live in httpOnly, secure, same-site cookies with a 30-day absolute expiry. Logout revokes the session upstream and reports a failure rather than swallowing it.

Evidence: lib/session-read.ts; docs/rebuild-package/DEFENSIVE_ASSESSMENT.md, section 3.

An API key is displayed once at creation, stored only as a SHA-256 hash, scoped to its workspace, and revocable at any time.

Evidence: Security Overview (Resources tab); API Terms at https://trooth.co/api-terms.

An account that has turned on multi-factor authentication can generate single-use recovery codes to regain access if the authenticator is lost.

Becomes attested when: Not implemented; the authentication service offers no recovery or backup codes and tests/auth-journey.test.mjs asserts the absence. Becomes attested when the feature ships.

Every credential-free mutating route parses its body against a declared schema and reads no field it does not declare. A build gate fails the deploy when a route is added without one.

Evidence: lib/api-schemas.ts; check:request-validation in verify:deploy.

A content security policy, strict transport security, frame, content-type and referrer policies are sent on every response, and a build gate compares the policy against the source on every deploy.

Evidence: next.config.mjs; check:csp in verify:deploy.

Unauthenticated and bare-token mutations are rate limited per client, failing closed where the work costs money. Public forms are protected by Cloudflare Turnstile, and a submission that fails the check is rejected before anything else happens.

Evidence: lib/rate-limit.ts and lib/turnstile.ts; check:rate-limit and check:turnstile in verify:deploy.

Every material action in the product is recorded in an append-only ledger whose entries are hash-linked, so that a removed or altered entry breaks the chain and is detectable.

Evidence: check:ledger in verify:deploy; the Security Overview (Resources tab).

Routes that touch tenant data derive the owner from the session, and a build gate checks every route for an authorization call. Function-level and property-level authorization are enforced on the surfaces the assessment names.

Evidence: check:authz in verify:deploy; docs/rebuild-package/DEFENSIVE_ASSESSMENT.md, section 3.

The privacy policy states what is collected, why, for how long, who processes it, and how a person exercises their rights. It carries its effective date and is reviewed when the product or the law changes.

Evidence: https://trooth.co/privacy.

A data processing addendum with the standard contractual clauses is published and incorporated into customer terms without negotiation.

Evidence: https://trooth.co/dpa.

The list of third parties that process customer personal data is public, with each provider's purpose and processing region, and changes are announced 30 days in advance.

Evidence: https://trooth.co/subprocessors; the Subprocessors tab of this page reads from the same document.

Each kind of data has a maximum retention period and a stated disposal event. Working data is removed 30 days after an account closes; backups age out on a 30-day rolling window.

Evidence: https://trooth.co/retention; Data Retention and Disposal Policy.

Access, correction, portability and erasure requests are accepted through a published procedure and completed within 30 days. Erasure is exercised against the live database and tested in the build.

Evidence: Data Subject Rights Request Procedure (Resources tab); test:privacy-request and test:erasure-live in verify:deploy.

Data is classified as public, internal, confidential or restricted, with handling requirements for each level covering encryption, access, logging and where the most sensitive material may be stored.

Evidence: POL-04 Data Classification and Handling Policy, published on the Resources tab.

Trooth takes no payment and holds no card data. No payment processor is a sub-processor.

Evidence: Sub-processor list change log, 2026-09-04.

Trooth does not sell personal information and does not use the content of connected data for advertising.

Evidence: Privacy Policy; CCPA statement (Resources tab).

Primary customer data is stored in the United States (AWS us-east-1, through Neon). Edge compute and content delivery run globally through Cloudflare and Vercel. Each sub-processor's processing region is published.

Evidence: https://trooth.co/subprocessors.

The site sets the cookies its own session and security need and discloses each one. Analytics are aggregate and carry no personal identifiers.

Evidence: https://trooth.co/cookies.