Permissions

Protect files, decide who can read and write them, look after your keys, and prove who touched what — all without a server in the loop. TOVIO enforces read access with cryptography, not a permission flag a server can be talked out of: a protected file is encrypted, and only identities whose attributes satisfy its policy can obtain the key to read it. Anyone can clone the repository; the math, not an access-control server, keeps the protected content closed.

Permissions implementation status (Phase 1)

The permission layer documented here — policies, the Tier 0/1 encryption tiers, key recovery, and the signed audit log — is Phase 1, which is complete in the source tree. In an authorized source checkout, tovio policy, tovio access, and tovio audit are enforced offline and over TLS: a protected path is encrypted at snapshot, a non-recipient clone gets ciphertext only, and revoking rotates the key. The secret_clearance read-gate is also enforced through the Node/MCP agent edge: protected plaintext reads, diffs, moves, and conflict-side selections gate before key access and append a signed read audit before returning bytes. tovio help --team shows the Team-tier commands your build exposes. TOVIO binaries and packages are not generally available; start with the installation status before following these commands.

Start here

If you have never protected a file in TOVIO, read the pages in order — each builds on the one before.

• Promote a repository

  Turn a Solo repo into a Team repo with tovio identity init. What changes, what does not, and what to do either side of it.

• Write a policy

  Declare a policy on a path so files there are encrypted automatically. The difference between a clear file and a policy object, and how the manifest stays readable to everyone.

• Grant and revoke access

  Enroll an identity and issue its attributes, then remove it. Why a grant is prospective while a revoke rotates immediately, and what revocation cannot do about content already read.

• Manage your keys

  Where your identity keys live (your OS keychain), what they are for, and how to rotate them safely.

• Recover a lost key

  The recovery phrase tovio init generates, and what you must do with it before your first protected commit. Losing your key is data loss unless you escrowed that phrase — start here before you ever need it.

• Check access

  tovio access check <path> --identity <file> names exactly which predicate is unsatisfied — never a bare "denied" — plus the protection indicators in tovio status.

• Read the audit log

  The append-only access log: who read what, what was blocked, and how to verify the log has not been tampered with.

• Permission & review workflows

  The same material as diagrams — clear objects vs policy objects, grant vs revoke, the decrypt path, the land gate, and where agents fit.

How read access actually works

These guides are practical, but two ideas underpin all of them:

• Read access is cryptographic. A protected file is stored as an encrypted policy object. You can read it only if you hold a key wrapped for your identity. Revoking someone cannot delete the plaintext they already decrypted — it rotates the key and re-seals the committed protected state, so everything from that point on is closed to them. This shapes every grant, revoke, and recovery workflow.
• Write access is checked by the relay. Pushing a change to a write-protected path requires a proof that you hold satisfying attributes. Unlike read access, this is enforced when you sync, not by encryption.

To understand why TOVIO is built this way, read the concepts. For the AI-agent side of permissions — capability tokens and scoped access — see the agents guides. For the full security posture and accepted residual risks, see security.

Last reviewed September 9, 2026

Suggest an improvement to this page  ·  Not for security reports — see disclosure