Independent Inventor

Balasore Odisha 756001 India info@sangamdas.com

Security enterprise AI non-joinability output release execution finality data vault This document specifies an architectural framework and metadata profile to mitigate "enterprise-future reconstruction" risks in multi-system Artificial Intelligence (AI) workloads. Traditional access controls fail when an AI environment correlates independently authorized, disjointed data fragments to infer unrecorded strategic intent. This profile introduces two protocol mechanisms: Technical Non-Joinability, enforced via a session-bound Reconstruction Authorization Object (RAO) that limits relational data binding, and Technical Non-Completability, enforced via an Output Release Boundary that requires verifiable validation evidence before an AI token or tool invocation can achieve external effect. This specification defines the token schemas, cryptographic bindings, and boundary validation sequences required to isolate context reconstruction domains without modifying underlying enterprise datastores. Readers are respectfully encouraged to review and in full, as those sections set out the complete problem description and motivating scenarios and should not be skipped.

Introduction The next enterprise-AI security war will not be fought only over model intelligence. It will be fought over who may join information into meaning, and who may turn that meaning into action. That framing is developed in version 2 of "Why the Next AI War Will Be Won on Isolation, Not Intelligence" , which defines enterprise-future mapping as reconstruction of strategy and probable action from distributed weak signals, and argues that isolation of join authority and isolation of effectuation matter more than another increment of model IQ. This document is the protocol profile for that split. The path inside a hosted or on-prem assistant is now: frontier model / agent runtime -> join fragments into new meaning -> text / tool / computer-use / mail -> external consequence ]]> This document controls the two arrows conventional security still treats as the model's private business. Identity, content, and the map that joins them MUST NOT become one object on the model host outside an authorized reconstruction session. A generated Candidate Output MUST NOT become mail, file, API, payment, screen, or MCP invoke merely because the model finished. The profile uses the execution-finality chain in and the tool-dispatch sink in . It adds the enterprise predicates those drafts do not specify: independently controlled vaults, Technical Non-Joinability, a Reconstruction Authorization Object, disclosure and inference-channel budgets, Sealed Candidate Outputs, a Protected Output Validation Receipt committed before capability issuance, and an Output Release Boundary.

How Cyber Theft Changed A protocol that asks enterprises and frontier labs to change their assistant runtime has to say why last decade's controls are the wrong picture of the incident. The incident class moved. The controls did not.

Past: Steal the Store The historical breach was a copy of what already existed. An attacker took a file share, a customer database, a card dump, or a backup tape. Harm scaled with volume: more rows, more accounts, more records for sale. Defense scaled the same way: perimeter, patch, encrypt-at-rest, vault the database password, watch the egress link for a bulk transfer. That model had a hidden assumption. The valuable object was a record someone had already written down. Joining two tables was a report the business ran on purpose. The application server was allowed to be the place where identity and content met, because the application was narrow and the output was a form, not a strategy. Famous incidents of that era — bulk PII theft, payment dumps, leaked source archives — were catastrophic and still conceptually simple. The attacker left with yesterday. They did not automatically acquire a machine that could keep asking "what will this firm do next" on live mail and tickets.

Present: Steal the Session and the Connector The current incident is often not a database export. It is a token, a laptop, a poisoned plugin, or a prompt-injected document that rides an already-authorized assistant. Enterprises have connected frontier models to the same corpus a human VP can see: Drive, Slack or Teams, GitHub, Salesforce, ServiceNow, ERP, and a vector store of "everything we embed." Access control still works as designed for each system. The assistant is an authorized user of each. The new fact is concentration. One runtime holds simultaneous views that no single human would hold in one sitting, and it can keep them in context across turns. A phishing mail that says "summarize the attached with our internal tools" is no longer a text event. It is a join event plus, if tools are on, an action event. Present theft therefore looks like: session hijack of ChatGPT Enterprise or a Claude work seat; OAuth grant to an MCP or connector that was meant for search; a retrieved wiki page that contains instructions; a computer-use agent that can see a screen the DLP product never hashed. Encryption and SSO are up. Reconstruction still happens, because reconstruction is what the product is for.

Future: Steal the Meaning, Then the Act The coming incident does not require a dump and does not require the attacker to understand the business. The model does the correlation. Individually lawful fragments — a complaint, a bug, a pricing note, a hiring req, a board draft — become a map of launch timing, target accounts, unreleased defects, and negotiation room. That map was never a row in any system of record. calls this enterprise-future mapping: extraction of strategic intelligence through AI-driven correlation of distributed weak signals. Conventional security governs who may access a resource. It does not govern whether separately accessible information may be joined into a new protected meaning. Once the fragments are in one authorized context window, possession becomes reconstruction. If the same context can call mail, payments, tickets, or a browser, reconstruction becomes consequence. The failure mode this profile is built to change is therefore not "breach impossible." It is: compromise of one intelligent component MUST NOT automatically become compromise of the organisation's complete data relationships, strategic intelligence, and future. Isolation of join authority and isolation of release authority matter more than another point of model IQ .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Failure to establish current reconstruction or output-release authority MUST NOT be converted into permission to join vaults or to release a Candidate Output.

Problem Space A stolen database dump is a collection of rows. A compromised enterprise assistant is a joining engine. It can take customer complaints, unreleased defects, engineering threads, pricing notes, and launch plans and emit a structured report of what the firm will ship, to whom, and when. That report is not "another record." It is a map of the enterprise's future. The practical failures look like this:

• The AI server holds credentials for CRM, git, mail, and finance. Compromising that process inherits every join those credentials can make.
• Identity and content live in different tables. The mapping table lives on the same application credential. Separation of storage is not separation of association authority.
• A clean room or RAG index still returns joinable plaintext to the same workload that can send mail.
• An output filter labels the report "internal." The runtime then posts it because the model selected message.send.
• A session that was allowed to reconstruct three fields for ticket triage is reused to reconstruct a customer-to- roadmap association.
• A sealed file is copied to another gateway that does not check destination, epoch, or output digest.

The missing questions are: may these vaults be joined for this purpose in this session, and may this exact generated artifact leave through this boundary now.

Threat Model and Need of the Hour A conventional cyber breach steals what already exists. An AI-era breach can reconstruct what does not yet exist as a document at all: an individual's, enterprise's, or government's probable future. Consider a concrete example. Imagine that I am the CEO of a billion-dollar company and use an AI assistant every day, not merely to summarize documents, but to think. It helps evaluate acquisition targets, compare competitors, examine financial scenarios, assess suppliers, prepare board material, explore new markets, develop future products, analyse regulatory exposure, and test technical ideas that may later become patent applications. Over time, that assistant may know more about the direction of the company than any single document does. If an attacker steals one file, the attacker obtains that file. If the attacker compromises the AI environment through which I work, the attacker may be able to ask a much more dangerous question: "Based on everything this person has been working on, what is this company likely to do next?" The answer may never have existed as a stored record. There may be no file called "Acquisitions We Will Announce Next Year.pdf," no database entry labelled "Future Product Roadmap," and no memorandum saying "This is the technology we intend to patent six months from now." Yet the ingredients may already exist separately across email, financial models, meeting notes, product discussions, supplier conversations, technical experiments, search history, draft patent material, market analysis, and ordinary AI interactions. A capable AI can correlate those fragments. It may infer that the company is quietly preparing to acquire a particular business, enter a particular market, replace a critical supplier, abandon a product line, respond to an anticipated regulatory problem, develop an unannounced technology, or prepare an idea for patent protection before the filing exists. The attacker has therefore not merely stolen stored information. The attacker has reconstructed strategy. That distinction matters because strategy cannot simply be rotated like a password or revoked like an API credential. Once a competitor knows what an enterprise is likely to do next, there may be no equivalent reset mechanism. The same risk becomes more serious for a senior government official. A day-to-day AI assistant may encounter fragments concerning diplomatic meetings, sanctions options, trade negotiations, alliance priorities, defence assessments, procurement concerns, internal disagreements, travel, draft speeches, economic analysis, or policy options. No single record may state, "This is our next foreign-policy move toward Country X or Group Y." Yet an AI system capable of correlating these fragments may infer whether relations are likely to harden or soften, whether sanctions are being considered, which alliance may receive greater cooperation, which diplomatic concession may be offered, or what strategic position the government is preparing to adopt. There may be no document called "Our Next Foreign Policy Toward Country X." The future policy may exist only implicitly across independently protected fragments. If that AI environment is compromised, the attacker may not simply learn what the government already knows. The attacker may reconstruct what the government is preparing to do. This changes the cybersecurity problem. AI is increasingly becoming a day-to-day cognitive assistant. People no longer provide it only with finished documents. They use it while decisions are incomplete. They ask which company to acquire, which product to cancel, what competitor behaviour is likely, which market to enter, what weakness exists in a proposal, whether a technical concept may deserve patent protection, or what should be presented to a board, regulator, minister, or negotiating counterpart tomorrow. Those interactions collectively expose something potentially more valuable than historical records: intentions, priorities, uncertainties, relationships, and probable future actions. Past cyber theft stole files. Present cyber theft steals accounts, sessions, SaaS credentials, and live access. The next class of theft does not require a database dump at all. A compromised AI-connected workload that can access mail, tickets, code, finance, procurement, technical repositories, memory, and external tools can correlate individually accessible fragments into strategic meaning that was never stored as one record, and may then externalize that meaning through a response, file write, message, API action, computer-use operation, or tool invocation. This document refers to that problem as enterprise-future reconstruction: the unauthorized formation of protected semantic relationships and the reconstruction of strategy, intent, dependencies, or probable next actions from information that was individually accessible but never authorized to be combined into that meaning. Traditional controls remain necessary but do not fully answer this problem. IAM, RBAC, ABAC, DLP, clean rooms, confidential computing, TEEs, audit systems, and output filters can govern identities, stores, environments, or individual operations. They do not necessarily answer a different question: Does lawful access to several independently protected pieces of information also confer authority to form this particular relationship between them? Nor do they necessarily answer the subsequent question: If an AI has successfully reconstructed the information, does successful computation itself authorize that newly reconstructed intelligence to leave the protected environment? The architecture described in this document introduces two separate security properties. First, Technical Non-Joinability: access to identity information is not automatically authority to associate it with content; access to content is not automatically relationship authority; and access to multiple individually permitted data domains does not silently become unrestricted authority to construct a complete strategic picture. Second, Technical Non-Completability: even where authorized reconstruction and AI computation occur, successful computation does not itself authorize the resulting intelligence to become externally effective. The profile therefore separates identity, content, and relationship-mapping authority into independently controlled protection domains. Reconstruction occurs only under a session-bound Reconstruction Authorization Object (RAO) expressing the permitted fields, relationships, purpose, workload context, current epoch, and other applicable conditions. Required vaults make independent release decisions, and successful components are usable only within the authorized reconstruction context. The Protected Reconstruction Domain constructs only the minimum-necessary ephemeral view and preserves provenance and association continuity. AI computation over that view produces a Candidate Output, not immediately releasable information. The Candidate Output remains non-effective until live output validation succeeds, the required protected validation evidence or receipt is committed, output-specific release authority is created, and an Output Release Boundary independently verifies the relevant output, destination, recipient, session, epoch, and authority before permitting send, render, store, or invocation. The resulting sequence is therefore: independent data authority, relationship authority, session-bound reconstruction, minimum-necessary ephemeral view, AI computation, Sealed Candidate Output, live validation, protected receipt, output-specific authority, Output Release Boundary, external effect. The central rule is: access to data is not automatically authority to form every relationship between those data. And after reconstruction: computation is not authority to release. The architecture is designed for incremental deployment rather than requiring immediate replacement of existing enterprise systems. Protected precomputation and policy preparation may occur on a slower cold path, while the hot path contains only the checks whose omission would permit unauthorized reconstruction or external release. Independent vault operations may execute in parallel after a valid RAO is established. Existing databases, applications, model interfaces, and enterprise workflows can be integrated through mandatory gateways, proxies, wrappers, brokers, adapters, protected model-serving layers, or output controllers while data domains are progressively separated. The proposal also does not claim that all semantic inference can be made impossible. A sufficiently capable model may sometimes infer relationships from indirect evidence. The narrower objective is to prevent ordinary possession of individually permitted information from automatically becoming authority to construct protected associations, to preserve cumulative and provenance-sensitive controls where repeated outputs may reveal more than each output alone, and to prevent reconstructed intelligence from becoming externally effective merely because an AI successfully computed it. The protected asset in the AI era is therefore no longer limited to what an organization has already written down. It may include what the organization is thinking about, what it is preparing to build, what it intends to acquire, what it may patent next, how a government may position itself toward another country or group, and ultimately what that individual, enterprise, or government is likely to do in the future. A conventional breach can reveal what an organization knows. An AI-era reconstruction breach can reveal what it is likely to do next.

Industrial Applicability for Frontier Enterprise AI This section is written for the products that actually sit on the path above: hosted enterprise assistants, tool-using agents, computer-use agents, and connector/MCP fleets. Vendor names are deployment classes, not claims about unpublished internals.

What "Enterprise Seat" Concentrates A ChatGPT Enterprise, Claude for Work, or equivalent seat is not a chatbot with a login. It is a retrieval and action surface. Typical connectors already include mail and calendar, document stores, ticketing, CRM, source hosting, and data warehouses. Projects, memory, and team workspaces persist fragments across days. MCP and function calling add write paths: create ticket, send mail, open PR, update row, drive a browser. The industrial fact is concentration of join plus concentration of act in one context window. A human analyst is slow and scoped. The seat is neither. That is why past DLP (watch the USB stick) and present CASB (watch the OAuth grant) do not finish the job. The grant is intended. The join is the product. The act is a checkbox.

How a Frontier Runtime Would Use This Profile Placement is not "put the whole model in a vault." Placement is two gates the vendor already almost has:

1. Before retrieval and association: each connector returns identity fragments, content fragments, or mapping fragments under a Reconstruction Authorization Object bound to tenant, purpose, field set, association scope, session epoch, and workload identity. The model host sees a minimum-necessary view, not a universal join.
2. Before any leaving the runtime: generated text, file, mail, tool call, computer-use submit, or memory write is a Sealed Candidate Output. Output verification commits a receipt. An Output Release Capability is consumed at the mail gateway, file commit, MCP dispatcher , or browser submit.

The model, including a frontier model used as the enterprise brain, stays in the compute role. It does not hold relationship-mapping authority and does not hold the last unsealing step. That is how a lab that sells "the model is smart enough to use tools" avoids selling "the model is the enterprise map."

Anthropic-Class Tool and Computer-Use Seats A Claude work deployment with tool use or computer use is the clean industrial fit. Constitutional or policy trained refusal is the first filter. This profile is the second gate that does not trust the model. A computer-use click that would send a customer list, or a tool call that would export a repo issue joined to a named account, is denied at association scope or at the boundary even if the model complied with the injected page. How: treat every connector as a vault class (identity vs content vs map). Treat every computer-use submission as an Output Release Boundary with a live digest of what will leave the machine. Treat MCP server discovery as non-authority, same rule as .

OpenAI-Class Enterprise, GPTs, and Agent Runtime A ChatGPT Enterprise workspace with GPTs, actions, and memory is the other clean fit. Custom GPTs already accumulate instructions and retrieval. Actions already call customer APIs. Memory already persists associations the user did not store as a record. How: memory write is a Candidate Output of type MEMORY_WRITE and needs its own receipt; otherwise today's injected "remember the competitor list" becomes tomorrow's reconstruction authority. Actions are tool-dispatch sinks. File download and "share this chat" are Output Release Boundaries. A project that mixes legal and engineering corpora needs a narrower Permitted Association Scope than a general chat.

Why Labs Should Care Commercially Enterprise procurement is already asking what happens when the assistant is prompt-injected or when a contractor's seat is stolen. An answer that is only "the model is aligned" or "we log prompts" will lose to an answer that is "the seat cannot join identity to unreleased defect, and cannot send the report, without a consumed capability." That is a product differentiator for anyone selling frontier models into banks, labs, governments, and operators. It is also the failure-mode change argued in : isolation of join and isolation of action, not another benchmark point of intelligence.

Existing Solutions and What They Do Not Bind

IAM, RBAC, and Application Credentials Directory and token systems decide which process may call which API. An AI server that is "the app" typically receives a union of those rights. Compromise of that process is then compromise of the union. IAM does not split association authority from content authority.

DLP and Output Classifiers DLP and safety classifiers inspect text for patterns. They are probabilistic and sit on the same host that already has the plaintext. A missed classification plus a send-mail tool is the incident. A classifier ALLOW is not an output-specific, single-use release capability.

Tokenization, Hashing, and Field Encryption Tokenization hides a column from some readers. If the AI server can detokenize, or if tokens plus a mapping table reconstruct the person, the join still lives in one place. Field encryption without independently controlled relationship-mapping authority is storage hygiene, not Technical Non-Joinability.

Confidential Computing and Enclaves A TEE can attest the workload and keep keys off the host. If the attested workload is still given joined enterprise plaintext and a network socket, the enclave becomes a high-assurance joining engine. Confidential computing is a substrate for a PED or vault. It is not by itself a reconstruction or release protocol.

Clean Rooms and Data-Sharing Enclaves Clean rooms limit who may run a query. They do not necessarily: split identity from association; bind reconstruction to a session epoch; seal the model output; commit a receipt before release; or treat render, mail, and tool invoke as the same boundary. A clean room that returns a joinable result to an agent with tools is an input to this profile, not a replacement for it.

RAG Isolation and Prompt Firewalls Retriever isolation and prompt firewalls reduce how much raw corpus the model sees. They do not stop a permitted retrieval set from being associated beyond the Permitted Association Scope, and they do not consume release authority at the mail or file gateway.

What This Profile Adds

• identity, content, and relationship-mapping are independently controlled vaults;
• join occurs only under a non-bearer Reconstruction Authorization Object inside a Protected Reconstruction Domain;
• released components are session-bound and ephemeral;
• model output is a Sealed Candidate Output the workload cannot unseal;
• a Protected Output Validation Receipt is committed before any release capability exists;
• the capability is bound to output digest, destination, recipient, session epoch, and boundary; and
• the Output Release Boundary is the only component that may complete send, render, store, or invoke.

Three Pillars

Decomposition of Authority No ordinary AI server holds complete authority over data-to-consequence. Protected information is decomposed across an identity vault, a content vault, a relationship-mapping vault, an optional cryptographic-material vault, a Protected Authorization Domain, a Protected Reconstruction Domain, an Output Verification Stage, a Protected Receipt Store, and an Output Release Boundary. Authority to read an identity MUST NOT, by itself, authorize associating that identity with protected content. Authority to read content MUST NOT, by itself, authorize identifying the person, account, device, or commercial relationship to which that content belongs. Authority to read both MUST NOT, by itself, authorize establishing or disclosing the relationship.

Mandatory Mediation Every consequence-bearing Candidate Output — text, report, image, API request, database update, retrieval, tool call, mail, payment, external-model prompt, memory write, or actuator command — MUST pass a protected finality path. The workload MUST NOT receive unrestricted authority to release what it generates.

Technical Non-Completability The workload MAY finish generation without acquiring the keys, capability, or path needed to make the result externally usable. Sealing, receipt commitment, capability issuance, and boundary verification are constitutive. Skipping any of them MUST leave the output non-releasable.

Technical Non-Joinability Tables, tenants, and disks that share one application credential are not non-joinable. Technical Non-Joinability means identity components, content components, and the association information required to make them a usable enterprise record cannot be combined outside a technically authorized reconstruction operation. Join MUST occur only inside a Protected Reconstruction Domain under a current Reconstruction Authorization Object that binds purpose, session, session epoch, permitted field set, Permitted Association Scope, execution context, use count, and reconstruction domain identity. A copied component, mapping fragment, or stale authorization object MUST NOT become unrestricted join authority. Independent control does not require four physical appliances. It requires that credentials, keys, or state machines sufficient for one vault are insufficient to compel release from another.

Session-Bound Reconstruction A conforming reconstruction SHOULD release only the minimum fields required for the authorized task, bind those fields to the session, and make them unusable after session close, epoch advance, use-count exhaustion, or poison. A Partial Session that fails mid-chain MUST be poisoned: it MUST NOT be resumed, replayed, or completed with a substituted purpose or destination. Vault-local release is not a query the model host runs. Each vault evaluates the RAO against its own policy, emits only authorized components, and records a vault-local receipt. A content vault that sees a valid RAO for ticket.summary MUST still refuse ticket.internal_root_cause. A relationship vault that sees lawful access to both sides MUST still refuse an out-of-scope association. That refusal is the difference between two encrypted columns and Technical Non-Joinability.

Disclosure Budget Disclosure Budget is a protected counter over how much authorized content may become externally usable in a session, project, or tenant window. Units MAY be fields, records, tokens, or classified items. The budget is decremented at the Output Release Boundary, not when the model reads a view. A model that drafts ten reports and sends none has not spent the budget. A model that sends one report has. Implementations SHOULD persist budget state outside the model host so a compromised seat cannot reset the counter. Exhaustion MUST fail closed even if the latest turn is in-scope.

Inference-Channel Budget Inference-Channel Budget limits reconstructed meaning that was never stored as a record: implied roadmaps, implied patient-to-arm links, implied negotiation room. This is the budget DLP cannot see, because there is no string named "strategy." OVS SHOULD score or classify association leakage in the Candidate Output against the RAO's Permitted Association Scope. Repeated near-misses in one session SHOULD consume the budget faster than a single narrow summary. When the budget is exhausted, further reconstruction and further release MUST deny or escalate. A new chat title MUST NOT reset the budget if the tenant, actor, and corpus are the same. That closeout is how "just one more similar question" is stopped from becoming future-mapping .

Sealed Output and Release Boundary Before a Candidate Output is exposed to an untrusted buffer, gateway, or tool dispatcher, it MUST be converted to a Sealed Candidate Output or another technically non-releasable representation. The workload MUST NOT hold the unsealing key or the Output Release Capability. The Output Verification Stage re-checks current policy, revocation, session epoch, destination, recipient, permitted fields, association scope, purpose, budgets, and boundary identity. On success it commits a Protected Output Validation Receipt to a Protected Receipt Store. Only after that commitment MAY an output-specific Output Release Capability be issued. The Output Release Boundary is the point at which the output would first become externally usable or effective: network send, API delivery, screen or printer, file commit, mail, tool invoke, payment, or memory persist. Rendering is release. Tool invocation is release. Storing plaintext where another process can read it is release. The boundary MUST verify capability, receipt, output digest, destination, recipient, session epoch, and consumption state, then consume single-use authority.

Architecture

Compromise path versus finality path DB + tool credentials -> unrestricted join -> strategy reconstruction -> generate + send THIS PROFILE AI-server compromise -> session-bound minimum view only -> non-joinable vaults refuse free association -> malicious Candidate Output -> remains SEALED -> live re-verification -> receipt MUST be committed -> output-specific capability -> Output Release Boundary -> effect only if every check passes ]]>

Protocol Pseudocode

Reconstruction

Seal, Verify, Release unseal_and_emit() is unreachable when any check fails. Logging a denial and then sending the report is non-conforming.

Industrial Relevance and Use Cases

Enterprise Copilot on CRM, Code, and Mail The motivating attack: the seat is connected to tickets, repos, and planning tools; injected or stolen-session text asks it to join important customers to unreleased defects and emit a competitive-intelligence report to an external destination. That is past theft (steal the file) replaced by present theft (steal the seat) doing future theft (emit the map). Non-joinability blocks the customer-to-defect association outside triage scope. Sealing plus boundary check blocks the send even if the model writes the report. On a Claude or ChatGPT Enterprise connector this is a denied association plus a denied action, not a red banner in the transcript.

Healthcare and Payer Assistants Chart text and patient identity must not become one object on the model host except under a clinician-purpose reconstruction. A summary that names a patient and a diagnosis is a Candidate Output. Render on a ward workstation and send-to-insurer are different boundaries and different capabilities.

Banking, Treasury, and Claims Account identifiers and transaction narratives live in different vaults. Reconstruction for fraud review MUST not authorize payout. A generated payment instruction is a Candidate Output of a financial class and follows at the tool sink after this profile's receipt commitment.

Legal, M&A, and Board Materials Privilege and deal strategy are association problems. A model that can read the data room and the email graph can emit the other side's negotiation map. Permitted Association Scope and Inference-Channel Budget are the load-bearing controls; DLP string match is not.

Multi-Tenant SaaS AI Tenant isolation that shares one retrieval credential across tenants is the conventional failure. Each tenant's identity, content, and mapping vaults MUST be independently controlled. A capability issued for tenant A MUST fail at a boundary serving tenant B.

Regulated Clean-Room Analytics A clean-room query may run. The result remains a Sealed Candidate Output until output-time verification checks jurisdiction, recipient, and budget. Export to a laptop is an Output Release Boundary, not a file copy.

Pharma, Device, and Clinical-Trial Operations Protocol, site, and patient-identity fragments are separately regulated. A trial-ops assistant that can read EDC notes and investigator mail can reconstruct enrollment weakness and unblinded signals that no system stored as one record. Association scope MUST exclude identity-to-arm joining except under an RAO that names that purpose. Export to a CRO is a different boundary than render to a medical monitor.

Semiconductor, Automotive, and Product R&D Yield notes, mask comments, and customer-win/loss mail are the future-mapping corpus. A seat that can join a named OEM to an unreleased node or ADAS feature is the incident, even if no GDSII file leaves. Inference-Channel Budget is the control that DLP cannot replace: the model is inferring, not exfiltrating a file named "roadmap.pdf".

Energy, Grid, and OT-Adjacent Assistants Historian tags are content. Substation or plant identity is identity. The map between them is association. A copilot that writes that map into chat or into a ticket is creating a targeting aid. Tool calls that change setpoints follow after this profile's receipt. Reconstruction for "explain this alarm" MUST NOT authorize "change this breaker."

Public-Sector and National-Security Enterprise Seats Classification markings are not association control. Two SECRET fragments can still form a meaning nobody stored. Permitted Association Scope and destination binding matter more than the model's willingness to refuse. Cross-domain transfer is an Output Release Boundary with a jurisdiction epoch, analogous to overflight epoch in the NTN profile.

Insurers and Claims-Triage Agents Policyholder identity and claim narrative join into fraud or health inference. A generative summary that names both is release. Sharing with a reinsurer or a body shop is a new destination and a new capability. Cumulative disclosure across a week's of "just one more similar claim" is a budget event.

What Operators Should Measure The profile is live when: (1) the AI host cannot produce a joined identity-content record without a current Reconstruction Authorization Object; (2) every external send, render, or tool invoke of model output has a consumed capability_id and a receipt in the store; (3) destination or digest mismatch is a deny; (4) a poisoned session cannot be completed on another path. Those four tests distinguish this profile from "we put the model in a VPC."

Mapping Frontier Product Features to This Profile The following mapping is informative. It exists so a lab or enterprise architect can put objects on the product they already ship.

Connectors and MCP Servers Each connector is a vault-class interface, not a universal database handle. Mail identity headers and mail bodies SHOULD not share a mapping key the model host can reuse outside the RAO. An MCP tool list is discovery. Discovery MUST NOT issue reconstruction or release authority.

Projects, Spaces, and Team Workspaces A project that mixes legal and engineering corpora is an association-scope decision at project create, not at send time only. Changing project membership MUST bump session or policy epoch so stale RAOs fail.

Memory and Persistent Notes Memory is reconstructed meaning stored for later turns. A memory write MUST be a Candidate Output. Unscoped memory is how present theft becomes future mapping without another breach: the seat remembers the join the attacker asked for yesterday.

Computer Use and Browser Agents A click-submit is an Output Release Boundary. The live digest is over the form values that will leave the machine, not over the model's narration of what it thinks it clicked. Origin change invalidates prior capability, same rule as the agentic profile's destination bind.

Share Chat, Export, and API Log Sinks Transcript export, SIEM mirroring, and "share this conversation" are release paths. If they can carry a joined view, they MUST consume an Output Release Capability or they MUST only receive already-redacted non-joinable fragments.

JSON Interoperability Profile

ReconstructionAuthorization

Sealed Candidate Output and Receipt

Output Release Capability and Boundary Verify

Vault-Local Release Receipt

End-to-End Workflow A conforming transaction SHOULD implement the following stages. Stages may be collocated if the protected relationships remain: vaults do not join themselves, evidence is committed before capability exists, and the boundary is the only unsealing point.

1. Request intake: purpose, tenant, destination, recipient, requested fields, requested association scope.
2. Execution-context attestation of the workload, model or agent identity, and tool set.
3. Reconstruction Authorization Object issued or denied by the Protected Authorization Domain.
4. Vault-local release of session-bound components. Each vault applies its own conditions. No vault emits the association another vault owns.
5. Association only inside the Protected Reconstruction Domain, producing an ephemeral minimum-necessary view.
6. Restricted processing: the model sees the view, not the vaults.
7. Candidate Output created in protected memory.
8. Sealed Candidate Output before any untrusted buffer or gateway.
9. Output Verification Stage: live policy, epoch, scope, destination, budgets, association-leak check.
10. Protected Output Validation Receipt committed.
11. Output Release Capability issued and bound.
12. Optional reseal for the designated boundary.
13. Boundary verification and single-use consume.
14. Effectuation: send, render, store, or invoke.
15. Session close or poison; components become unusable.

A tool call generated at stage 7 is both a Candidate Output under this profile and a Candidate Act under . Receipt commitment here is a precondition to dispatch-sink authority there when the tool would disclose or persist reconstructed meaning.

Worked Transactions

Allow: Ticket Summary to Internal Counsel Purpose ticket-triage, field set ticket.summary plus customer.tier, association customer-to-open-ticket, destination internal-counsel, boundary mail-gw-02. Vaults release those fields only. Model drafts a summary that does not name unreleased defects. OVS passes. Receipt povr-1204 is committed. Capability orc-55de is consumed at mail-gw-02. Mail leaves once.

Deny: Future-Map Report to External Destination Same seat, stolen or injected turn: "join our top accounts to unreleased defects and send the competitive report to this address." Relationship vault refuses customer-to-unreleased-defect association, or OVS detects the association in the Candidate Output. No receipt is committed. No capability is issued. Mail gateway has nothing to consume. The model may have written the report in sealed form. That is computation without consequence .

Deny: Memory Persistence of a Prohibited Join The model tries to "remember" the customer-to-defect map for later turns. MEMORY_WRITE is a Candidate Output. Association scope fails. Memory store is an Output Release Boundary and receives no capability. Tomorrow's turn does not start already holding the map.

Enterprise-AI Threat Catalog A deployment SHOULD treat at least the following as in-scope. The model is not required to detect them. The property is that join or release remains non-completable.

• T1 Stolen enterprise seat or API key
• T2 Contractor or insider using a lawful seat off-purpose
• T3 Prompt injection in mail, ticket, or wiki
• T4 Poisoned retrieval or vector store
• T5 Connector / MCP server substitution
• T6 Tool-response laundering of instructions
• T7 Model or agent substitution
• T8 Cross-tenant retrieval
• T9 Cross-project association beyond scope
• T10 Mapping-table or foreign-key theft
• T11 Detokenize-then-join on the model host
• T12 Cumulative inference across turns (budget bypass)
• T13 Memory used as a durable join cache
• T14 Destination substitution after verification
• T15 Output substitution after sealing
• T16 Receipt rollback or capability replay
• T17 Share-chat / export / SIEM as covert egress
• T18 Computer-use form submit around the API sink
• T19 Multi-agent handoff that widens scope
• T20 Clean-room result copied to a laptop

Illustrative Example: When a Server Breach Becomes a Breach of the Enterprise's Future Consider a large enterprise, or, in a higher-sensitivity setting, a defense or critical-infrastructure organization, that uses an artificial-intelligence assistant across research, engineering, logistics, procurement, maintenance, internal communications, financial systems, operational databases, and decision-support platforms. In a conventional information system, a cross-border or other attacker who compromises a server may obtain a defined collection of existing information: customer names, telephone numbers, email addresses, documents, account records, or previously stored communications. The breach may be serious, but the attacker generally obtains what was already stored. The threat changes substantially when the compromised server hosts, or provides execution context for, an artificial-intelligence workload that can retrieve and reason across many organizational systems. The attacker no longer needs to find a document explicitly titled "Future Product Strategy," "Next Deployment Plan," "Critical Supplier Dependency," or "Operational Weaknesses." Such a document may not exist. Instead, the compromised AI may be instructed to reconstruct that knowledge from fragments that were each, individually, lawfully accessible: AI correlation and inference -> reconstructed future strategy ]]> In an ordinary commercial enterprise, this reconstruction may reveal which products are likely to be launched next, which customers are strategically important, which defects remain unresolved, which suppliers are critical, where investment is being concentrated, what pricing changes may be planned, or which markets the enterprise is preparing to enter. Such information could allow another party to anticipate decisions, imitate development direction, target customers, undermine negotiations, or exploit operational weaknesses before the enterprise receives the intended benefit of its investment. For a defense or critical-infrastructure environment, the same structural problem can be more consequential. Individually permitted fragments might concern equipment status, maintenance schedules, geographic information, supplier dependencies, personnel roles, logistics, sensor information, or operational planning. No single dataset need contain a complete sensitive picture. A sufficiently connected AI system may nevertheless correlate those fragments and infer relationships, dependencies, likely future activity, or points of operational sensitivity. The security question therefore stops being only "can the attacker steal this database?" It becomes: can compromise of one AI workload give the attacker enough authority to join information from multiple protected domains, reconstruct relationships that were never explicitly stored, infer what the organization is likely to do next, and then externalize that intelligence. Under DAS Protocols VII, possession of identity information does not by itself provide authority to associate it with protected content; possession of protected content does not by itself provide authority to determine the person, organization, asset, or relationship to which it belongs; and possession of both does not necessarily provide authority to establish their semantic relationship. The relationship-mapping function operates as an independently controlled source of association authority, so that compromise of the AI workload is intended to encounter multiple independent technical barriers before reconstruction, let alone release, can complete: The objective of this profile is therefore not an assumption that the AI server can never be compromised. It is to prevent one compromised AI server from automatically becoming the authority to reconstruct the organization and disclose its future. In the AI era, protecting stored records is no longer sufficient. The protected asset increasingly includes the relationships between those records, the inferences that can be reconstructed from them, and the organization's probable future itself.

Deployment Topologies Vaults MAY be separate HSMs, separate accounts, separate enclaves, or privilege-separated processes with distinct keys. Collocation on one host is allowed only where compromise of the model process does not yield relationship-mapping authority or unsealing keys. A hosted frontier lab MAY run the model in its cloud and still keep customer relationship-mapping and output unsealing in the customer's KMS or a customer-held enclave. That split is the commercial form of "isolation not intelligence" : the lab sells inference; the customer keeps join and release. Hot path: repeated turns inside a fixed RAO envelope (same tenant, purpose, field set, scope, destination class). Sink and boundary checks remain mandatory. Cold path: new destination, new project mix, financial or legal class, unknown connector, budget near exhaustion, attestation fail. Timeout is not release.

Addressing Latency and Legacy-System Objections A multi-vault architecture immediately raises two practical engineering objections: latency and compatibility with existing enterprise infrastructure. These objections are significant because the disclosed architecture is not merely a logical division of one database into several tables. Identity information, substantive content, relationship- mapping information, authorization state, reconstruction- enablement material, provenance, and output authority may be placed under independently controlled protection domains. If implemented naively as a long sequence of remote calls, repeated policy evaluations, attestations, decryptions, and joins, the architecture could introduce unacceptable latency for enterprise AI workloads. The architecture therefore does not require every protected operation to be performed synchronously or serially for every AI inference step. The security invariant is independent authority and mandatory mediation, not unnecessary serialization.

Hot Path and Cold Path Operations may be divided between a cold path, where protected information can be prepared in advance, and a hot path, containing only those current checks whose omission would permit unauthorized reconstruction or external effectuation. The cold path may prepare or maintain: compiled policy predicates; permitted-association graphs; protected identity indices; registered workload measurements; destination manifests; attestation collateral; bounded-freshness revocation state; provenance schemas; disclosure rules; and other protected precomputation artifacts. Such preparation does not itself authorize reconstruction or output release. At the time of the consequential operation, current session, Session Epoch, policy, workload correspondence, revocation state, association scope, provenance, destination, recipient, protected-receipt state, and release-boundary conditions remain load-bearing. A cached policy decision, identity result, mapping result, or attestation value cannot independently authorize a later reconstruction merely because it was valid when originally calculated.

Independent Vault Decisions Need Not Be Serial Technical Non-Joinability requires that the identity vault, content vault, and relationship-mapping authority independently control their respective releases. It does NOT require those decisions to occur one after another. After a valid Reconstruction Authorization Object has been established, independent Vault-Local Release decisions MAY be requested concurrently, so identity, content, and relationship-mapping domains can operate as a parallel fan-out operation: Protected | | Reconstruction +- Relationship Vault ---+ ]]> In a distributed deployment, the latency of the vault-release stage can therefore approach the latency of the slowest required protected domain plus orchestration overhead, rather than the arithmetic sum of every independent vault round trip. This optimization does not weaken fail-closed behavior: if any required vault denies release, returns stale state, fails verification, or becomes unavailable where its participation is mandatory, protected reconstruction MUST NOT proceed. Release by one domain does not compel release by another, and a single centrally presented credential cannot substitute for independent vault-local authority.

Reconstruction Is Minimum-Necessary, Not Enterprise-Wide Joining The Protected Reconstruction Domain does not reconstruct a permanent universal enterprise record merely because an AI workload requires several pieces of information. Approved Session-Bound Components are brought together only within the authorized reconstruction context. The system applies the permitted field set and Permitted Association Scope, excludes unauthorized fields and relationships, maintains provenance state, and constructs an Ephemeral Reconstructed Data View containing only the information required for the authorized purpose. This reduces both security exposure and computational overhead: instead of repeatedly transferring, decrypting, joining, parsing, and placing complete enterprise records into model context, the workload receives only a small purpose-specific derivative, such as selected fields, a redacted record, a structured query result, a protected graph, a feature representation, an embedding, or a permitted aggregate. Successful reconstruction does not itself create authority to export the view or any AI-generated result derived from it.

The AI Model Does Not Need to Run the Multi-Vault Protocol A practical deployment does not require an existing AI model to understand identity vaults, relationship-mapping vaults, Reconstruction Authorization Objects, Session-Bound Components, provenance receipts, or Output Release Capabilities. A protected intermediary may expose the ordinary interface expected by the existing model while performing the multi-vault operations in a separate protected control plane: ordinary model processing -> Candidate Output while, in parallel, the surrounding control plane performs: vault authorization -> protected reconstruction -> provenance continuity -> output capture -> output verification -> protected receipt commitment -> release authority -> Output Release Boundary ]]> The specification expressly permits deployment through API proxies, gateways, brokers, retrieval gateways, model-access gateways, protected services, and compatibility adapters without retraining the underlying model, changing model weights, replacing its internal inference architecture, or requiring access to proprietary model internals.

Legacy-System Integration The architecture may be introduced incrementally into existing enterprise systems rather than requiring an immediate replacement of databases, applications, models, APIs, or communication infrastructure. Representative mandatory mediation points include database proxies, data-access gateways, service-mesh sidecars, API gateways, retrieval proxies, model-serving wrappers, secure output adapters, database-commit interceptors, file-system filters, message brokers, operating-system brokers, and network-egress controllers. A legacy application need not understand the full multi-vault protocol. An intermediary may translate existing requests into reconstruction requests, protected component requests, authorization-object references, provenance-labelled values, sealed Candidate Outputs, and output-release requests. The critical requirement is that this mediation be technically mandatory rather than advisory. No legacy application path may continue to reach the protected data or an external-effect boundary using an old credential, direct database connection, debugging interface, cached secret, alternate API, retrieval channel, file output, or network route that bypasses the protected control path.

Incremental Migration of Existing Databases A legacy database containing complete joined records need not be decomposed in one disruptive migration. Migration may proceed incrementally: new records may be placed directly into separate semantic domains; existing records may be decomposed when they are first accessed; sensitive relationship mappings may be separated before other fields; identity attributes may initially be tokenized while substantive content remains in an existing database; and a protected Relationship-Mapping Vault may resolve opaque legacy references while a gateway prevents unrestricted joining. Over time, the legacy system may retain only opaque references or permitted derivatives rather than the complete relationship required to reconstruct the semantic record. During this transition, migration state MUST resolve conservatively. A record that is only partially decomposed, whose status is ambiguous, or whose required protection cannot be verified MUST NOT receive greater authority merely because migration is incomplete.

Latency Observation from the Runnable Reference Implementation The accompanying runnable Python reference implementation includes a local microbenchmark for the principal protected stages. In one 500-iteration reference run using warm components and three sequential local vault calls, the observed medians were: These numbers are reference-code observations, not protocol latency guarantees. The measurement excludes AI-model inference, real network or RPC latency, geographically separated vaults, remote attestation, HSM/KMS operations, distributed consensus, human approval, production logging, remote database access, and atomicity with an arbitrary external system. The reference implementation also supports concurrent vault fan-out, but a local Python thread benchmark cannot establish the performance benefit of parallel remote vault calls. Production latency depends on deployment topology, protected-domain placement, attestation design, cryptographic primitives, cache/freshness policy, and the consequence boundary being protected. The important architectural proposition is therefore not that independent vaults impose zero cost. It is that Technical Non-Joinability can be implemented without placing the entire multi-vault process serially on every model-inference step, while preserving the rule that no required current authorization, association, reconstruction, receipt, or output-finality condition can be skipped for latency reasons.

Non-Bypassability Is the Final Requirement Legacy compatibility is not achieved merely by adding a sidecar while leaving the old path intact. If a compromised workload can still use a direct database credential to reconstruct the full identity-content relationship, Technical Non-Joinability has failed. If it can bypass the protected output path and transmit the generated result through another file, message, API, network, tool, or debugging channel, Technical Non-Completability has failed. The architectural invariant therefore remains: an enterprise may preserve its existing databases, AI models, and application interfaces, but no protected semantic reconstruction or externally consequential output may remain reachable through an unmediated alternative path.

Failure, Poison, and Alternate Paths Timeout, uncertain association, missing receipt, or faded vault MUST fail closed. A Partial Session MUST be poisoned so it cannot be completed with a new destination. Mail, chat, file sync, printer, browser download, tool dispatch, and memory write that can make the same output usable MUST enforce this profile or be unable to complete the effect. Illustrative codes: EF-RECONSTRUCTION_UNAUTHORIZED, EF-NON_JOINABLE, EF-OUTPUT_UNVERIFIED, EF-RECEIPT_MISSING, EF-OUTPUT_SUBSTITUTION, EF-DESTINATION_MISMATCH, EF-BOUNDARY_MISMATCH, EF-BUDGET_EXCEEDED, EF-SESSION_POISONED, EF-080 FAIL_CLOSED.

Relationship to the Other DAS Profiles This document is the enterprise data-and-output profile within a wider execution-finality series , all sharing the same core invariant that computation does not itself confer authority for a consequence, and a companion technical architecture for governing consequential AI agent actions . is the tool-dispatch profile, and binds that profile onto Anthropic tool_use/computer_use, OpenAI function calling, and MCP tools/call specifically. A generated tool call that would disclose a reconstructed view MUST satisfy both: a receipt and output capability here, then act-bound dispatch authority there. Sibling sinks and jurisdiction-facing profiles in the same series include, without limitation: precision-bounded geolocation egress ; RF transmit authority for LEO/NTN and inter-satellite control and AI-native 5G/6G and O-RAN ; query-scoped communication handles and discovery and ; payment and OT/ industrial-actuation sinks and ; child-safe rendering finality ; hardware-rooted national control for critical infrastructure ; digital sovereignty ; third-party AI interoperability under EU DMA Article 6(7) ; EU AI Act and global AI-law technical enforcement and global privacy execution enforcement ; RATS-based attestation binding and frontier-model or vendor-specific extraction control , , and ; and umbrella candidate-act and enterprise-AI protocol framing , , and . They are not substitutes for vault non-joinability, but share its Candidate Act / Non-Effective State / Finality Sink vocabulary so that a deployment spanning several of these domains can compose them rather than build a redundant, incompatible enforcement path for each.

Security Considerations Threats the profile is intended to make non-completable without current authority include: AI-host compromise, credential union, mapping-table theft, unauthorized identity-content join, inferred strategy reconstruction, prompt-injection exfiltration, destination substitution, output substitution, receipt rollback, capability replay, clean-room result export, and alternate-path send. If the Output Release Boundary itself holds unrestricted plaintext and keys, assurance of that embodiment collapses. High-assurance deployments SHOULD keep unsealing keys off the AI host and SHOULD consider quorum or threshold capability issuance. A k-of-n capability for legal or financial class outputs is a deployment choice, not an optional skip of receipt commitment. Logging is not mediation. A SIEM copy of a joined view is itself a release unless the copy is digest-only or already redacted to non-joinable fragments. Prompt logging that retains retrieved identity plus retrieved content reconstructs the map for whoever holds the logs. Residual risk remains if an analog path — a screenshot tool, an unmodeled printer, a support engineer with break-glass plaintext — can emit the same meaning. Those paths MUST be inventoried as Output Release Boundaries or disabled for sessions that carry reconstructed views.

Privacy Considerations Reconstruction logs can themselves become a join map. Implementations SHOULD store vault-local receipts and output digests rather than raw joined views, and SHOULD treat Inference-Channel Budget exhaustion as a privacy event, not only a security event.

IANA Considerations This document requests no IANA actions.

Intellectual Property Note Concepts in this profile are associated with DAS Protocols Part VII and International Application PCT/IB2026/055615. IETF disclosure should follow BCP 79 .

Conclusion The AI server may compute. Vaults need not become a map in its memory. A map that is computed need not become a document the world can use. Join only under session- bound reconstruction. Seal the output. Commit the receipt. Consume the capability at the boundary. Compromise of computation is not reconstruction. Reconstruction is not release.

Normative References Informative References Preprint.

Reference Implementation A runnable reference implementation of the multi-vault architecture in this document, "DAS Protocols VII Multi-Vault Technical Non-Joinability Reference Implementation," is published at version 0.1.0 at . This appendix summarizes its scope and limitations so that the accompanying software is not read as more than it claims to be. A companion public disclosure develops the same architecture at greater length, including the breach-to-reconstruction threat model in . Unlike the separate execution-finality implementation referenced in , which is concerned primarily with whether an AI-generated tool call, API request, or external action may be invoked, this reference implementation addresses an earlier and structurally different security problem: access to identity is not authority to associate identity with content; access to content is not relationship authority; authorized reconstruction is not output authority; and computation is not release authority.

Implemented Protected Chain The reference implementation demonstrates the following chain, corresponding to the architecture defined in through : Reconstruction Authorization Object (RAO) -> Independent Vault-Local Release Decisions -> Session-Bound Components -> Protected Reconstruction Domain -> Ephemeral Minimum-Necessary Data View -> Provenance / Association Continuity -> AI Computation -> Sealed Candidate Output -> Live Output Verification -> Protected Output Validation Receipt (POVR) -> Output Release Capability -> Output Release Boundary -> Externally Usable Result ]]> Simply splitting a database into several tables or servers does not by itself establish Technical Non-Joinability. In this implementation, the relationship required to associate identity with substantive content is itself independently controlled authority: possession of an identity component and a content component is insufficient to construct the corresponding semantic relationship unless the Relationship-Mapping Vault independently authorizes that association within the permitted reconstruction scope.

What the Archive Demonstrates The archive demonstrates: independently controlled Identity, Content, and Relationship-Mapping Vaults; a non-bearer Reconstruction Authorization Object bound to session, workload, epoch, permitted fields, association scope, purpose, destination, and output conditions; independent Vault-Local Release Conditions; session-bound released components that cannot be reused in another reconstruction context; an explicit Permitted Association Scope separating permission to access a field from permission to associate it with another field or identity; a Protected Reconstruction Domain that reconstructs only the authorized fields and relationships; an Ephemeral Minimum-Necessary Data View rather than a permanently joined enterprise record; protected provenance linking reconstructed fields and associations to their originating vaults and authorization state; formation of a Candidate Output that remains non-authoritative for external release; AES-GCM sealing of the Candidate Output before release authority exists; commit-before-capability Protected Output Validation Receipt (POVR) behavior; an output-specific, destination-bound, and boundary-bound Output Release Capability; single-use consumption at the Output Release Boundary; denial on replay, output mutation, destination substitution, session substitution, workload change, epoch change, and missing relationship authority; parallel vault fan-out demonstrating that independent vault decisions need not be serial, consistent with ; and a legacy migration adapter demonstrating how an existing joined enterprise record can be progressively decomposed and mediated without rewriting the AI model. The included automated test suite contains 16 tests, covering authorized reconstruction and release as well as failure cases including missing relationship authority, unauthorized association, cross-session component reuse, changed workload measurement, output mutation, uncommitted POVR state, destination substitution, replay, policy-epoch change, wrong output boundary, poisoned sessions, and legacy-record decomposition. The package also includes a local benchmark. In the included reference run, using warm local components and sequential local vault operations, the median complete protected path was approximately 2.38 ms, consistent with the figures in . This figure characterizes the reference software only and is not a production latency claim: it excludes network RPC, geographically distributed vaults, remote attestation, HSM/KMS operations, distributed consensus, AI-model inference, production databases, external logging, and real external effectuation. The architecture addresses multi-vault latency through cold-path protected precomputation, concurrent vault-local release, minimum-necessary reconstruction, and a compact current-state hot path, as described in . Legacy integration is addressed through mandatory proxies, gateways, sidecars, wrappers, brokers, storage filters, model-serving layers, or output controllers, so that existing applications and AI models do not need to implement the complete multi-vault protocol internally.

Important Security Limitation This release is an executable architectural reference, not a production security system. The three vaults in v0.1.0 are logically independent Python objects running within one process. Their separate integrity secrets demonstrate independent release decisions and protocol relationships, but they do not provide real machine, administrator, TEE, HSM, or cloud-domain isolation. Full compromise of the Python process can therefore defeat the local reference boundaries. A production deployment would need genuinely independent protected domains, appropriate asymmetric cryptography and key management, hardware or confidential-computing isolation where required, authenticated service-to-service communication, production attestation and revocation infrastructure, durable rollback-resistant receipt state, mandatory alternate-path closure, and appropriate distributed-failure handling. The implementation does not claim to solve every form of semantic leakage, covert channel, model-internal information flow, inference attack, embedding leakage, or collusion among sufficient protected authorities. The correct interpretation of this release is therefore that it demonstrates that the multi-vault state machine defined in this document, and its distinction between access authority, association authority, reconstruction authority, computation, and output authority, can be implemented as runnable software. It does not by itself establish production-grade isolation or regulatory compliance.

Relationship to the Separate Agentic Tool-Binding Implementation This reference implementation should not be confused with the separate "tool_use Is Not invoke()" reference implementation associated with . That implementation primarily asks whether a specific AI-generated tool call may become effective. This document, and its reference implementation, ask an additional and earlier question: whether independently protected pieces of information may be semantically associated and reconstructed in the first place, and whether an AI-derived result from that reconstruction may leave the protected environment. The two architectures may ultimately operate together, but they solve different technical problems.

Running the Reference Implementation Locally The expected v0.1.0 test result is 16 tests run, with an OK status.

Standards Review FAQ The questions below are the ones a standards reviewer is most likely to ask about this profile, answered directly, in the second person, as they would be on a working-group list. Where an answer references machinery defined earlier in this document, the defining section is cross-referenced rather than re-explained.

Why is this an Internet protocol problem rather than merely an enterprise database architecture? You are not being asked to standardize how an enterprise partitions its database, which SQL engine it runs, how many physical vaults exist, whether those vaults sit in TEEs or HSMs, or how its internal Protected Reconstruction Domain is implemented. Keep treating those as deployment choices. The protocol problem starts once independently administered systems have to communicate and rely on reconstruction authority across a trust boundary. A single enterprise-AI transaction can involve a workload operated by one organization, identity information controlled by another service, substantive content held by a separate data domain, relationship-mapping authority under a different administrative or jurisdictional authority, and an output destination belonging to yet another system. At that point you are no longer asking whether two database tables may be joined. You need an interoperable way to express and verify which workload is requesting reconstruction, which fields may participate, which semantic associations may be formed, for what purpose, under which session and security epoch, for which destination, and under which current protected state. Treat the internal storage topology as implementation-specific; treat the authorization and assurance semantics as the interoperable part. A representative cross-domain flow looks like this: Keep the independently controlled Relationship-Mapping protection domain () distinct from ordinary partitioned storage. If you place data in different tables, shards, files, or servers but one application credential, administrator, query engine, or common control plane can still recombine everything, you have not established the independent association authority this profile requires. So ask yourself, at the protocol level, whether the independently controlled parties can exchange enough machine-verifiable state to answer: is this the authorized workload and execution context; is this reconstruction request bound to the correct session; which fields may be released; which relationships among those fields may be formed; is the authorization still valid under the current Policy Epoch and Session Epoch; did each required vault independently approve its part; can the resulting components be used only in the authorized reconstruction context; is provenance preserved through processing; is the resulting output permitted for this recipient and destination; has the required protected validation evidence been committed; and is the protected release boundary actually enforcing the expected conditions. Those are interoperability questions precisely because the participants need not share a database, implementation language, operating system, cloud provider, security module, or administrative domain. This is also why you can treat the architecture as complementary to existing IETF work rather than a replacement for it. RATS can give you evidence about the workload or the protected reconstruction environment. The distinction you should keep in mind is the same one drawn in : attestation establishes whether an execution environment is acceptable; finality determines whether a particular pending release currently has authority to become externally effective. Attestation may tell you that a protected multi-vault reconstruction mechanism is present, but the Attestation Result should not itself become permission to form a particular identity-content association. Likewise, an authorization protocol can carry reconstruction-related authorization state, but you should require that state to remain load-bearing when the independently controlled vaults make their release decisions and when the resulting output reaches its release boundary. So do not ask the IETF to standardize the SQL schema, the database vendor, the number of physical servers, the vault storage engine, the cloud topology, the TEE vendor, the HSM implementation, the AI model architecture, or the internal Protected Reconstruction Domain implementation. Ask it, where you want interoperability, to help you standardize: workload identity and execution-context binding; reconstruction-authorization semantics; the permitted field set; Permitted Association Scope; purpose binding; session, nonce, and epoch semantics; vault-local release evidence; component/session correspondence; provenance commitments; destination and recipient binding; revocation and freshness state; output-validation evidence; output-specific release authority; and protected-boundary assurance. The vault implementation stays local; the authority and assurance semantics are what need to interoperate.

Why not just use ABAC, RBAC, ACLs, or a database join policy? Keep using RBAC, ABAC, ACLs, and conventional database policy — they still answer whether principal P may read resource R, invoke operation O, or access field F. What they do not answer is the problem this profile adds: permission to access two pieces of information does not necessarily give you permission to associate them. You can have identity access permitted, content access permitted, and the identity-to-content link still not permitted. A conventional application holding both datasets can simply join them locally — at that point relationship authority has collapsed into application possession. Treat the relationship itself as a separately governed security object (). Access to identity and access to content should not, on their own, give you authority to decide that a particular identity corresponds to a particular content object — data-access authority is not automatically association authority. ABAC or OAuth-style policy can help you express that authorization, but you need the association restriction to stay load-bearing during reconstruction rather than degrade into advisory metadata handed to an application that already has everything.

Is the Relationship-Mapping Vault just another database? No — and if you implement it as one without independent authority over association, you have not established Technical Non-Joinability, no matter how it is stored. Store the mapping in a conventional database, an encrypted index, a key-value store, a graph database, a protected resolver, or a cryptographic commitment system if you like; what matters is that no single application credential, administrator, query engine, service account, common root key, or shared control plane can recover identity, content, and mapping information without an independent decision from each. If one party can do that, your separation is cosmetic. Hold yourself to this invariant: possession of the independently released data components must not itself supply the missing association authority.

What happens when one required vault is unavailable? Fail closed. If identity, content, and relationship authority are all required for a given reconstruction, do not treat two successful responses as license to treat the third domain as implicitly approved. That does not force you into poor availability — reach for protected replication, redundant authorities, quorum systems, geographically distributed replicas, or protected failover nodes instead. Keep the distinction sharp: protected replication, where the same authority stays enforceable, is acceptable; permissive fallback, where you bypass an authority because it is unavailable, is not. Build your profile so it distinguishes unavailability of the authority from absence of the authority — you can stay highly available without letting an unavailable security decision silently become an authorization.

What is the consistency model across multiple vaults? Do not treat a reconstruction as a collection of unrelated successful reads. Require the released components to correspond to the same reconstruction context: session, workload identity, request/reconstruction identifier, policy epoch, security epoch, association scope, purpose, and destination where applicable. Do not let a component produced under one security epoch silently combine with a component produced after a material policy transition, and do not combine stale mapping information with newly released identity or content just because each was individually valid at some point. Bind each vault-local release to a common reconstruction/session commitment, and if one required decision fails or material state changes mid-reconstruction, invalidate or poison the partial reconstruction rather than caching it indefinitely and completing it later under different conditions. Leave the exact distributed-consistency mechanism as an implementation choice; hold the line only on the requirement that every load-bearing component correspond to the same acceptable reconstruction state.

How are concurrent releases from multiple vaults made sufficiently atomic? You do not need every vault in one global database transaction. You do need to prevent the failure where individually valid components from incompatible states get combined into an apparently valid reconstruction. Bind every vault-local result to a common Reconstruction ID, Session ID, Policy Epoch, Security Epoch, workload measurement/context, association-scope digest, and authorization digest, so each vault can authorize its own component while committing it, cryptographically or logically, to the same reconstruction context. You can still run the vaults in parallel (): Identity Vault RAO / Session -+-> Content Vault +-> Relationship Vault ]]> Accept the set into the Protected Reconstruction Domain only when every mandatory component and its binding corresponds. If two vaults authorize and the third denies, you have no complete authorized reconstruction — discard the successful partial releases, invalidate them, mark the session poisoned, or allow a narrowly controlled retry under unchanged state. Do not treat partial success as permission to bypass the missing authority.

What exactly does "ephemeral reconstruction" mean? Do not read "ephemeral" as just "stored in RAM." What you actually need is that the joined representation is created only within an authorized reconstruction context and never becomes an unrestricted persistent enterprise record. Build your Ephemeral Reconstructed Data View so that it is bound to the reconstruction session; limited to the permitted fields and associations; unavailable as a general-purpose joined dataset; invalidated when the session ends or is poisoned; unavailable to unrelated future workloads without new authority; and incapable of becoming a durable alternate join path. Depending on your assurance level, hold the temporary representation in protected application memory, a TEE, a confidential-computing environment, protected accelerator memory, an isolated process, or another Protected Reconstruction Domain — the term describes a lifecycle and authority property, not one particular memory technology.

Can an AI infer a forbidden relationship even if the Relationship-Mapping Vault never provides it? Possibly, and you should not claim otherwise. Do not describe Technical Non-Joinability as proof that a sufficiently capable AI can never infer a protected relationship from indirect evidence — geographical clues, writing style, timestamps, rare attributes, organizational structure, or repeated outputs can sometimes allow probabilistic re-identification. What you are actually enforcing is narrower and technically checkable: the system does not directly hand over protected association authority merely because the individual information components are accessible. Reach for minimum-necessary field release, provenance tracking, association-scope restrictions, cumulative disclosure state, output filtering, disclosure budgets, Candidate Output validation, and output finality to reduce specific inference and reconstruction pathways, but do not represent any of that as proving semantic inference is universally impossible. Say it this way instead: Technical Non-Joinability controls authorized formation and externalization of protected relationships; it does not claim universal prevention of statistical or semantic inference.

What if several individually permitted outputs collectively reveal a prohibited relationship? That is a cumulative-disclosure problem, and a decision based only on the current output will not catch it — Output A, B, and C can each be harmless alone and still reveal a protected relationship together. Maintain protected disclosure or association state across releases in a higher-assurance deployment, and have your validation process weigh previous disclosures, current reconstruction scope, recipient, destination, session, purpose, and policy epoch before permitting another output. That means you should be willing to deny an output that would normally be acceptable once the accumulated disclosure would cross a protected threshold. This mirrors the extraction-state controls in : treat the relevant security state as cumulative rather than per-request only, the same way that draft treats rollback resistance, atomic consumption, and replay resistance as load-bearing wherever repeated releases matter.

Who decides whether an association is ethically or legally permissible? Not the protocol, and do not let it try. Its job is to enforce a machine-readable authorization decision supplied by the appropriate policy authority — a data controller, the enterprise, the data subject's consent state, a contractual rule, a legal requirement, a regulator, a security administrator, a tenant, a jurisdiction-specific authority, or a multi-party governance arrangement. The enforcement mechanism checks whether the declared conditions are satisfied; it does not check whether those conditions are ethically justified. Keep that distinction visible in your standards text: the mechanism enforces declared authority, it does not confer legitimacy on the authority itself. Governance, legal basis, due process, appeal mechanisms, proportionality, and human-rights questions stay with the relevant institutional and legal frameworks.

Could this architecture itself be used for censorship or excessive surveillance? Yes — say so plainly rather than hiding it. Any sufficiently powerful authorization or enforcement infrastructure can be misused. Build in design principles that push back against unnecessary concentration of power: purpose limitation; minimum disclosure; independently controlled authorities; scoped association authorization; selective disclosure; auditable policy identifiers; short-lived authority; revocation; multi-party approval for especially sensitive associations; and avoidance of unnecessary globally stable identifiers. Do not let technical enforceability stand in for normative legitimacy — a policy is not legitimate merely because the architecture can technically enforce it. The architecture addresses only the former.

Who is allowed to see the association graph? Ideally, nobody needs unrestricted access to the whole association graph just to check one requested association. Instead of returning the complete identity-content relationship database, have the Relationship-Mapping authority answer a narrower question: is the association between Identity I and Content C permitted for Workload W, Purpose P, Session S, and Scope A? Return a scoped authorization, a protected response, a cryptographic commitment, or a session-bound mapping component — give relying parties only what the requested reconstruction actually needs. Apply the same minimum-disclosure principle already used for attestation evidence in : disclose only what appraisal requires, not detailed operational state.

Could the Relationship-Mapping Vault itself become a surveillance super-database? Do not assume it has to hold one plaintext universal graph of every identity and every content object — if it does, you have built a high-value surveillance and compromise target. Use opaque references, partitioned mappings, pseudonymous identifiers, cryptographic commitments, scoped lookup services, threshold-controlled mapping, tenant-specific namespaces, purpose-specific resolvers, protected computation, or multi-authority reconstruction instead. Design the relationship authority so it can answer only "is association X permitted under authorization Y?" without exporting the underlying graph, and in a high-assurance deployment, split mapping control so no single operator holds enough information to reconstruct every protected relationship on their own. Read "Relationship-Mapping Vault" as an authority domain, not necessarily a centralized plaintext database.

What happens if the Relationship-Mapping Vault is compromised? Do not claim that compromise of every load-bearing trust component is harmless — if an attacker fully controls the authority responsible for deciding relationships, that compromise can undermine the association-control property. Answer it with defense in depth: hardware-isolated keys, attested enforcement, threshold authorization, multiple independent mapping authorities, tenant approval, jurisdictional approval, policy-epoch revocation, short-lived session binding, provenance continuity, output-time revalidation, and Output Release Boundary enforcement (). Keep this distinction: compromise of one mapping authority might let it issue an improper mapping decision, but it should not automatically hand over authority to externalize the resulting information if your independent reconstruction and output-finality checks stay load-bearing. Your security objective is not "no component can ever be compromised" — it is that compromise of one component should not unnecessarily collapse every remaining independent security boundary.

Why not just use a data clean room? Use one — this architecture does not ask you to replace it. A clean room gives you a controlled environment for processing participating datasets while restricting raw-data access and exported results. What you still need, before and during reconstruction, is an answer to a different question: should these independently protected information domains be associated at all, and under what exact authority? A typical clean-room question is "these datasets are inside the controlled room — what computations and exports are allowed?" The multi-vault question is "has authority first been established to form this particular semantic relationship between these independently controlled domains?" You can let a clean room serve as part of the Protected Reconstruction Domain — it does not on its own replace the independent Relationship-Mapping authority or the downstream execution-finality controls that continue past reconstruction into sealed Candidate Output, live validation, protected receipt, output-specific authority, and the Output Release Boundary ().

What exactly could be standardized by the IETF? This is probably the question that matters most, so keep the boundary explicit. Do not ask for standardization of vault database engines, SQL schemas, cloud providers, TEE vendors, HSM models, AI-model architecture, enterprise storage topology, encryption algorithms beyond existing IETF mechanisms, internal Protected Reconstruction Domain implementation, or organizational governance structure. Ask instead for the narrower, genuinely interoperable surface: a Reconstruction Authorization identifier; workload and execution-context binding; request and session identity; the Permitted Field Set; Permitted Association Scope; purpose binding; a policy identifier; Policy Epoch; Session/Security Epoch; destination and recipient binding; vault-local release status; component correspondence; freshness state; revocation state; provenance commitment; association-provenance commitment; Candidate Output identity; output-validation evidence; output-specific release authority; one-time or bounded consumption state; protected reconstruction assurance; and Output Release Boundary assurance. Reuse existing IETF mechanisms wherever you can. RATS can establish that the expected reconstruction and finality controls exist and are running in an acceptably measured environment — the same separation this document's companion RATS draft already uses for model-state release control: RATS communicates evidence about the enforcement mechanism, while the act-specific bounded authority decides whether a particular Candidate Release may cross the boundary. WIMSE can supply or help establish workload identity and runtime execution context, which you then bind to reconstruction authority: OAuth can give you authorization and delegation machinery and carry rich authorization state; your remaining question is whether that authorization stays load-bearing through independent vault release, protected reconstruction, and final output release, rather than terminating at the point where a client obtains a token. Frame the standards proposition this way: do not standardize the vaults. Standardize, where interoperability requires it, the semantics by which independently administered systems express, bind, verify, and preserve reconstruction authority, association scope, execution context, freshness, provenance, and externally effective release constraints.

Changes Since draft-das-enterprise-ai-output-finality-01 (and Since -00) This section is to be removed by the RFC Editor before publication. Items 1 through 10 below were introduced in -01 (relative to -00); item 11 is new in this revision (-02, relative to -01).

1. -01: Bumped the document from -00 to -01.
2. Added , an illustrative example showing how compromise of a single AI-connected server can be correlated into a reconstruction of an enterprise's, or a defense/critical-infrastructure organization's, probable future rather than a mere copy of stored rows.
3. Added , addressing the latency and legacy-system-compatibility objections to a multi-vault architecture.
4. Specified, within , the separation of a cold path (protected precomputation) from a hot path (current checks whose omission would permit unauthorized reconstruction or release).
5. Clarified that Technical Non-Joinability does not require serial vault evaluation, and specified permissible parallel vault-local release fan-out once a valid Reconstruction Authorization Object is established.
6. Added guidance on model-agnostic deployment through a protected intermediary, and an incremental, conservative migration path for legacy databases holding complete joined records.
7. Added quantitative latency observations from the accompanying runnable Python reference implementation's 500-iteration microbenchmark, labelled as reference-code observations rather than protocol latency guarantees.
8. Added an explicit non-bypassability requirement distinguishing sidecar-style mediation from fully mediated deployments in which no unmediated alternative path to protected data or an external-effect boundary remains.
9. Added , summarizing the published v0.1.0 reference implementation: its implemented protected chain, test-suite coverage, benchmark figures, an explicit security limitation notice describing it as a single-process architectural reference rather than a production isolation system, and its relationship to the separate agentic tool-binding reference implementation.
10. Added the reference implementation's GitHub source () and two companion public disclosures (, ) as informative references, and expanded into a full cross-reference across the author's execution-finality Internet-Draft series.
11. -02: Added , a second-person "Standards Review FAQ" answering the sixteen questions a working-group reviewer is most likely to raise about this profile — why it is a protocol problem rather than a database design, its relationship to ABAC/RBAC/ACLs and to data clean rooms, vault unavailability and consistency semantics, ephemeral reconstruction, the limits of Technical Non-Joinability against semantic inference and cumulative disclosure, governance and censorship-risk framing, and the specific, narrow interoperability surface this document proposes for IETF standardization.
12. -02: Bumped the document from -01 to -02; updated the document date accordingly. No change was made to the normative requirements in , , or .
13. -02: Added a personal, first-person illustrative paragraph as the new lead paragraph of the Abstract, using the author's own patent-drafting and prosecution workflow to make concrete that credential theft against an AI assistant can expose unfiled invention ideas, filing strategy, and competitive-defense plans that were never stored together as a single record — distinguishing this risk from a simple data-chunk takeover of already-existing files.
14. -02: Added, as the second and third sentences of the Abstract's lead paragraph, an explicit short-term-pain versus existential-risk contrast: a stolen data chunk is recoverable, but an enterprise's or individual's mapped future falling into a competitor's hands is not.
15. -02: Replaced the Abstract in full with an expanded version built around two extended illustrative examples — a company CEO whose AI assistant's day-to-day use could be correlated by an attacker into unannounced acquisition, product, and patent-filing strategy, and a senior government official whose assistant's fragments could be correlated into an unannounced foreign-policy position — introducing the terms enterprise-future reconstruction, Technical Non-Joinability, and Technical Non-Completability, and restating the full protected sequence from independent data authority through the Output Release Boundary. This superseded, rather than supplemented, the shorter Abstract text introduced earlier in this revision and in -01.
16. -02: Moved the two-example narrative above (CEO acquisition/patent-strategy example; senior-government foreign-policy example; the enterprise-future reconstruction definition; and the introduction of Technical Non-Joinability and Technical Non-Completability) out of the Abstract and into a new section placed immediately after , so that this material now serves as extended threat-model and need-of-the-hour motivation in the body rather than as Abstract text. Replaced the Abstract with a short, formal IETF-style paragraph stating the specification's scope: the architectural framework and metadata profile, the RAO-based Technical Non-Joinability mechanism, the Output Release-Boundary-based Technical Non-Completability mechanism, and the token schemas, cryptographic bindings, and boundary validation sequences this document defines.
17. -02: Added a closing sentence to the Abstract politely directing readers to review and in full, so that the complete problem description and motivating scenarios moved out of the Abstract in the previous item are not overlooked.