Security at Trusvo
A security product should be secure by construction.
Trusvo answers your customers' security questionnaires from your real evidence. This is exactly how that evidence is handled — the same standard we help you prove to your own buyers.
- Answers cite their sources
- Secrets redacted before storage
- No training on your content
- Self-hostable end to end
We never train on your content
Your code, configs and documents are used only to answer your own questions. No customer content is used to train models — ours or a provider's. Zero retention is required of the model provider where available.
Secrets are redacted first
Detected secrets — keys, tokens, credentials — are stripped before anything is stored and before any text is sent to a model. Redaction happens at ingestion, not as an afterthought.
Strict tenant isolation
Every query is scoped to your account and project. Access to evidence, answers and trust rooms is checked on each request — one customer can never read another's data.
Config-only mode
Ingest manifests, infrastructure config, schemas and docs without your application source code ever entering the platform. The boundary is enforced in the pipeline, not just the interface.
Encrypted in transit; secrets encrypted at rest
TLS everywhere. Runtime provider secrets (AI and email keys) and the trust-signing key are stored AES-256-GCM encrypted, never in plaintext. Disk-level encryption of the database and uploads depends on the hosting environment — ask about the deployment you are evaluating.
SSRF-guarded fetches
When Trusvo fetches an external URL — a repository, a well-known endpoint — the request is guarded against server-side request forgery: private, loopback and link-local addresses are refused.
Signed attestations
Trust snapshots (trust.json) are signed with a per-instance Ed25519 key. The public key is published at /.well-known so any buyer or agent can verify a payload is authentic, timestamped and untampered.
Sign-in, MFA and self-hosting
Signed, HTTP-only sessions, two-step verification (authenticator app, emailed code or recovery code) required for our admins and available to every user, and the option to self-host the whole product so your code never leaves your network.
Audit logging
Privileged and security-relevant actions are recorded — account changes, admin actions, access decisions — so there is an honest trail of who did what.
How we build it
The controls behind the principles, grouped by what they protect. Every answer Trusvo drafts cites the evidence it is built from; the platform holds itself to the same rule.
Data handling
- Secret detection and redaction run at ingestion, before storage and before any model call.
- Config-only mode keeps application source code out of the platform entirely — enforced in the pipeline.
- No customer content is used to train models; zero retention is required of the AI provider where available.
- Uploaded source files are never publicly accessible; a trust room exposes only what you explicitly publish.
Access and isolation
- Every request is scoped to the signed-in user and project; cross-tenant reads are refused on every route.
- Sessions are signed, HTTP-only cookies. Two-step verification is required for platform admins and optional for customers; authenticator secrets are encrypted and recovery codes hashed.
- Trust-room access modes (public, NDA-gated, approval-gated) are enforced on the server.
- Machine-readable surfaces (trust.json, the MCP endpoint) never expose more than the human page.
Platform and integrity
- TLS in transit; provider secrets and the signing key stored AES-256-GCM encrypted at rest. Disk-level encryption depends on the hosting environment.
- Outbound fetches are SSRF-guarded — private, loopback and link-local targets are refused.
- Trust attestations are signed with a per-instance Ed25519 key, published for independent verification.
- Privileged and security-relevant actions are written to an audit log operators can search and export.
These are the same measures set out in our DPA and Privacy Policy.
Reporting a vulnerability
Found something? Email us. We acknowledge every report and work with researchers in good faith.
See also the Privacy Policy, DPA, Acceptable Use Policy and AI disclosure.
Last updated 2026-10-14