Security¶
TOVIO exists to keep secrets secret. Its entire reason for being is to enforce file access cryptographically — by who can decrypt a file, not by who a server decides to trust. That makes security the most important promise the system makes, and the one it documents most plainly.
This section explains the security model honestly: what TOVIO protects, how the cryptography works for you as a user, how to manage your keys, what the audit trail gives you for compliance, and how to report a vulnerability. It is deliberately candid about the limits — what v1 protects and what it does not, so you can tell an intended tradeoff from a bug.
Implemented profile; not a release claim
The current public implementation covers Tier 0 (Solo) and Tier 1 (Team) of the permission model, but public V1 artifacts and independent assurance are still gated. The Tier-2 CP-ABE enterprise KA has passed its conformance/internal-review gate, but remains behind the separately licensed, default-off release boundary and is not generally available. Threshold authority and live KMS/HSM behavior remain later Enterprise targets. See the threat model for Tier-1 limits.
Start here¶
-
Threat model
What TOVIO protects against, who is trusted, where the trust boundary sits, and the residual risks v1 accepts on purpose.
-
Cryptography
The three tiers and the primitives — BLAKE3, AES-256-GCM, X25519, Ed25519, ChaCha20-Poly1305 — and the envelope that ties them together. No deep math.
-
Key management
Where your keys live, why they never enter the synced object store, how recovery keys work, and how rotation protects future content.
-
Compliance
The append-only audit log, the chain of custody implemented for local reads, the SIEM export and archive mechanics (built) versus the production evidence still open, and how to describe TOVIO honestly in HIPAA / SOC 2 programs.
-
Responsible disclosure
Found a vulnerability? Report it privately. Never open a public issue. Here is the channel and what we commit to in return.
The one-sentence model¶
A TOVIO relay or Forge stores protected payloads as ciphertext plus wrapped keys; the storage/API view does not have a recipient secret that unwraps them. Read decryption occurs client-side when an authorized identity has a usable wrapped key. In Tier 1, the Key Authority is still trusted to select the correct recipients, and the service remains trusted for metadata, availability, integrity, administration, and authorized disclosure edges.
What TOVIO does not protect
TOVIO shrinks your exposure; it does not make a fully compromised machine safe. If an authorized person decrypts a file on a machine that is also running malware, that malware can read the now-decrypted file — the same as any encryption system. And anyone who legitimately decrypted a file keeps that plaintext outside TOVIO's control forever; rotation protects only future content. These boundaries are spelled out in the threat model.
How this connects¶
- The conceptual foundation lives in core concepts.
- Day-to-day tasks — protecting a file, rotating a key — are in the guides.
- Agent containment, where the encryption is the boundary, is covered under AI agents.
- Every command, flag, and
TVO-*error code is in the reference.
Specification provenance
These pages summarize the normative security specifications for a working TOVIO. The authoritative,
requirement-coded sources are the threat model, the cryptography specification, and the project's
SECURITY.md. Where a page states a guarantee, it traces to one of those.
Last reviewed September 9, 2026
Suggest an improvement to this page Not for security reports — see disclosure