Skip to content

Compliance

TOVIO is built so that "who accessed what, and when" is a first-class, tamper-evident record — not an afterthought bolted on with log shipping. This page distinguishes the audit controls implemented in source from the deployment controls still required for a production compliance program.

Posture, not certification

TOVIO provides core technical controls — cryptographic access enforcement and tamper-evident, signed chain-of-custody logging — that auditable programs depend on. It does not, by itself, make you compliant: certification is about your organization's policies, processes, deployment, and scope. Source/principal/authorization context, commit-linked justification policy, CEF/RFC 5424 export, and signed archive checkpoints are implemented. Production log-source coverage, collector operation, retention-policy validation, and independent assurance remain evidence work.

The audit log

The audit log is an append-only, hash-linked chain of signed records. Each entry references the previous entry's address, and each is Ed25519-signed by the acting identity. Three properties follow directly:

  • Immutable in effect. Removing or altering any entry breaks the hash chain and invalidates a signature. You cannot quietly edit history.
  • Offline-verifiable. tovio audit verify walks the chain with no network and reports the first break, with object context.
  • Replicated. Because entries are content-addressed objects that sync like any other, multiple peers hold the chain. A single tampering relay that omits newer entries is detectable by comparison against an honest peer.

What gets recorded

The audit chain records meaningful security events, including:

Event Recorded when
policy_object_decrypted A protected file is read (decrypted); the signed append succeeds before plaintext is released.
read_denied A token/scope/clearance or final decrypt attempt is refused; recorded best-effort because no plaintext is released.
push / fetch Objects are synced to or from a peer.
branch_create / branch_delete A branch is created or deleted.
policy_change An access policy is modified.
token_issue / token_revoke A capability token is issued to or revoked from an agent.
key_rotate / key_recover An identity key is rotated — the entry roots a new chain segment but names the prior head and the rotated-away identity, so verification continues across the boundary — or a fresh identity is provisioned from recovery material, which cannot claim continuity and starts an unlinked segment.
device_enroll / device_revoke A per-device key is enrolled under, or revoked from, an identity.
obliterate A payload is obliterated (and a tombstone left in its place).

For a local read, the entry names the ciphertext object and logical path/resource plus the local surface. For a token read, the repository identity signs its chain and the record separately binds the effective agent principal and token id; TOVIO does not pretend that the service owns the agent's signing key.

Chain of custody for reads

This is the property regulated programs care about most: TOVIO logs read access to protected files, not just modification.

What the current read record proves

A policy_object_decrypted event is repository-signed after authenticated decryption and before disclosure. It records the signer, effective agent/token when applicable, ciphertext object, path, timestamp, and source context without recording plaintext. The audit schema retains observed peer, device/session, authorization attributes, verified capability-chain context, and justification when the producing edge has authenticated them. A commit-linked policy can require a bounded, trimmed human justification before selected security-sensitive mutations. An absent optional observation is not proof that no device or network source existed; production source coverage must be validated.

Obliteration is visible, never silent

Sometimes you must remove content — a secret committed by mistake, data subject to a deletion request. TOVIO's obliterate removes the payload but preserves the address as a typed tombstone: a read returns a clear "obliterated" result, not a 404 or a corruption error. The obliteration object records the reason, who authorized it, and an authorization proof, and the obliteration is itself an audit event. History removal is therefore an explicit, attributable, logged operation — never a way to silently erase evidence.

SIEM and retention status

The local CLI implements the signed-chain export and archive mechanics; a production compliance program must still configure, operate, and independently validate them:

  • Implemented: tovio audit log --json, summary/show, offline signature/chain verification, and tovio audit export in JSON, CSV, CEF, and RFC 5424 syslog formats. Export can write an atomic file (--output) or use bounded TLS 1.3 delivery (--tls host:port) with the collector verified against the platform CA roots or a pinned certificate (--cert); syslog uses RFC 6587 octet-counting framing.
  • Implemented: tovio audit archive moves entries older than the retention window (--older-than, default 365d; --dry-run previews) behind a signed checkpoint over exact retained-chain boundaries, publishes crash-safely, and resumes post-pointer loose-entry cleanup idempotently.
  • Implemented: the hosted catalog carries its audit-retention entitlement and exposes bounded retention state; catalog-derived history cleanup is separately fail-closed around reachability, legal holds, policy revision, and exact accounting.
  • Open evidence: production collector ingestion, PII review, keychain/power-loss/restore exercises, organization-specific legal retention policy, and proof that every deployed producer supplies the required source context for the assessed scope.
# Atomic local export
tovio audit export --format cef --output tovio-audit.cef

# Certificate-authenticated collector delivery
tovio audit export --format syslog --tls siem.example.com:6514 --server-name siem.example.com

Deployment boundary

The Forge has authenticated audit-chain reads and a validated, secret-reference-only per-organization SIEM configuration surface. The CLI exporter and archive commands are real implementation paths; an activated hosted collector worker, production retention operations, and their evidence remain separate deployment responsibilities and launch gates.

Mapping to control frameworks

The table below maps TOVIO capabilities to the kinds of control families a HIPAA or SOC 2 program assesses. Use it as a starting point for your control narratives, not as a certification.

Control area What an auditor wants What TOVIO provides
Access control Only authorized identities can access regulated data A holder of only a protected payload cannot decrypt it without a usable recipient key. Key issuance/wrapping, endpoint disclosure, repository admission, and hosted authorization remain separate controls.
Audit & accountability A complete, tamper-evident record of access Append-only, signed, hash-linked local chain; protected reads and token denials are emitted at CLI/Node/MCP edges and are offline-verifiable. Exhaustive event coverage remains incomplete.
Access logging / chain of custody Who read what, when, on what basis policy_object_decrypted binds signer, effective agent/token, object, path, time, source context, and recorded authorization basis. Commit-linked policy can require justification for the supported mutation set; each deployment must validate producer coverage.
Encryption at rest Sensitive data encrypted where stored Protected payloads are ciphertext in the object store; supported clients keep recipient private keys and unwrapped content keys in their keystore rather than the synced store.
Encryption in transit Data protected on the network TLS 1.3 protects transport; policy-covered payloads are additionally encrypted before they reach the wire. Public content and metadata have different disclosure boundaries.
Integrity Data cannot be altered undetectably BLAKE3 content addressing plus Ed25519 signatures; every object re-hashed on read and receipt.
Log retention Records kept for a required period Signed archive checkpoints and crash-safe cleanup preserve exact retained-chain boundaries. Hosted entitlements carry an audit-retention floor; production policy, backup/restore, and operational evidence remain the operator's compliance work.
Least privilege (agents) Automation is scoped and accountable Capability tokens scope each managed TOVIO operation by path, lane, operation, lifetime, and clearance; successful managed writes attach server-derived provenance. Host/process sandboxing remains separate.

Honest limits for an auditor

A defensible compliance story is an honest one. State these limits plainly in your control narratives:

Document these in your assessment

  • Tier-1 access enforcement trusts the Key Authority not to mis-wrap. In Team mode, read enforcement is cryptographic against everyone except a dishonest Key Authority, which is trusted (and audited) not to grant access improperly. The unavailable Enterprise threshold design is intended to reduce the single-party version; full policy-at-decrypt enforcement exists in the release-gated Tier 2 implementation, not as a generally available control. See the threat model.
  • Write control is relay-enforced, not cryptographic — a compromised relay accepting an unauthorized write is detectable (no valid proof), not mathematically impossible.
  • Metadata is visible by design — policy labels, recipient sets, object sizes, and the commit-graph shape are not hidden, even though content is.
  • Provenance depends on honest hashing — agent provenance is a tamper-evident attestation under the signing identity's signature, not a proof that the recorded model actually ran.

Assurance roadmap

Independent third-party security review and remediation evidence remain launch gates for the applicable public and commercial surfaces. Tier-2 CP-ABE follows ADR-0234's conformance-suite and documented internal-review gate rather than a separate external-audit prerequisite; that Tier-2 conformance gate has passed, while shipping without an independent cryptographic audit remains an accepted residual risk and the threshold/KMS/HSM key authority and its evidence remain later work. No generally available artifact should be treated as certified or audited. Cite the evidence status, not just the design intent.

Last reviewed September 9, 2026

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