Responsible disclosure

TOVIO's whole reason for existing is to keep secrets secret and enforce access cryptographically. A bug in the crypto or permission layer is therefore not a cosmetic defect — it can expose protected content, leak key material, forge a signature, or let an agent or peer read or write outside its scope. We treat such reports as the highest-priority work in the project, and we want reporting them to be easy and safe.

Never open a public issue for a vulnerability

Do not open a public issue, pull request, or discussion — or post on any public channel — for a suspected vulnerability. Public disclosure before a fix is available puts every user at risk. Report it privately through the channel below.

How to report

Prelaunch intake status

Send reports to security@tovio.dev, a Google Workspace group; reports are accepted there, and https://tovio.dev/.well-known/security.txt names the same address. 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: a vulnerability posted there is taken down without a public reply and the author is contacted privately with this route. Do not substitute a public issue.

This page summarizes the prelaunch policy

The authoritative, canonical policy is the project's SECURITY.md. This page is the user-friendly summary; where the two differ, SECURITY.md governs. Exercising this intake with a test report, recorded in docs/current-state.md, is a release gate.

What to include

A good report lets us reproduce and triage quickly:

• A clear description of the issue and which property it breaks — cite a threat-model property or a REQ-* requirement if you can.
• The affected component, version or commit, and the platform.
• Step-by-step reproduction, a proof of concept, or a failing test.
• The impact as you see it (what an attacker gains), and any suggested remediation.

What not to do

Keep your research safe and lawful

• Do not disclose publicly until we have coordinated a release.
• Do not include live secrets, production credentials, or other people's protected content in your report — synthesize a minimal reproducer instead.
• Do not run tests against infrastructure, repositories, or Forge instances you do not own or have explicit permission to test.

We will not pursue legal action against good-faith security research that follows this policy: testing only systems you control, avoiding privacy violations and data destruction, and giving us a reasonable chance to fix the issue before going public.

What we commit to

Once a verified private channel is published, reports received through it use this response policy:

Stage	Commitment
Acknowledge	Within 72 hours.
Triage	Confirm the issue and assign a severity within 7 days, and tell you whether it is in scope.
Fix — critical	For critical issues (secret exposure, key leakage, signature forgery, enforcement bypass), develop and ship a fix within 90 days of triage — faster when an exploit is in the wild.
Fix — lower severity	Scheduled by severity and communicated to you, typically within one or two release cycles.
Keep you informed	Regular progress updates; we coordinate the disclosure date and any credit with you.

These are maximums, not targets — we aim to move faster, especially on the crypto and permission surfaces. If a fix needs a coordinated upstream change and we cannot meet a timeline, we will tell you why and agree a revised date.

How coordinated disclosure works

1. You report privately; we acknowledge and triage.
2. We reproduce and confirm, write a private regression test that fails without the fix, and develop the fix in private.
3. We agree a disclosure date with you. The default embargo lasts until a fixed release is available; we will not unreasonably delay, and we will not reveal your identity without your consent.
4. We release the fix, publish a security advisory, and credit you (unless you prefer to remain anonymous).
5. Affected users are notified through the advisory channel and release notes, with upgrade guidance and, where relevant, key-rotation instructions.

If a vulnerability is being actively exploited, we may accelerate this and ship an out-of-band release.

For every critical vulnerability, once a fix has shipped and users have had time to upgrade, we publish a public, blameless post-mortem: what the vulnerability was, the root cause, the fix, the regression test or conformance vector added so it cannot recur, and any design changes — including a possible re-evaluation of the threat model.

What is in scope

The most sensitive surfaces — where a bug is potentially critical — are:

• The cryptographic envelope and key handling — anything that lets ciphertext be read by an unauthorized party, lets key material reach the synced store / the wire / logs, or makes a forged signature verify.
• The permission and capability-token enforcement order — anything that bypasses path-scope-before-policy, obtains a clearance-gated key without clearance, escalates a token, or leaks a later-stage fact in a denial.
• Content integrity and addressing — anything that lets a payload not matching its BLAKE3 address be accepted as genuine.
• The audit chain — anything that lets an entry be removed, reordered, or forged without tovio audit verify detecting it.
• Untrusted-input parsers — the object decoder, payload framing, wire frames, the policy parser, and the token/envelope decoder. A panic, an over-read, an unbounded allocation, or an access-granting outcome on malformed input is a security defect.

Lower-severity issues — relay denial-of-service, ergonomics, non-security crashes — are still welcome, just triaged at a lower severity.

What is not a vulnerability

The implemented public profile covers Tier 0 (Solo) and Tier 1 (Team), while V1 publication and independent assurance remain gated. The Tier-2 CP-ABE enterprise KA has passed its conformance and internal-review gate, but remains private, default-off at the public client boundary, and not generally available. Threshold authority and live KMS/HSM behavior remain later Enterprise targets. Several properties you might expect from "cryptographically enforced permissions" are documented Tier-1 limitations — not bugs. Before reporting, please check them, so you don't spend effort on something already acknowledged.

Known Tier-1 limitations — please check before reporting

The following are expected in the Tier-1 profile and are not vulnerabilities (some are reduced only when the release-gated Tier-2 implementation or a later threshold profile is actually deployed). The full list, with reasoning, is in the threat model.

• The Tier-1 Key Authority is trusted not to mis-wrap a key to an unauthorized identity (it is audited, not cryptographically prevented). Tier-2 CP-ABE closes this at decrypt time, but no generally available Enterprise artifact enables it.
• Revocation requires re-encryption, and already-distributed content cannot be un-decrypted — rotation protects only future content. Intrinsic to client-side encryption.
• Write control is relay-enforced via a signature proof, not by encryption — circumvention by a compromised relay is detectable, not mathematically impossible.
• Metadata leaks by design — policy labels are clear (so any client can evaluate them offline), and a Tier-1 relay learns the recipient set, object sizes, and commit-graph shape.
• Agent provenance depends on honest hashing, and a compromised authorized endpoint can read whatever that identity can decrypt — defending a decrypted file from a co-resident process the user trusts is outside TOVIO's boundary.
• A compromised Key Authority can bind a rogue key to an identity. The enrollment authority attests which public key a human, device, or agent identity resolves to, so a compromised authority can enroll an attacker-controlled key until that binding is revoked. Bindings are signed, offline-verifiable, visible in the audit trail, and revocable per device and per agent; a threshold authority (later work), not CP-ABE, is what reduces this.

A report that one of the above "doesn't work" the way full Tier 2 would is expected. A report that an enforcement stage can be bypassed, that a secret leaks outside these documented limits, or that a claimed security property can be broken — that is exactly what we want to hear about.

A note on assurance

Beyond reports, 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 threshold/KMS/HSM authority stays later work and the lack of an independent cryptographic audit is an accepted residual risk. This policy and the threat model are living documents: a confirmed bypass, or any change to the trust boundaries, updates them.

Thank you for helping keep TOVIO and its users safe.

Last reviewed September 9, 2026

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