Security
Protected objects stay bound to recipient keys.
TOVIO is built around a cryptographic permission model. Policy-covered content is encrypted before it enters a tracked snapshot. A holder of only the protected object and wrapped-key metadata cannot recover plaintext without a usable recipient key. Key-authority, endpoint, metadata, public-content, runner, and intentional-disclosure risks remain separate boundaries.
The model
Four implemented boundaries—and where they stop
Recipient keys stay client-side
Supported client profiles keep recipient private keys and unwrapped content keys in the client keystore rather than synced object storage. The Forge still uses serving, signing, and transport credentials; those credentials are distinct from recipient decryption keys.
Protected content remains ciphertext
The implemented Tier-1 snapshot path seals policy-covered content with AES-256-GCM and wraps its DEK to authorized X25519 recipients. A copied protected object remains opaque without a usable recipient key. Repository metadata, public content, runner inputs, and explicitly disclosed agent context have separate trust boundaries and are not covered by that claim.
Agent reads are capability- and key-gated
Within TOVIO, an agent request must pass token scope, operation, and clearance checks and possess a usable recipient key. That boundary does not sandbox other tools or retract plaintext deliberately disclosed to a runner or model.
TOVIO protected reads are tamper-evident
The implemented protected-read paths append signed, hash-chained audit context. That log detects alteration within its covered boundary; it cannot observe a downstream copy after an entitled client intentionally releases plaintext.
In plain terms
Permissions you can prove, not just configure
In most systems, "who can see this file" is a setting on a server you have to trust. In TOVIO it's a property of the bytes themselves. When you mark a path protected, the working copy encrypts it at snapshot time — plaintext never lands in a tracked tree. The policy manifest remains clear-readable so repository readers can see which paths and policy expressions apply; it carries no protected plaintext or unwrapped content key.
Cryptography prevents a holder of only the protected object from recovering plaintext. In Tier-1, the Key Authority is still trusted to compile policy into the correct recipient set; endpoints, administrators, public data, metadata, and intentionally disclosed plaintext remain separate controls. The Tier-2 implementation moves policy enforcement into decryption, but remains private and release-gated.
Primitives
What's under the hood
Boring, well-reviewed cryptography — no novel ciphers. Each does exactly one job.
BLAKE3
Content addressing and the audit hash-chain. Implemented object-store reads and receipt paths verify addressed bytes, while covered audit verification detects chain alteration.
AES-256-GCM
Authenticated encryption of protected file content in the Tier-1 hybrid envelope. Fast, hardware-accelerated, integrity-checked.
X25519
Wraps each protected object's data-encryption key to its authorized recipients. Adding a reader can add a new key wrap; revocation rotates the key, re-encrypts the affected content, and re-wraps the new key for the remaining recipients.
Ed25519
Signs commit/provenance payloads, capability tokens, and other defined authorization records. Signature coverage follows the documented object and operation profile.
TLS 1.3
Secures the sync transport between clients and the Forge, with a channel-bound identity proof on connect.
CP-ABE
The enterprise KA implementation has passed its CP-ABE conformance and internal-review gate, but remains private, default-off at the public client boundary, and not currently available. Threshold/KMS authority, hosted parity, and remaining release evidence stay open.
Responsible disclosure
TOVIO's permission system is security-critical — a bug can expose secrets. If you believe you've found a vulnerability, do not open a public issue. Send it to security@tovio.dev, the addresshttps://tovio.dev/.well-known/security.txt names. Until a PGP key or the repository's private vulnerability reporting is published, reports travel over ordinary email, so keep proof-of-concept material minimal and never include live secrets. The public feedback portal is not a security channel. Check thesecurity disclosure page for current intake status and thethreat model for documented residual risks.