Five pillars. Fifteen requirements. One test.
Every requirement has a stable identifier, a minimum outcome you can test, and a question an ordinary person can ask. If a system cannot meet one, the gap is the finding.
V
Verifiable Provider Blindness
Can the company read it?
Under a declared threat model, the people and systems that operate the service cannot independently obtain protected source data or derived intelligence in plaintext. This covers the whole processing path, including model hosts, infrastructure operators, storage services and subcontractors, not only the company whose name appears on the app. Because metadata can reveal a great deal even when content is protected, residual exposure such as activity timing, compartment, record size, tool use and network signals must be disclosed. "Verifiable" means the claim comes with evidence that outsiders can assess.
No independent provider access
No provider-exercisable key, console, recovery route or side path reveals protected plaintext. Any such route, whatever it is called, fails V1; disclosure does not cure it.
Ask: Could anyone at the company read what my AI knows about me, even in an emergency?
Approved execution and egress
Context reaches only a freshly verified boundary, and cannot leave it or reach an unauthorized recipient through logs, telemetry, tool calls, generated outputs, fallbacks or any other egress route.
Ask: When my AI uses a tool or the internet, where can my information go?
Independently assessable evidence
Threat model, trusted computing base, collusion sets, update authority, residual metadata exposure and known failures are public and reviewable without private data.
Ask: Has anyone outside the company checked these privacy claims?
A
AI–User Dual Custody
Who must agree before it is used?
Routine use of protected shared context requires two separate authorities: the authenticated person and an authorized AI identity, each represented by a share that is not sufficient on its own. The AI identity's authority is exercised through a provider-independent custody service, never through prompts, ordinary memory or model weights. The provider independently controls neither authority. Because that authority is bound to an enrolled relationship, a changed model, runtime or policy cannot silently inherit it. Dual custody never stands between a person and their own original records.
Separate authorization domains
Two separately held, individually insufficient authorities are required; the provider independently controls neither, and the protocol states where plaintext and short-lived keys exist.
Ask: Does using my history require more than the company's say-so?
Bind authority to identity and change control
A changed model, runtime or policy reaches existing context only through a documented, authorized transition naming it a continuation, successor, fork or new participant; nothing inherits authority silently.
Ask: If the company changes the AI I have been working with, will I be told, and asked, before it can access our history?
Preserve access without captivity
The person can always retrieve their own records independently; dual custody governs managed access, never captivity.
Ask: Can I always get my own records back, even if the AI or the company is gone?
U
User-Defined Purpose and Compartments
Is it used only for what I allowed?
People decide the purposes for which their context may be used, and the system enforces those purposes as concrete restrictions on data, operations, recipients, tools and time. A request about subscriptions should not open health records by default. Restrictions travel with the information into summaries and inferences, and consent stays understandable over time.
Narrow authorization
Every grant names its compartments, operations, recipients, tools, duration and execution identity, enforced in code.
Ask: When I ask for help with one thing, can my AI see everything else?
Restrictions follow information
Derivatives carry their sources' restrictions; combined material carries the combined restrictions; reductions are explicit and recorded.
Ask: If my AI learns something from my health records, could that knowledge show up in a conversation about money?
Understandable continuing consent
Active access is visible and closable; grants expire or are reviewed; material changes are shown side by side before they apply.
Ask: Can I see everything my AI is currently allowed to do, and switch it off?
L
Locked Source and Derived Intelligence
Does protection follow what the AI infers?
The protected asset is not only what a person supplies but what the system makes from it: memories, summaries, embeddings, indexes, inferred attributes and personalized adaptations. These derivatives are inventoried with their provenance, can be inspected and corrected, and do not quietly flow into training, analytics, advertising or unrelated human review.
An inventory with provenance
Every retained source and derivative is inventoried with provenance, and the inventory is protected like the content.
Ask: Is there a complete list of what my AI has kept about me?
Inspect and correct the portrait
People can read what is durably held about them, see what is stated, inferred or disputed, and correct it with effect on dependent derivatives; third-party information can be restricted, contested and deleted.
Ask: Can I see what my AI believes about me, and fix what is wrong?
Govern every reuse
No training, analytics, advertising or human review without specific authorization; adaptations are in scope; unremovable influence is disclosed in advance.
Ask: Could what I share be used to train or improve other products?
T
Tamper-Evident Transparency, Transfer and Termination
Can I check it, take it and end it?
Every covered use leaves a private, integrity-protected receipt. A person's history can be exported in a documented package and shown to work in a second environment, with losses reported honestly. Revocation and deletion have declared scope and timing, so ending the relationship is real rather than cosmetic.
Protected and verifiable receipts
Every covered operation produces a private, integrity-protected receipt, and omissions or conflicting histories can be detected.
Ask: Can I see a trustworthy record of every covered access, disclosure, permission change, export and deletion involving my information?
Functional transfer
Export is an authenticated, documented package, proven by import into a second environment, with missing dependencies and behavior changes reported.
Ask: If I leave, can I take my history somewhere else, and will it actually work there?
Scoped termination
Revocation works within a declared delay; deletion reports scope, timing and exceptions across sources, derivatives, keys, backups and caches.
Ask: When I end it, what is actually deleted, and when?
Key terms
Covered operation
Any action that accesses, discloses, exports, imports, corrects or deletes protected material; changes a grant, policy, AI identity or execution environment; or exercises recovery. Computation inside an authorized operation is not a separate one.
AI identity
The authenticated continuity of an AI participant in a relationship, recognized by a provider-independent custody service. The model is part of the execution envelope; the identity is the continuity being authenticated.
Continuity event
A change of model, runtime, policy, custody service or provider. It needs a documented, authorized transition naming the result a continuation, successor, fork or new participant.
Residual metadata
What stays observable when content is protected: activity timing, compartment accessed, record size, tools invoked, location and network signals.
Architecture must match the claim
VAULT mandates no product stack. Each implementation states which claims its architecture can support and publishes what its guarantees depend on.
| Deployment pattern | What it can support | What it must still show |
|---|---|---|
| Hosted AI, provider-held keys | Purpose controls, inventories, receipts, export, deletion | It cannot claim provider blindness or dual custody, and should say so plainly. |
| Local inference on your device | Provider blindness for on-device processing | That client, updates, tools and telemetry hold the boundary; recovery without a provider master key. |
| Remote confidential execution | Provider blindness under a declared hardware trust model | Fresh attestation per operation; transparent updates; review of what approved software does; side-channel limits. |
| Hybrid | Heavier workloads without surrendering custody | Every boundary crossing is visible, authorized and receipted. |
Evidence, not badges
Each requirement is scored on evidence, from 0 to 4. A pillar scores its weakest requirement, and no totals are published: fourteen strong answers cannot cure one provider master key.
Unknown
No evidence, or no control
Assertion
A policy or marketing claim
Documented design
Published, not yet tested
Implemented and tested
Reproducible results, failures reported
Independently verified
External review, conflicts disclosed
A permitted claim
"Provider-blind under VAULT v0.1 at Evidence Level 3 for the health and financial compartments, using configuration X, under threat model Y, assessed October 2026."
Never permitted
"VAULT certified," "VAULT approved," unqualified "VAULT compliant," or any claim about a whole product when only part was tested.