How per-file permissions actually work

A path covered by a policy is encrypted when it is snapshotted, before it is written to the object store. Plaintext never lands in the tracked tree.

Why this is different from every other VCS

Permissions elsewhere are a server saying no. Clone the repository and the server is no longer in the conversation — the bytes are yours.

In TOVIO the protection is in the bytes. Someone without the key holds ciphertext. It stays ciphertext on their laptop, in a backup, on a stolen disk, and in a Git export. There is no server to bypass because there is no server involved in the decision.

What follows from that

• Cloning is not access. A successful clone tells you nothing about what you can read.
• Revocation is re-encryption. tovio access revoke re-seals HEAD and writes a new commit — it does not just remove a row.
• Granting is prospective. A new recipient starts reading a protected path at its next commit, not retroactively.
• Losing your key loses your data. Support cannot decrypt for you.
• You cannot approve what you cannot read. Review enforces this.

Checking

tovio access check <path>tovio policy show <path>

Finding the commands at all

policy, access, identity, key and device all sit in the Team tier of the CLI, so a bare tovio help does not list them. They are always runnable by name; the tier only affects what the index prints.

tovio help --teamtovio help policy

Filenames are not protected

Policy protects content. Paths, lane names, the policy manifest itself, and the set of recipient DIDs are all clear by design — the manifest is meant to be auditable without a key. This metadata exposure is a documented, accepted limitation of the threat model, not an oversight. Protect the file; do not rely on the filename being a secret.