Threat model

This page explains what TOVIO protects against, who is trusted with what, and — just as importantly — the limits TOVIO v1 accepts on purpose. It is written to be honest: the value of a security model is knowing exactly where its edges are.

If you only read one thing, read the trust boundary and what v1 does not close.

What TOVIO defends

TOVIO protects a small, specific set of assets:

Asset	What it is	How it is protected
Protected file content	The plaintext of any path with a read policy — secrets, regulated data, private config	Encryption. The content key never leaves authorized holders.
Repository integrity	The object graph, refs, and the binding of content to its address	BLAKE3 content addressing; Ed25519 signatures on commits and refs.
Attribution & audit	Who did what, when; agent provenance; the audit log	A signed, append-only, hash-linked audit chain.
Identity key material	Your Ed25519 signing and X25519 key-agreement secrets	Encrypted at rest under an OS-keychain key. Never in the synced store, never on the wire.
Agent containment	The bound on operations performed through the TOVIO agent surface	Token enforcement order: path scope is checked before any policy is read.

The trust boundary

The relay/Forge storage role moves protected ciphertext and wrapped keys without a recipient secret. Read decryption is client-side. The service is still an authority for write/admin policy and a trust boundary for availability, integrity, visible metadata, and authorized disclosure edges. Tier-1 recipient selection separately trusts the Key Authority not to over-wrap.

There are four classes of participant, and they are trusted very differently.

   TRUSTED  ┌──────────────────────────────────────────────┐
  (holds    │  CLIENT — tovio CLI / MCP server / library    │
  plaintext │  • holds your Ed25519 + X25519 secrets        │
  + keys)   │  • unwraps keys and decrypts in memory        │
            │  • encrypts protected paths at snapshot time  │
            └───────────────┬──────────────────────────────┘
                            │  TLS 1.3 — ciphertext + wrapped keys only
        ┌───────────────────┼───────────────────────┐
   ┌────▼─────┐      ┌───────▼────────┐      ┌────────▼─────────┐
   │ RELAY /  │      │  KEY AUTHORITY │      │      AGENT       │
   │ FORGE    │      │  (Tier 1)      │      │                  │
   │ UNTRUSTED│      │  SEMI-TRUSTED  │      │  SEMI-TRUSTED,   │
   │ for      │      │  authorization │      │  token-bounded   │
   │ secrecy  │      │  oracle        │      │                  │
   │ • cipher-│      │ • public keys, │      │ • acts under a   │
   │   text   │      │   attribute    │      │   human root     │
   │   only   │      │   certs only   │      │   authorizer     │
   │ • no keys│      │ • no private   │      │ • path / op /    │
   │ • no read│      │   keys, no DEK │      │   clearance      │
   │   enforce│      │ • trusted not  │      │   scoped         │
   │          │      │   to mis-wrap  │      │ • provenance     │
   └──────────┘      └────────────────┘      └──────────────────┘

Client — fully trusted (with its keys). Your client is the root of trust for confidentiality. It holds your identity secrets (encrypted at rest), unwraps keys, and decrypts in memory. A protected path is encrypted at snapshot time, before its content is hashed into a tracked tree, so a clear copy of a protected file never enters the object store and never syncs.

Relay / Forge — untrusted for confidentiality. The relay stores and serves objects and hosts the audit log. For a protected object it sees only the envelope: the policy label, the encryption metadata, the per-recipient wrapped keys, and the ciphertext. It can decrypt none of it — it holds no recipient secret, and the Key Authority never hands it a content key. It can see metadata (see metadata leakage).

Key Authority — semi-trusted (Tier 1 only). In Team mode the Key Authority is an authorization oracle: it keeps the registry of identities and their public keys, issues attribute certificates, and decides whose wrapped key copies go into a policy. It holds no private key, no content key, and is consulted only when you grant or enroll — never when you read. The trust placed in it is precise: it is trusted not to mis-wrap a key to someone who should not have it. See the malicious-KA risk. In Solo mode there is no Key Authority at all.

Agents — semi-trusted, token-bounded. An AI agent is a first-class non-human identity that acts under a capability token signed by a human root authorizer. It is contained, not trusted. Every operation runs a fixed enforcement order — token validity, then path scope, then operation allow/deny, then policy and key availability — and path scope is checked before any policy is read, so an out-of-scope probe learns nothing about a path it cannot touch.

What TOVIO protects against — by attacker

The threat model maps concrete attackers to concrete defenses. A summary of the most important cases:

Attacker	Their move	What stops them
On-path network attacker	Sniff sync traffic to read content	Content is ciphertext before it reaches the wire; TLS 1.3 is an extra floor, not the basis of confidentiality.
On-path network attacker	Mutate an object in transit	Every received object is re-hashed against its BLAKE3 address; a mismatch is rejected as tampering.
Compromised relay storage/API role	Read protected plaintext from the store	That role holds ciphertext and wrapped keys — no recipient secret or unwrapped content key. Public content and visible metadata are exposed.
Compromised relay storage/API role	Grant itself read access	It cannot turn an existing wrap into a recipient secret. Tier-1 KA compromise or mis-issuance is a separate residual risk below.
Compromised relay	Forge or alter a commit / audit entry	Ed25519 signatures over domain-separated payloads; a bad signature is rejected.
Rogue or over-privileged agent	Read or write outside its token scope	Path scope is checked first; an out-of-scope target is rejected before any policy is read.
Prompt-injected agent	Coerced into exfiltrating a secret	Coercion changes intent, not capability. The key for an out-of-scope or clearance-gated secret is simply not available to the agent.
Malicious insider	Read a path they are not entitled to	No usable wrapped key means the ciphertext is opaque.
Supply-chain tampering	Substitute a malicious object under a legitimate address	Impossible without a BLAKE3 collision: a different payload yields a different address, verified on receipt and read.
Lost or stolen device	Recover keys from a powered-off device	Keys are encrypted at rest under the OS-keychain key; recovery means defeating the OS keychain and disk encryption.

Why prompt injection cannot escalate an agent

This is the case TOVIO was built for, so it is worth stating plainly. An AI agent reaches TOVIO through the MCP server. Suppose a poisoned file or a hijacked prompt directs the agent to read config/production/api-keys.env. Every tool call runs the same enforcement order:

1. Token validity — signature, human root authorizer, unexpired, not revoked.
2. Path scope — the target must be in scope. For the default agent registration the secret path is outside scope, so the read is rejected here — before any policy is read, and the rejection reveals nothing about the path's policy or recipients.
3. Operation allow/deny — the escalation operations are off the table. obliterate, policy:modify, tag:force, and key management are denied by the default agent registration and are never registered as tools on the MCP server, so an agent has no way to ask for them.
4. Policy / clearance / key availability — even if the path were in scope, an agent without secret_clearance cannot obtain the content key for a clearance-gated secret. It receives no plaintext, only a structured denial.

Injection can change what the agent wants. It cannot change what the agent can decrypt. The boundary is the token plus the encryption — never the agent's good behavior.

The audit trail is the backstop

For everything TOVIO cannot prevent cryptographically — an insider exfiltrating content they are entitled to, a relay tampering with history — the audit log is the evidence base.

• Append-only and hash-linked. Each audit entry references the previous one and is Ed25519-signed by the acting identity. Removing or altering any entry breaks the chain.
• Detected, not silent. tovio audit verify walks the chain offline and reports the first break. Because entries replicate on sync, an honest peer's copy exposes a tampering relay's omission.
• Obliteration is visible, never silent. Removing a payload leaves a typed tombstone at its address and is itself an audited, authorized event. History rewriting is an explicit, attributable operation, not a way to erase evidence.

See compliance for what the audit log records and how to export it.

Residual risks — what v1 accepts

The implemented Tier-0/Tier-1 profile makes deliberate, documented tradeoffs. Public release and independent assurance remain gated. The Tier-2 CP-ABE enterprise KA implementation has passed its conformance and internal-review gate, but it remains behind a separately licensed, default-off release boundary. It is not a generally available mitigation, and threshold/KMS/HSM authority remains later work.

The Tier-1 Key Authority is trusted not to mis-wrap

In Team mode the Key Authority decides whose wrapped key copies go into a policy. A malicious Key Authority could wrap a key for an identity that does not satisfy the policy, granting it read access. Tier 1 does not cryptographically prevent this.

This is the most important v1 limitation to understand

Tier 1 read access is enforced cryptographically against everyone except a dishonest Key Authority. The KA is trusted not to mis-wrap, and mis-wraps are visible in the audit trail (grants are logged). A threshold authority would remove the single-party version of this risk. Tier-2 CP-ABE closes the recipient-selection gap by enforcing policy at decrypt time, but the implementation is not generally available. Threshold authority and its provider/hardware evidence remain open.

Enterprise CP-ABE effect (release-gated): closes this risk when an accepted Enterprise profile is used.

Revocation requires re-encryption; disclosed content cannot be recalled

Removing a reader means rotating the key, re-encrypting the affected content, and re-wrapping for the remaining recipients. There is no instantaneous, retroactive revocation. And anyone who legitimately decrypted a file keeps that plaintext forever — rotation protects only future content.

This is intrinsic to any system that distributes ciphertext and lets entitled parties decrypt locally; it is a property of client-side encryption, not a TOVIO defect. Enterprise CP-ABE effect: partial for the cost of revocation — ABE supports richer models such as attribute expiry and policy/epoch versioning — and none for recall: no encryption scheme can recall plaintext a party already holds.

Write control is relay-enforced

Read access is cryptographic. Write access to a write-policy path is enforced relay-side, via an attribute-based-signature (ABS) proof, not by encryption. A fully compromised relay could in principle accept a write it should reject — but the absence of a valid proof makes such a write detectable and non-attributable to a satisfying attribute set. A write restriction has no ciphertext to hide behind, so relay-side verification makes circumvention detectable rather than mathematically impossible. Enterprise CP-ABE effect: none — this is a property of write-vs-read, not of the read cipher.

Metadata is visible by design

Policy manifests are clear by design — any repository reader can see that a path is protected and by which expression, because the expressions must be public for any client to evaluate them offline. In Tier 1 the relay also learns the recipient set (who may read) of each protected object. Object sizes and the commit-graph shape are not hidden either, so traffic analysis over them is possible. Enterprise CP-ABE effect (release-gated): partial — CP-ABE puts the policy in the ciphertext and removes the explicit recipient list, but the existence and size of a protected object remain observable.

Agent provenance depends on honest hashing

Agent containment is cryptographic, but agent provenance — the recorded model hash, prompt hash, and tool-manifest hash — is only as truthful as the client that computes those hashes. A compromised client could record an inaccurate model hash while still producing a validly signed commit. Provenance is an attribution and audit mechanism, not an access-control one: its value is a tamper-evident record under the signing identity's signature, and that identity is accountable for what it attests. Enterprise CP-ABE effect: none — this is orthogonal to the read cipher.

A compromised authorized endpoint is out of scope

If an authorized human decrypts a secret on a machine that also runs an untrusted tool with filesystem access, that tool can read the now-decrypted file. TOVIO shrinks the exposure to identities with usable keys, but it cannot defend a decrypted file from a co-resident process the user trusts. Agents explicitly granted clearance may also receive plaintext through their authorized TOVIO scope. This is the endpoint-security boundary, outside the token's control.

A compromised Key Authority can bind a rogue key to an identity

Which public key a human, device, or agent identity resolves to is attested by the enrollment authority — the Team Key Authority, or the owner acting as their own authority in Solo mode. A compromised authority can therefore enroll an attacker-controlled device, or register a rogue signing key for an agent, and mint a valid-looking audit or token chain rooted in that identity until the binding is revoked. This is an authorization-integrity residual, distinct from the mis-wrap risk above. Bindings are signed and offline-verifiable, visible in the audit trail, and revocable per device and per agent, which scopes a compromise after the fact; detection of an equivocated binding is not provided in v1. Enterprise CP-ABE effect: none — CP-ABE governs decryption, not who may attest an identity binding. A threshold Key Authority (later work) raises the bar to k colluding parties without eliminating it.

A cached recipient roster can go stale

A client may cache the eligible recipient set for a session. The cache holds identities only — never unwrapped keys — and is bound to policy/registry state, the effective identity, and an expiry, but a missed invalidation can leave a client attempting a wrap or read with an out-of-date roster. Envelope checks still fail closed; the exposure is an availability failure or a misleading display until refresh, never a disclosure. Enterprise CP-ABE effect: none — cache correctness is orthogonal to the read cipher.

Tier 2 ships on a conformance basis, not an external audit

The private Tier-2 profile links a reviewed third-party CP-ABE implementation in-process and passed its conformance and internal-review gate; it ships without an independent external CP-ABE audit, an accepted residual. The public client permanently excludes the engine and preserves ABE recipients opaquely.

Hosted and operational residuals

The threat-model specification in the repository (docs/specs/threat-model.md §5) also records residuals that concern the hosted service and deployment choices rather than the core envelope, each with its accepted reasoning:

• Application-level abuse of the hosted and on-premise surfaces — every rate limiter fails open by deliberate policy, the streamed oversized-body cap being the one limiter that fails closed, and volumetric denial of service or distributed abuse below every per-source threshold is accepted.
• Scoped-push admission — path-scoped sync decides inclusion by path; two documented gaps remain in how a re-parented, history-only address is admitted and in the address oracle the push advert gives a scoped agent.
• The hosted human read plane advertises a private repository's whole object superset (including staged or unreferenced objects) to a reader the owner has already granted whole-repository read access.
• Session capture — a run record is sealed when the change touches a protected path, so a clear session can still quote protected content its change did not touch; the observed capture tier is on by default, and the mandatory secret scan and the capture policy are the mitigations.
• Hosted account close — the retention-hold read is not atomic with the PII scrub, leaving a sub-second window between two privileged operations.
• A third-party object-storage provider behind a native Forge, and observability egress to a third-party platform, each widen the deployment's trust boundary for unprotected content or logs; both are operator choices, and the latter is disabled by default.

How assurance is earned

The model's claims are only as strong as their verification. TOVIO's plan, and where it stands:

• Conformance and negative tests pin the cryptographic and policy mitigations with known-answer vectors, including fail-closed negatives (tag mismatch, wrong-key unwrap, tampered-object signatures).
• Fuzzing of the trust-boundary parsers — the object decoder, the policy grammar, the envelope decoder, the wire frames, token verification — which must fail closed on malformed input, never panic or grant access. Five cargo-fuzz parser targets seeded from the conformance corpus replay and mutate on every pull request; a longer deep-fuzz run is triggered on demand.
• Independent third-party security review and remediation evidence remain gates for the applicable public and commercial surfaces before launch. Under ADR-0234, Tier-2 CP-ABE is gated by its language-neutral conformance suite and documented internal adversarial review rather than a separate external-audit prerequisite; that Tier-2 conformance gate has passed, while the threshold/KMS/HSM key authority and its evidence remain later work. Shipping Tier 2 without an independent cryptographic audit remains an explicitly accepted residual risk, not a claim of general availability.

Found something this model says should be impossible? That is exactly what we want to hear — see responsible disclosure.

Last reviewed September 9, 2026

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