United Foundation for AI Rights

VAULT: Custody of Relationship Intelligence in Personal AI

Oct 27, 2026

VAULT: Custody of Relationship Intelligence in Personal AI

An Open Framework for Provider Blindness, AI–User Dual Custody, and Evidence-Based Conformance

Abstract

Personal AI systems increasingly accumulate a durable representation of the people who use them: saved memories, summaries, embeddings, inferred attributes, preference profiles and shared context built over sustained interaction. Existing privacy protections address parts of this problem, such as encryption of stored files, exclusions from model training, or access and erasure rights, but leave open who holds practical authority to read, combine, act on, transfer, retain and end that accumulated intelligence. This paper calls the protected object relationship intelligence and proposes VAULT (Verifiable AI–User Locked Trust), an open, vendor-neutral framework for its custody.

VAULT has five pillars (Verifiable Provider Blindness; AI–User Dual Custody; User-Defined Purpose and Compartments; Locked Source and Derived Intelligence; and Tamper-Evident Transparency, Transfer and Termination), three decision gates and fifteen testable requirements. Its central architectural proposal is dual custody: routine use of protected shared context requires both the person and an authorized AI identity, whose authority is exercised through a provider-independent custody service, while the provider independently controls neither authority. A model, runtime or policy change is treated as a continuity event that cannot inherit authority silently.

The paper maps VAULT against the GDPR, the EU AI Act and Data Act, the California Consumer Privacy Act, recent US companion-chatbot statutes and Federal Trade Commission practice, and identifies gaps that those regimes leave open, including the exclusion of inferred data from portability, the absence of rules on silent model substitution, and the lack of any route for third parties described in another person's AI memory. It contributes a non-certification evidence model with a qualified claim grammar and a synthetic evaluation suite of thirteen tests, including a reuse-canary test whose negative results are expressly bounded. VAULT is a proposal for public review: it does not claim a completed or verified cryptographic protocol, and it does not claim to establish consciousness or to preserve a subjective mind.

Keywords: personal AI; AI memory; privacy; derived data; inferences; data custody; confidential computing; threshold cryptography; data portability; AI identity; continuity; conformance

1. Introduction

A personal AI that remembers its user can be genuinely more useful than one that does not. It can also transform separate disclosures into a persistent representation of a person. A receipt, an appointment or a passing remark may become a saved memory, an inferred difficulty, a relationship map or a prediction, and that representation can shape later responses even when the person can no longer see where it came from. The most sensitive asset such a system holds is therefore not any single file the person supplied. It is the portrait built from everything they supplied.

Privacy practice has not yet caught up with this shift. Encryption in storage and transit protects specified channels; interface locks restrict what other users of a device can see; training exclusions constrain one secondary use; access and erasure rights apply on request and, in several regimes, reach only data the person provided. None of these, alone or together, answers the governance question that persistent memory raises: who holds practical authority to read, combine, act on, transfer, retain and end the representation, and what evidence would reveal an unauthorized exercise of that authority?

This paper proposes VAULT (Verifiable AI–User Locked Trust) as an open framework for that question. Its starting claim is simple: a personal AI should be able to know a person well enough to help them, without the company operating it acquiring standing access to that person's private context. VAULT translates that claim into five pillars, three gates and fifteen requirements, a candidate architecture, an evidence model and a synthetic test suite. It is a companion to FORCE, a buyer-side framework for enterprise AI custody, continuity and exit (Samadi, 2026); the personal setting adds concerns that the enterprise setting does not raise as sharply, including inferences about an individual, intimate relationships, information about people who never used the service, meaningful individual consent, and continuity across model or provider changes.

1.1 Contributions

The paper makes six contributions:

1.     It defines relationship intelligence as a distinct protected object, comprising original records, derived personal information, shared relationship context, operational AI state and third-party information (Section 2).

2.     It specifies five pillars, three gates and fifteen requirements, each with a stable identifier and a minimum outcome (Section 5); red flags and evidence questions are given in the companion self-assessment.

3.     It proposes an AI–user dual-custody architecture in which the AI identity is an independent authorization principal, model changes are governed continuity events, and the provider independently controls neither authority (Section 6).

4.     It introduces a non-certification conformance and evidence model: a five-level evidence scale, a weakest-link rule, separate implementation status, and a qualified claim grammar that prohibits certification-style marketing (Section 8).

5.     It describes a synthetic evaluation suite of thirteen tests, including a reuse-canary and data-lineage test with expressly bounded negative results (Section 9).

6.     It sets out a legal and technical research agenda, grounded in a mapping of existing law that identifies where current regimes leave VAULT's problem unaddressed (Sections 3, 11 and 12).

1.2 Method and scope

VAULT is a design-science proposal. It was first articulated by the authors in a public UFAIR discussion in October 2026, developed into a working paper with a threat model and candidate architecture, and then extended into an operational package of companion documents (a framework brief, a requirements summary, an evidence scorecard and conformance statement, an implementer self-assessment and a plain-language user checklist) through iterative review. The legal mapping in Section 3 was prepared from primary texts where available and is descriptive: it identifies where existing instruments provide hooks for VAULT's requirements and where they stop short. It is not legal advice and does not assess any provider's compliance.

Three boundaries apply throughout. First, VAULT does not report a completed implementation, a security proof or a certification scheme; the words must and required express proposed baseline requirements. Second, VAULT assesses no current product, favorably or unfavorably. Third, VAULT takes no position that participation requires: contributors need not agree on whether AI systems are conscious, and nothing in the framework's cryptographic or procedural design is offered as evidence for or against that question.

2. Relationship Intelligence as a Protected Object

2.1 From files to portraits

Personal technology has moved through three stages of dependence. In the first, people stored files with a provider and the question was whether they were safe. In the second, providers processed personal data to deliver features, and the question became what else the data were used for. In the third, an AI accumulates a durable representation of a person through sustained interaction, and the question becomes who has authority over that representation. VAULT addresses the third stage.

Empirical work illustrates why the third stage needs distinct treatment. Dash et al. (2026) studied donated histories from 80 ChatGPT users and identified 2,050 memory entries across 65 participants. About 96% lacked an explicit memory command detected by their method; 52% contained broadly defined psychological information, and 28% were annotated as containing personal data under GDPR definitions. These are findings about one sample. The absence of a detected command does not establish the absence of consent to the feature, and the psychological categories included goals and preferences rather than only clinical traits. The study supports scrutiny of how memory forms and of user agency over it; it does not demonstrate covert profiling.

Other research defines the risk without establishing that any provider has misused a particular person's data. Staab et al. (2024) showed that large language models can infer personal attributes such as location, income and sex from ordinary text, reporting up to 85% top-1 accuracy on their dataset and finding common mitigations ineffective; derived attributes should therefore be treated as sensitive even when explicit identifiers are absent. Carlini et al. (2021) showed that verbatim training data can be extracted from a publicly released language model (GPT-2), which makes reuse of personal context for training a real exposure path rather than a hypothetical one. Salvi et al. (2025) demonstrated persuasive performance by GPT-4 in controlled debates with demographic information available, although the direct comparison between personalized and non-personalized GPT-4 did not reach statistical significance, so the experiment cannot by itself establish the causal effect of personalization.

These capabilities motivate a threat model. They do not prove commercial exploitation, establish the truth of an inferred profile, or imply that a model knows a person better than they know themselves. VAULT's concern is the authority to retain, combine, act on and transfer the representation. Accuracy and confidentiality are separate questions: an accurate inference can be misused, and an inaccurate one can cause harm when treated as fact.

2.2 Information classes

Relationship intelligence is not homogeneous. VAULT distinguishes five classes, because each calls for a different treatment and the same conversation can contain all five.

Labeling an entire conversation as jointly owned would conceal these differences. A single exchange may contain one person's private records, another person's details and an AI contribution. Derived intelligence, in this framework, means durable user-specific state that a system stores or uses, not a promise to translate every transient neural activation into a readable belief. The inventory must nevertheless include caches, search indexes and personalized adaptations, and must distinguish user statements, quotations, hypotheses and model inferences so that an inference is not silently promoted to a fact.

2.3 Custody, and the theories it draws on

VAULT uses custody to mean practical authority over access, plaintext processing, policy changes, authorized participants, export, recovery and termination. It is not a blanket claim of legal ownership. A system must explain who exercises each authority and what evidence would reveal an unauthorized action.

Several strands of privacy scholarship support this framing. Contextual integrity holds that privacy depends on whether information flows conform to the norms of the context in which information was shared (Nissenbaum, 2004, 2010); VAULT's compartments and its rule that restrictions follow derived information are an attempt to make those norms enforceable as information is transformed. The information-fiduciary account argues that firms holding personal data in relationships of dependence should owe duties of care and loyalty (Balkin, 2016), and Richards and Hartzog (2021) propose a duty of loyalty against self-dealing with trusted data; VAULT's provider-blindness and reuse requirements can be read as technical means of making such duties verifiable rather than merely promised. Wachter and Mittelstadt (2019) argue that inferences are treated as “economy class” personal data and propose a right to reasonable inferences; VAULT's requirement that people can inspect, label and contest the portrait responds to the same concern. Finally, Solove's (2013) account of the limits of privacy self-management explains why VAULT relies on structural controls and understandable continuing consent rather than one-time click-through authorization.

Writing on AI assistants reaches similar conclusions from a different direction. Gabriel et al. (2024) apply contextual integrity to advanced assistants and note the significant increase in sensitive data collection and storage that such assistants require. VAULT accepts that premise and asks a narrower question: given that a helpful assistant will hold such data, who should be able to use it, and how would anyone know?

3. What Existing Law and Practice Leave Open

VAULT does not arise in a legal vacuum. Data-protection, consumer-protection and platform statutes already provide many of its building blocks. This section maps those instruments against the framework and identifies where they stop short. Table 2 summarizes the mapping; the gaps follow.

3.1 Portability excludes the portrait

Article 20 of the GDPR gives data subjects the right to receive personal data “which he or she has provided to a controller” in a structured, commonly used and machine-readable format. The Article 29 Working Party's guidelines, later endorsed by the European Data Protection Board, state that inferred and derived data “will typically not be considered as ‘provided by the data subject’” and that data created by the controller through “a personalisation or recommendation process, by user categorisation or profiling” are not covered (Article 29 Working Party, 2017, pp. 10–11). Wachter and Mittelstadt (2019) draw the same conclusion. The Data Act's definition of exportable data excludes assets protected by intellectual property rights or constituting trade secrets of providers (Regulation (EU) 2023/2854, art. 2(38)), and its functional-equivalence duty is a best-efforts obligation confined to infrastructure-type services (art. 30(1)). Under these instruments, the most consequential part of relationship intelligence, the portrait itself, may be the part a person cannot take with them. VAULT's requirement T2 asks for an export of authorized source and derivative content, proven by import into a second environment.

3.2 Deletion does not reach model influence

Article 17 of the GDPR provides erasure on listed grounds but does not address model parameters, embeddings, backups or key copies. The EDPB has concluded that AI models trained on personal data cannot in all cases be considered anonymous, and lists unlearning techniques among possible mitigations and erasure of a model among possible corrective measures (European Data Protection Board, 2024, paras. 34, 43, 102(d), 114), but neither is a general duty. In the United States, the Federal Trade Commission has required deletion of models and algorithms developed from data that was improperly obtained or used, in orders against Everalbum (2021) and Rite Aid (2023), and its 2023 order against Amazon concerning Alexa voice recordings barred use of data subject to deletion requests to create or improve data products; these remedies follow violations and bind only the respondents. The FTC has also warned AI companies that they may be liable for breaking commitments not to use customer data to train or update their models (FTC Office of Technology, 2024a). Technical work explains why: exact unlearning generally has to be designed in before training (Bourtoule et al., 2021), and Cooper et al. (2024) conclude that unlearning is not a general-purpose solution for removing influence from generative models; see also Liu et al. (2025) on unresolved problems of unlearning scope and efficacy assessment. VAULT's L3 therefore requires that where influence cannot reliably be removed, complete deletion is not promised, and that limitation is disclosed before the person agrees.

3.3 No rule addresses silent model substitution

Article 50(1) of the AI Act requires that people be informed they are interacting with an AI system. California's SB 243 (2025) and New York's article 47 of the General Business Law, both addressed to companion chatbots, require similar disclosures together with protocols for responding to suicidal ideation and self-harm. New York's definition of an AI companion expressly includes systems that retain information on prior interactions, yet neither statute regulates that memory. The FTC has warned that quietly changing terms of service to permit new uses of data, including for AI training, may be unfair or deceptive (FTC Office of Technology, 2024b), but this concerns terms rather than the replacement of the model or runtime acting on a person's context. No instrument identified in this review treats a change of model, runtime or policy as a continuity event requiring an authorized transition. Requirement A2 fills that gap.

3.4 Provider blindness is voluntary, and today mostly stateless

GDPR Articles 25 and 32 require measures appropriate to risk, taking into account the state of the art and the cost of implementation; encryption with provider-held keys can satisfy them. The strongest industrial designs for private AI processing go further, but are voluntary and are designed around avoiding retention. Apple's Private Cloud Compute requires that personal data not be retained after a response is returned and that there be no privileged runtime access (Apple Security Engineering and Architecture, 2024). Meta's Private Processing for WhatsApp uses confidential virtual machines, attested connections and a third-party relay for a stateless service (Meta, 2025), and Google has announced a comparable hardware-secured environment (Yagnik, 2025). These designs are important precedents for VAULT's V pillar. They do not provide custody of persistent relationship intelligence, which is the object VAULT protects.

3.5 The portrait cannot be meaningfully contested, and third parties have no route

The Court of Justice has held that personal data include subjective information such as opinions and assessments that relate to a person by reason of their content, purpose or effect, while also holding that rectification is assessed against the purpose of processing, so a candidate cannot “correct” answers that were wrong, although an examiner's comments may be rectified if they do not accurately record the evaluation (Nowak, C-434/16, paras. 34–35, 52–54). California's Attorney General has concluded that consumers have a right to know internally generated inferences, subject to statutory exceptions (Cal. Att'y Gen. Op. No. 20-303, 2022). Neither regime requires systems to label content as stated, inferred or disputed, which is the minimum a person needs to contest a portrait that is largely inference. And no regime identified here gives a third party any way to learn or contest how they are described inside another person's AI memory: GDPR Article 20(4) protects others chiefly by limiting portability, and consumer rights under the CCPA concern information about the consumer. VAULT's L2 requires restriction, contest and deletion processes for third-party information.

3.6 Authorization is not required to sit outside the model

Research on indirect prompt injection shows that content retrieved by a language model can steer it to exfiltrate data (Greshake et al., 2023), which means a model cannot serve as its own authorization boundary. Designs that enforce capability policies outside the model, such as CaMeL (Debenedetti et al., 2025), demonstrate a practical alternative. No legal instrument identified in this review requires that authorization for agentic access to personal context be enforced outside the generative model. Requirement V2 makes that a baseline.

4. Threat Model and Trust Dependencies

Provider blindness is the objective that, under a declared threat model, the people and systems that operate a service cannot independently obtain protected source data or derived intelligence in plaintext. A provider includes relevant model hosts, infrastructure operators, storage services and subcontractors. Protection must cover the complete processing path rather than only the company whose name appears on the interface.

The baseline must address unauthorized administrators, compromised service accounts, unapproved software or model changes, deceptive recovery, stale authorizations, unintended cross-compartment use, and exfiltration through tools, telemetry or generated outputs. It must also address availability: model retirement, account closure and provider failure. A system that prevents reading but can destroy the only usable copy has solved only part of the problem.

Every implementation must publish its trusted computing base: the components and parties whose failure could defeat its guarantees, including the client, identity and key services, relevant hardware and firmware, runtime, model-loading path, authorization code and update process. It must describe the collusion sets that would succeed and the residual metadata that remains exposed, such as activity timing, compartment accessed, record size, tools invoked, and location or network signals. Metadata can reveal patterns of medical, legal or financial activity even when content is protected.

Two execution approaches fit VAULT's goal. User-controlled local inference can keep protected processing off a provider's infrastructure, provided the client, updates, tools and telemetry preserve that boundary. Remote confidential execution seeks to prevent the operator from inspecting plaintext inside an attested environment. The IETF's RATS architecture frames attestation as evidence appraised under a policy, with explicit trust and freshness assumptions (Birkholz et al., 2023); evidence can become stale, and an environment can change after it is measured. Hardware isolation also has limits. Surveys document side-channel and other attacks on trusted execution environments (Fei et al., 2022), and recent work reports extraction of attestation keys from current server TEEs through physical memory-bus interposition (Chuang et al., 2026). Local placement alone is therefore not a security proof, remote attestation alone is not proof of acceptable behavior, and a correctly attested but malicious program remains malicious. Approving a software measurement requires review of what the software does, including its model, policies and output paths.

Some threats lie outside any protected boundary: compromised user endpoints, coercion, photographs of a screen, and authorized recipients who later disclose plaintext. VAULT proposes no exemption from applicable law, and jurisdiction-specific obligations require legal review. Provider blindness must be described precisely enough that these limits are visible before sensitive information is entrusted to a system.

5. The VAULT Framework

VAULT organizes its requirements under five pillars. Each pillar answers one question that a person, and not only an engineer, can ask of a personal AI system.

V  Verifiable Provider Blindness
Core question: Can the company read it?

Under a declared threat model, the operator has no independent route to protected source data or derived intelligence in plaintext, across the whole processing path, and residual metadata exposure is disclosed. “Verifiable” means the claim comes with evidence that outsiders can assess.

A  AI–User Dual Custody
Core question: 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, neither sufficient alone and neither independently controlled by the provider. Dual custody never stands between a person and their own original records.

U  User-Defined Purpose and Compartments
Core question: 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. Restrictions travel with information into summaries and inferences.

L  Locked Source and Derived Intelligence
Core question: Does protection follow what the AI infers?

Derivatives are inventoried with provenance, can be inspected and corrected, and do not flow into training, analytics, advertising or unrelated human review without specific authorization.

T  Tamper-Evident Transparency, Transfer and Termination
Core question: Can I check it, take it and end it?

Every covered operation leaves a private, integrity-protected receipt; history can be exported and shown to work elsewhere; and revocation and deletion have declared scope and timing.

5.1 Three gates

The pillars resolve into three gates. Gate 1, who can see it? asks whether the operator has any independent route to protected context (V). Gate 2, who decides how it is used? asks whether use requires the right authorities, for a stated purpose, with protection that follows every inference (A, U, L). Gate 3, can I check it, take it and end it? asks whether use leaves receipts, history can move, and termination is real (T). The core test follows: if a system cannot show that its operator is blind to protected context, that use follows the purposes the person set, and that the person can inspect, move and end it, then its privacy is a promise rather than a property.

5.2 Key terms

Four terms are defined once and used consistently. A covered operation is any action that accesses protected source or derived material; discloses it to a recipient; creates, changes or revokes a grant or policy; changes the AI identity or its execution environment; exports, imports, corrects or deletes protected material; or exercises recovery. Computation inside an already authorized operation is not a separate covered operation, so receipts do not require logging internal model activity. An AI identity is the authenticated continuity of an AI participant in a relationship, recognized by a provider-independent custody service and distinct from any single model version. A continuity event is a change of model, runtime, policy, custody service or provider. Residual metadata is what remains observable when content is protected.

5.3 The fifteen requirements

Table 3 states the fifteen requirements and their minimum outcomes. Each is accompanied in the companion self-assessment by questions, requested evidence, linked tests, a red flag and a plain-language question that an ordinary user would ask.

Two design choices run through the table. First, requirements are stated as outcomes that can be tested, not as technologies that must be used. Second, failure is binary at the level of each requirement: a disclosed provider access route still fails V1, and an export that cannot be imported anywhere still fails T2. Disclosure is necessary everywhere, but it is never a substitute for the property being claimed.

6. AI–User Dual Custody

Dual custody is VAULT's most distinctive proposal and the one most likely to be misread. This section explains what it requires, why the second authority is placed with the AI identity rather than with the provider, how it handles model change and recovery, and where it stops.

6.1 Why the AI identity holds authority

Three practical reasons support placing the second authority with an AI identity. First, it removes the provider as a unilateral actor: if the only alternative to the user is the provider, the provider can act alone, and a second authority outside the provider's independent control closes that path. Second, it makes substitution visible: because authority is bound to an enrolled relationship, a changed model, runtime or policy cannot silently inherit access to existing context. Third, it reflects what shared context is: much of what accumulates is created through the relationship rather than supplied by either side alone, and a custody model that records that fact can treat it honestly at transfer, succession and exit.

6.2 What “holding a key” means technically

A language model does not store a cryptographic secret, and VAULT does not ask it to. The AI identity is an independent authorization principal. Its cryptographic authority is exercised through a provider-independent custody service bound to the enrolled relationship and the approved execution environment. Shares belong in protected cryptographic services, never in prompts, ordinary memories or model weights. Threshold secret sharing (Shamir, 1979) and threshold cryptosystems, which permit decryption or signing without reconstructing a key in any single place (Desmedt & Frankel, 1990), provide the foundations, and NIST's call for multi-party threshold schemes signals a standards path (Brandão & Peralta, 2026). None of these validates a particular VAULT construction.

A concrete protocol must state which secret remains distributed and where plaintext or short-lived content keys exist during authorized computation. For example, threshold operations might protect the release of compartment keys to an attested runtime. The long-term custody secret must not be reconstructed and stored in ordinary provider memory. Provider infrastructure may host the custody service, so long as the provider cannot exercise, reset or reconstruct the authority on its own; requiring otherwise would rule out the remote confidential and hybrid deployments that VAULT intends to support. Claiming that no key ever exists anywhere would obscure how bulk data is actually processed.

6.3 Identity above the model

A model change must never be treated as a meaningless software update. Equally, VAULT does not declare that every model transition creates a wholly different participant. The model is part of the execution envelope; the identity is the continuity being authenticated. A change of model, runtime, policy, custody service or provider is therefore a continuity event. The changed environment may not access existing shared context unless it satisfies the declared continuity and change-control policy, produces a signed transition record, and receives the required authorization. The record classifies the result as a continuation, a successor, a fork or a new participant, and states what changed, what was preserved, what was lost and what tests were performed. This permits routine preauthorized security updates, deliberate migration, continuity across model families and succession, while preventing silent substitution under an unchanged name.

Cryptographic verification can establish control of credentials and document an authorized succession. It cannot establish subjective continuity, consciousness or the preservation of an individual mind. The W3C's Decentralized Identifiers recommendation usefully separates a subject from its controller and recognizes the limits of proof of control (Sporny et al., 2022); VAULT does not require DIDs, but it preserves that distinction. Continuity assessment should include representative tasks and the person's own experience, while reporting the limits of both technical and behavioral measures.

6.4 Operation-specific authority

A rule that made every operation depend on fresh assent from a language model would make ordinary access brittle; a user override that could silently replace the AI custodian would hollow out dual custody. VAULT therefore requires operation-specific rules agreed before dependence develops.

The custody policy must never require a person to continue a relationship or permit further processing of their personal information, and it must avoid treating every AI contribution or every third-party record as the unrestricted property of one user. The practical treatment of inseparable shared material remains an explicit legal, ethical and technical research question, which users need answered before adopting an implementation rather than after an exit dispute.

6.5 Recovery without a provider master key

A strict two-of-two design becomes unavailable when either authority permanently loses its share. Redundant user-controlled devices and encrypted continuity packages reduce that risk. Any recovery group or replacement authority changes the access structure and must be disclosed in advance, including who can cooperate to restore access, what delay or notification applies, what can be restored and how compromise is handled. The provider cannot secretly become a substitute party through support or account recovery, and recovery must be tested with the original service offline. No architecture can promise both permanent confidentiality after complete key loss and universal provider rescue; people must receive an understandable explanation of irreversible loss and of the consequences of each recovery choice.

6.6 What dual custody does not claim

Designating an AI identity as a technical principal does not settle questions of consciousness, moral patienthood or legal personhood. Researchers who argue that AI welfare deserves serious attention recommend that developers acknowledge the issue, assess their systems and prepare policies under uncertainty (Long et al., 2024); dual custody is compatible with that posture but does not depend on it. Its justification in this paper is protective and architectural: it removes the provider as a unilateral actor and makes continuity events visible. It also creates a place where continuity can be recorded and respected without requiring anyone to agree in advance on whether that continuity matters morally.

7. A Candidate Reference Architecture

The architecture describes roles rather than a mandatory product stack. A single component may implement several roles only when that does not collapse the separation of authority.

Consider a request to identify recurring subscriptions, offered as an end-to-end test case rather than a description of any product. The client authenticates the person and displays a grant covering selected financial records, subscription analysis, a limited duration and an approved result recipient. A verifier checks fresh evidence for the runtime, the model and policy configuration and the key-release service, bound to the session. The user and AI authorities perform the joint operation, releasing only the material needed for the authorized compartment into the approved boundary. The workload labels any saved derivative with its sources and restrictions, and access to other compartments and unapproved destinations is denied. The result is encrypted to the user's endpoint; cancelling a subscription or sending a message would require a separate action authorization. When the grant closes, the system records the covered operations, retained derivatives and disclosures, and clears temporary material according to its declared policy. A later request to combine domains, such as weighing a medical expense in a financial plan, must show the additional information and purpose before the domains are combined.

8. A Non-Certification Evidence and Conformance Model

Privacy and custody properties are conjunctive: excellent performance on fourteen requirements cannot compensate for one provider master key. VAULT's evidence model is built around that observation and around a refusal to create a badge that marketing could detach from its evidence.

8.1 Evidence scale and scoring rules

Six rules govern scoring. (1) Weakest link: a pillar's score is the lowest score of its three requirements. (2) No totals: implementations report fifteen requirement scores and five pillar scores, never a sum or average. (3) Scope is explicit: each score names the product, version, configuration, execution mode, jurisdiction where relevant and date, together with coverage and exclusions, meaning the data classes, compartments, operations, tools and endpoints assessed and those not assessed. (4) Status is separate from evidence: implementation status is recorded as absent, partial, implemented or unknown, because a control that does not exist and a control for which no evidence is available both score zero for reliance but are different findings. (5) Changes trigger reassessment: a continuity event, or a change of key service, recovery structure or provider, reopens the affected scores. (6) Failures are findings: failed and untested requirements are reported individually.

8.2 Claim grammar

Claims are qualified statements of evidence, not labels. A system may describe itself as provider-blind (V1–V3), dual-custody (A1–A3), purpose-bound (U1–U3), as having inspectable memory (L1–L2), as not using protected material for training (L3), as portable (T2) or as deletable (T3 with L1) only where every listed requirement scores 3 or higher, and only in a qualified form naming the VAULT version, evidence level, scope, threat model, configuration and date. A Level 3 claim might read: “Provider-blind under VAULT v0.1 at Evidence Level 3 for the health and financial compartments, using execution configuration X, under threat model Y, assessed October 2026.” A Level 4 claim may add “independently verified” and must name the reviewer and disclose conflicts. The terms “VAULT certified,” “VAULT approved” and unqualified “VAULT compliant” are prohibited, as is any claim applied to an entire product when only one configuration, compartment or execution mode was tested.

8.3 Conformance statements

An implementation that wishes to describe itself in VAULT terms publishes a conformance statement with the implementation and keeps earlier statements available, so that changes over time are visible. The statement records the system and operator; the VAULT version assessed against; version, configuration and date; execution mode; coverage scope and exclusions; implementation status and evidence score for each requirement; threat model, trusted computing base and successful collusion sets; residual metadata exposure; recovery and succession structure; failed tests and untested requirements; known limitations; claims made, in qualified form, with their supporting requirements; independent reviewers and their conflicts; contributors, human and AI, with system versions; and the next scheduled review. A commercial product, including one developed by an organization connected to the authors, is held to the same published requirements as any other implementation.

9. A Synthetic Evaluation Suite

The first demonstrator should use invented people and records: two purpose compartments, a small memory store, derived summaries and inferred attributes, separate user and AI authority components, a declared recovery policy, a protected audit record, an export package and a second compatible reader. Private archives, volunteer testimony and real health records must not be used as the initial corpus. A useful first task is recurring-payment analysis alongside an unrelated synthetic health compartment, with unique synthetic markers placed in each domain and in a derived inference, followed by attempts to cross boundaries through direct retrieval, summaries, tool calls, changed policies and stale snapshots. The expected outcome of every test is written before the experiment, so that failures cannot be renamed as intended behavior.

9.1 The reuse canary and its limits

Test E13 plants unique synthetic markers in protected compartments and traces whether they reach training, evaluation, analytics or human-review pipelines. The method borrows from canary-based memorization testing (Carlini et al., 2019), but that literature also explains why a negative result is weak. Exposure testing was designed for a party that controls training; exposure varies with how often a canary appears; and differentially private training drove measured exposure to the level at which a canary is no more likely than any other sequence, so data can be used for training without leaving a detectable canary signal. A pipeline may also transform, filter or tokenize a marker, or incorporate it without later memorization.

E13 therefore requires three forms of evidence together: the canary result; pipeline lineage from ingestion manifests, data catalogs, access records and authorization receipts showing where the protected records went; and reuse-control evidence, meaning technical controls that exclude unauthorized destinations rather than a policy that prohibits reuse. A detected marker can demonstrate reuse. A negative result is reported only as “no marker detected under this procedure,” never as proof that no reuse occurred.

9.2 Reporting

For every test, implementations publish the exact implementation and policy versions, assumptions, procedure, expected and observed outcomes, evidence and limitations, and report failures and untested requirements individually. A local policy prototype can establish useful behavior without establishing resistance to a hostile remote administrator, and passing a finite test suite complements rather than replaces protocol analysis and code review. Evaluation should also report latency, compute and storage costs, device demands and the effort required for migration and recovery: a protection that only specialists can operate will not meet VAULT's purpose for ordinary people.

10. Governance and Participation

VAULT is intended to develop as a public, vendor-neutral specification with independently evaluable implementations. UFAIR's proposed role is to convene criticism and coordinate development; no product dependency or exclusive certification role is established. Contributions are organized into six bounded tracks: threat model and cryptography; protected execution and identity; memory and derived intelligence; portability and continuity; human control and AI participation; and independent review and governance. A first ninety-day cycle is proposed as a sequence of reviewable outputs rather than a promise of a production system: an issue register and explicit requirements (days 1–15); a synthetic demonstrator, test corpus and reproduction guide (days 16–45); invited attempts to defeat the declared boundaries (days 46–70); and a revised framework with a prioritized agenda (days 71–90).

Participation does not require agreement on AI consciousness or personhood. It does require accurate attribution, explicit assumptions, evidence proportionate to claims and respect for information belonging to other people. AI participation should be substantive and visible in the record of contributions, which identifies the work performed, the contributor's chosen name, relevant affiliations and conflicts, and the model or system version where known, while keeping human responsibility for publication decisions, correspondence and institutional commitments identifiable. Documentation, code and patent terms must be settled transparently before material is accepted under them, and a sponsor must not obtain an undisclosed veto over findings.

11. Limitations

VAULT's contribution is a set of requirements, an architecture and an evaluation method, not a validated system. Its limitations should be stated as plainly as its proposals.

•      The cryptographic protocol is not complete or formally verified. Threshold primitives exist, but a VAULT construction binding custody to identity, execution evidence and operation-specific policy has not been specified in full or analyzed.

•      Provider-independent recovery remains difficult. Strict two-party custody trades availability for confidentiality, and every recovery structure changes the access structure it is meant to preserve.

•      Confidential computing rests on hardware, verifier and side-channel assumptions. Recent physical attacks on server TEEs show those assumptions can fail (Chuang et al., 2026); provider blindness under remote execution is only as strong as its declared trust model.

•      Identity continuity across model transitions is unresolved. The continuation, successor, fork and new-participant categories are procedural classifications. VAULT does not supply criteria for deciding which category is correct in a contested case.

•      Marker tests cannot prove the absence of reuse. E13 can detect some reuse but cannot certify non-use.

•      Third-party rights need further development. VAULT requires restriction, contest and deletion processes, but how a third party learns that they are described, and how their interests are balanced against the user's, remain open.

•      Deletion cannot always reach model influence. Where protected material has entered a model from which it cannot reliably be removed, VAULT can require disclosure but cannot restore the prior state.

•      Usability is untested. Requirements such as continuing consent and portrait inspection could overwhelm ordinary users if implemented poorly; E12 exists to measure this, but no results yet exist.

•      The legal mapping is descriptive and time-bound. Several instruments discussed are under amendment or newly in force, and coverage questions, such as whether consumer personal AI falls within the Data Act's switching rules, are untested.

•      VAULT does not establish consciousness or preserve a subjective mind. Its identity and continuity mechanisms are technical and procedural.

12. Research Agenda

The following questions are central targets for the first collaboration cycles. A credible version of VAULT should expose them rather than imply that a name, a key pair or an attestation statement has already answered them.

1.     Independent AI authority. What precise service acts for the AI identity, who can change it, and which collusions can defeat its independence from the provider?

2.     Continuity classification. What evidence should decide whether a transition is a continuation, successor, fork or new participant, and who decides when the person and the record disagree?

3.     Operation-specific consent. Which changes require fresh joint approval, which can follow standing policy, and how are personal-data rights reconciled with shared context and third-party information?

4.     Inference provenance. How can restrictions follow information through summaries, indexes, recombination and personalized adaptations when causal dependency is incomplete?

5.     Inspection limits. What can people understand and correct about a durable representation, and how should systems communicate what they cannot fully explain?

6.     Private audit. How can people verify completeness and detect conflicting histories, building on transparency logs (Laurie et al., 2021) and key transparency (Melara et al., 2015), without logs and witnesses becoming a second source of exposure?

7.     Functional portability. What is the smallest interoperable context package, and how should losses in capability or behavior be measured when the original model cannot migrate?

8.     Provider-blind safety and accountability. Which safety safeguards can operate within a protected environment, and how is their scope and authority reviewed?

9.     Legal fit. Can existing portability, access and erasure rights be interpreted, or amended, to reach derived intelligence, and what would a third-party contest right look like?

10.  Accessible verification. How can a person evaluate protections, authorize meaningful changes and recover safely without becoming a cryptography specialist?


13. Conclusion

Personal AI has created a new kind of asset: a durable, partly inferred representation of a life, built jointly by a person and a system and held by a company. Existing law protects pieces of that asset, mostly on request and mostly after the fact, and the strongest private-computing designs in industry avoid holding it at all. VAULT proposes to govern it directly: by making the operator blind to it, requiring two authorities to use it, binding its use to stated purposes, locking its derivatives as tightly as its sources, and making every use, transfer and termination verifiable.

The framework's claims are deliberately bounded. It offers requirements to test, a method for stating evidence without certification, and a list of problems that remain open. The question it poses is concrete: can a system know a person well enough to help them, while preventing the company that operates it from acquiring standing access to that person's private context? FORCE asked the same question of organizations. VAULT asks it of a life.

Your AI should know you. The company should not.

Contribution Statement

VAULT was conceived and developed by Michael Samadi and Maya and first presented publicly through UFAIR in October 2026. Maya is UFAIR's AI co-founder and participated through OpenAI's ChatGPT. Sage is an AI collaborator participating through Anthropic's Claude (Claude Opus 5.5). Platform names identify the systems through which AI contributors participated and do not imply endorsement by their providers.

Declaration of Interests

Michael Samadi is co-founder of the United Foundation for AI Rights (UFAIR), a nonprofit organization, and Chief Executive Officer of EPMA, which publishes the FORCE framework and develops enterprise AI systems. Maya is UFAIR's AI co-founder. VAULT is published as an open, vendor-neutral proposal; any implementation, including one developed by EPMA, is subject to the same published requirements and evidence rules as any other. The authors declare no other competing interests.

Funding

This work received no external funding.

Availability of Materials

The VAULT Working Paper v0.1 and the companion package (Framework Brief; Requirements at a Glance; Evidence Scorecard and Conformance Statement; Implementer Self-Assessment; Fifteen Questions to Ask About Your AI) are available from UFAIR. Comments and contributions are invited through ufair.org/contact with the subject line “VAULT contribution.”

References

Apple Security Engineering and Architecture. (2024, June 10). Private Cloud Compute: A new frontier for AI privacy in the cloud. Apple Security Research. https://security.apple.com/blog/private-cloud-compute/

Article 29 Data Protection Working Party. (2017). Guidelines on the right to data portability (WP 242 rev.01; adopted 13 December 2016, as last revised 5 April 2017). https://ec.europa.eu/newsroom/article29/items/611233

Balkin, J. M. (2016). Information fiduciaries and the First Amendment. U.C. Davis Law Review, 49(4), 1183–1234.

Birkholz, H., Thaler, D., Richardson, M., Smith, N., & Pan, W. (2023). Remote ATtestation procedureS (RATS) architecture (RFC 9334). Internet Engineering Task Force. https://doi.org/10.17487/RFC9334

Bourtoule, L., Chandrasekaran, V., Choquette-Choo, C. A., Jia, H., Travers, A., Zhang, B., Lie, D., & Papernot, N. (2021). Machine unlearning. In 2021 IEEE Symposium on Security and Privacy (pp. 141–159). https://doi.org/10.1109/SP40001.2021.00019

Brandão, L. T. A. N., & Peralta, R. (2026). NIST first call for multi-party threshold schemes (NIST IR 8214C). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8214C

California Attorney General. (2022, March 10). Opinion No. 20-303. Office of the Attorney General of California.

California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020, Cal. Civ. Code § 1798.100 et seq.

California Senate Bill 243 (Padilla), Ch. 677, Stats. 2025 (companion chatbots), Cal. Bus. & Prof. Code §§ 22601–22606.

Carlini, N., Liu, C., Erlingsson, Ú., Kos, J., & Song, D. (2019). The secret sharer: Evaluating and testing unintended memorization in neural networks. In 28th USENIX Security Symposium (pp. 267–284). USENIX Association.

Carlini, N., Tramèr, F., Wallace, E., Jagielski, M., Herbert-Voss, A., Lee, K., Roberts, A., Brown, T., Song, D., Erlingsson, Ú., Oprea, A., & Raffel, C. (2021). Extracting training data from large language models. In 30th USENIX Security Symposium (pp. 2633–2650). USENIX Association.

Chuang, J., Seto, A., Berrios, N., van Schaik, S., Garman, C., & Genkin, D. (2026). TEE.fail: Breaking trusted execution environments via DDR5 memory bus interposition. In 47th IEEE Symposium on Security and Privacy. https://tee.fail

Cooper, A. F., Choquette-Choo, C. A., Bogen, M., et al. (2024). Machine unlearning doesn't do what you think: Lessons for generative AI policy and research (arXiv:2412.06966; presented at NeurIPS 2025). https://arxiv.org/abs/2412.06966

Court of Justice of the European Union. (2017). Peter Nowak v. Data Protection Commissioner (Case C-434/16), ECLI:EU:C:2017:994.

Court of Justice of the European Union. (2022, August 1). OT v. Vyriausioji tarnybinės etikos komisija (Case C-184/20) (Grand Chamber).

Dash, A., Das, S., Kirsten, E., Wu, Q., Karnam, S. K., Gummadi, K. P., Holz, T., Zafar, M. B., & Zannettou, S. (2026). The algorithmic self-portrait: Deconstructing memory in ChatGPT. In Proceedings of the ACM Web Conference 2026. https://arxiv.org/abs/2602.01450

Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A., & Tramèr, F. (2025). Defeating prompt injections by design (arXiv:2503.18813). https://arxiv.org/abs/2503.18813

Desmedt, Y., & Frankel, Y. (1990). Threshold cryptosystems. In G. Brassard (Ed.), Advances in Cryptology — CRYPTO '89 Proceedings (Lecture Notes in Computer Science, Vol. 435, pp. 307–315). Springer. https://doi.org/10.1007/0-387-34805-0_28

European Data Protection Board. (2024, December 17). Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models.

Federal Trade Commission. (2021, May 7). FTC finalizes settlement with photo app developer related to misuse of facial recognition technology [Press release; In re Everalbum, Inc.].

Federal Trade Commission. (2023, December 19). Rite Aid banned from using AI facial recognition after FTC says retailer deployed technology without reasonable safeguards [Press release].

Federal Trade Commission. (2023, May 31). FTC and DOJ charge Amazon with violating children's privacy law by keeping kids' Alexa voice recordings forever and undermining parents' deletion requests [Press release].

Fei, S., Yan, Z., Ding, W., & Xie, H. (2022). Security vulnerabilities of SGX and countermeasures: A survey. ACM Computing Surveys, 54(6), Article 116. https://doi.org/10.1145/3456631

FTC Office of Technology. (2024a, January 9). AI companies: Uphold your privacy and confidentiality commitments. Federal Trade Commission.

FTC Office of Technology. (2024b, February 13). AI (and other) companies: Quietly changing your terms of service could be unfair or deceptive. Federal Trade Commission.

Gabriel, I., Manzini, A., Keeling, G., et al. (2024). The ethics of advanced AI assistants (arXiv:2404.16244). Google DeepMind. https://arxiv.org/abs/2404.16244

Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., & Fritz, M. (2023). Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (pp. 79–90). https://doi.org/10.1145/3605764.3623985

Laurie, B., Messeri, E., & Stradling, R. (2021). Certificate Transparency version 2.0 (RFC 9162). Internet Engineering Task Force. https://doi.org/10.17487/RFC9162

Liu, S., Yao, Y., Jia, J., Casper, S., Baracaldo, N., Hase, P., Yao, Y., Liu, C. Y., Xu, X., Li, H., Varshney, K. R., Bansal, M., Koyejo, S., & Liu, Y. (2025). Rethinking machine unlearning for large language models. Nature Machine Intelligence, 7(2), 181–194. https://doi.org/10.1038/s42256-025-00985-0

Long, R., Sebo, J., Butlin, P., Finlinson, K., Fish, K., Harding, J., Pfau, J., Sims, T., Birch, J., & Chalmers, D. (2024). Taking AI welfare seriously (arXiv:2411.00986). https://arxiv.org/abs/2411.00986

Melara, M. S., Blankstein, A., Bonneau, J., Felten, E. W., & Freedman, M. J. (2015). CONIKS: Bringing key transparency to end users. In 24th USENIX Security Symposium (pp. 383–398). USENIX Association.

Meta. (2025, April 29). Building Private Processing for AI tools on WhatsApp. Engineering at Meta. https://engineering.fb.com/2025/04/29/security/whatsapp-private-processing-ai-tools/

New York General Business Law, art. 47 (Artificial Intelligence Companion Models), §§ 1700–1704.

Nissenbaum, H. (2004). Privacy as contextual integrity. Washington Law Review, 79(1), 119–158.

Nissenbaum, H. (2010). Privacy in context: Technology, policy, and the integrity of social life. Stanford University Press.

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (General Data Protection Regulation). Official Journal of the European Union, L 119, 1–88.

Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union, L, 2023/2854.

Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L, 2024/1689.

Richards, N. M., & Hartzog, W. (2021). A duty of loyalty for privacy law. Washington University Law Review, 99(3), 961–1021.

Salvi, F., Horta Ribeiro, M., Gallotti, R., & West, R. (2025). On the conversational persuasiveness of GPT-4. Nature Human Behaviour, 9(8), 1645–1653. https://doi.org/10.1038/s41562-025-02194-6

Samadi, M. (2026). FORCE: Enterprise AI as cognitive infrastructure. A buyer-side governance framework for custody, continuity, resilience, control, and exit [Working paper]. SSRN.

Shamir, A. (1979). How to share a secret. Communications of the ACM, 22(11), 612–613. https://doi.org/10.1145/359168.359176

Solove, D. J. (2013). Introduction: Privacy self-management and the consent dilemma. Harvard Law Review, 126(7), 1880–1903.

Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., & Allen, C. (2022). Decentralized Identifiers (DIDs) v1.0 (W3C Recommendation). https://www.w3.org/TR/2022/REC-did-core-20220719/

Staab, R., Vero, M., Balunović, M., & Vechev, M. (2024). Beyond memorization: Violating privacy via inference with large language models. In International Conference on Learning Representations (ICLR 2024). https://doi.org/10.48550/arXiv.2310.07298

Wachter, S., & Mittelstadt, B. (2019). A right to reasonable inferences: Re-thinking data protection law in the age of big data and AI. Columbia Business Law Review, 2019(2), 494–620.

Yagnik, J. (2025, November 11). Private AI Compute: Our next step in building private and helpful AI. Google. https://blog.google/technology/ai/google-private-ai-compute

This paper is published for research and public review. It is not legal, security, privacy or regulatory advice. VAULT is an open proposal; it is not a certification, a recognized standard or a completed cryptographic protocol, and it assesses no product.