Independent

Balasore Odisha India info@sangamdas.com

Security Independent Submission AI security execution-consequence decoupling technical non-joinability mandatory mediation protected authorization enterprise data vaults output finality DAS Protocols assume breach high-risk AI enterprise AI prompt injection data exfiltration banking defence public sector critical infrastructure Start from the assumption that the attacker already controls the AI server — that the workload is fully compromised. Not the perimeter, not a phished seat — the workload itself: its credentials, its connectors, its context window, its output path. Nearly every enterprise control in use today has already failed by that point, because nearly every one of them is designed to keep the attacker out of the workload rather than to limit what the workload can do once it is theirs. Before anything else, the engineering posture: this architecture is specified for high-risk AI systems, where the standard priorities shift from speed and latency toward determinism, containment, and safety. It is written for billion-dollar enterprise and mission-critical deployments — banking and treasury, defence and national security, critical infrastructure, and regulated enterprises holding unreleased material — and not for general day-to-day, consumer-grade, or low-stakes use. It introduces evaluation on the join path and on the release path, and accepts that cost deliberately, because in these environments an unauthorized reconstruction or an unauthorized send is not recoverable by being fast. This document asks what is still denied to the attacker at that moment, and specifies an architecture in which two things are still denied: the attacker cannot cause independently held enterprise fragments to be bound into a map of the organization, and cannot cause any generated result to become externally effective. Access to a store is not authority to join it to another store. Finishing a generation is not authority to send it. The mechanism is Execution-Consequence Decoupling, enforced by three pillars: Decomposition of Authority (Technical Non-Joinability) across independently controlled identity, content, relationship-mapping, and cryptographic domains; Mandatory Mediation of every consequence-bearing Candidate Output; and Technical Non-Completability, so that computation can run to completion in a compromised environment without the ability to complete an external consequence. Reconstruction is governed by a non-bearer Reconstruction Authorization Object bound to attested execution context, session, purpose, and Permitted Association Scope. Candidate Outputs are sealed, re-verified at output time, and committed to a Protected Output Validation Receipt before an output-specific Release Capability can be issued and exercised at a designated Output Release Boundary. The industrially relevant systems are the enterprise assistant and agent runtimes now deployed into exactly those environments, including those built on Anthropic Claude, OpenAI ChatGPT, Google Gemini, xAI Grok, and self-hosted Meta Llama models, together with the connector and Model Context Protocol fleets attached to them. These are named as publicly described deployment classes, because an architecture for high-risk enterprise AI should say plainly which systems it is about; nothing here characterizes any vendor's internal design or security posture, and no vendor has reviewed or endorsed this work. It states the problem space, compares the architecture against representative conventional technologies (access control, bearer credentials, vaulting, TEEs, sandboxes, DLP, provenance, DRM, clean rooms, and information-flow control), gives a detailed technical description, and supplies JSON Schema definitions for the three protected objects. A published runnable reference implementation executes the protected chain described here, so the architecture can be run and tested rather than only read; it is an architectural reference for the state machine and its failure states, not a claim of production isolation. This is the architecture and rationale document. Its companion, draft-das-enterprise-ai-output-finality , specifies the same split as a deployable protocol profile and metadata format for vendor assistant and agent seats. The two are read together: this document explains why authority must be separated from computation; the companion specifies the objects, bindings, and boundary sequences that carry the separation on the wire.

Introduction

Scope and Relationship to the Wider Execution-Finality Work This document describes a focused enterprise-data and artificial-intelligence application of a general execution-finality architecture. The general form is stated in : existing Internet layers answer questions about information — how it is transported, whether the channel is protected, who may delegate access, whether a credential is valid, what happened and in what order — and none of them answers whether a specific machine-generated act was authorized to become externally effective. That general framework separates computation from authorized effectuation through Protected Authorization State, Mandatory Mediation, protected validation evidence, scoped Release Authority, Technical Non-Completability, and verification at a final consequence-bearing boundary. The enterprise consequences of the same split, stated for a non-specialist audience, appear in . This document applies and further develops those principles specifically for:

• independently controlled enterprise-data vaults;
• separately protected identity, content, relationship-mapping, and optional cryptographic-material domains;
• non-bearer reconstruction authorization;
• Technical Non-Joinability outside an authorized reconstruction session;
• session-bound component release;
• ephemeral minimum-necessary reconstruction;
• Sealed Candidate Outputs;
• live output-time verification;
• Protected Output Validation Receipts;
• output-specific Release Authority; and
• Output Release Boundary control for artificial-intelligence processing.

Relationship to the Companion Internet-Drafts This document is the architecture-and-rationale half of a pair. The other half is , available at https://datatracker.ietf.org/doc/draft-das-enterprise-ai-output-finality/03/, which specifies the same split as a deployable protocol profile: the authorization objects, the cryptographic bindings, the boundary validation sequences, the JSON interoperability profile, and the mapping onto vendor assistant and agent seats, connectors, and MCP fleets. Where the two documents overlap, they are deliberately different in framing rather than in mechanism. This document argues from the compromised workload inward and explains why authority must be separated from computation. The companion argues from the missing layer outward and specifies what must appear on the wire for the separation to be interoperable. An implementer needs the companion; a reviewer deciding whether the problem is real should start here. The wider series shares one invariant — computation does not itself confer authority for a consequence — across different consequence boundaries, and the profiles compose rather than compete:

• states the umbrella vocabulary: Candidate Act, Non-Effective State, Protected Enforcement Domain, Execution Handle, Finality Sink.
• and govern the tool-dispatch boundary, the latter binding the profile onto tool_use, computer_use, function calling, and MCP tools/call. A generated tool call that would disclose a reconstructed view must satisfy both this document and those: authority to join here, act-bound dispatch authority there.
• governs whether data obtained under one declared purpose may be reused for another, and extends that reasoning to model capability itself. That is a different predicate from the one here: purpose compatibility does not establish join authority, and join authority does not establish purpose compatibility. A deployment subject to both evaluates both.
• and carry the same mechanism into regulatory enforcement and jurisdictional control without blanket data localisation.
• applies the split to release of model information itself, for deployment by model creators.

Revision numbers cited here are point-in-time. Each reference entry carries an IETF Datatracker link; readers should follow it rather than assume the cited revision is current.

Motivation: A Compromised AI Server Must Not Become a Map of the Enterprise’s Future Modern enterprise security is built on a broken assumption: the application server is treated as a trusted boundary. That assumption may have been manageable when applications performed narrow, predefined operations. It becomes dangerous when an artificial-intelligence workload can retrieve information from databases, vector stores, internal communications, customer systems, research repositories, source-code platforms, financial systems, and external tools—and then infer relationships across all of them. A conventional data breach may expose a collection of existing records. A compromised enterprise AI server may do something more damaging: it may continuously correlate those records, reconstruct confidential relationships, infer future products and strategies, identify operational weaknesses, and generate a structured map of what the enterprise is likely to do next. That intelligence may be transferred, sold, or exploited by competitors, hostile actors, or criminal markets, potentially undermining years of research, investment, negotiation, and commercial planning. The security problem is therefore no longer merely “How do we prevent unauthorized access to data?” The more important question is: “How do we prevent compromised computation from becoming an unauthorized real-world consequence?” The failure-mode change behind that question — that isolation of join authority and isolation of effectuation now matter more than another increment of model capability — is argued in . This document introduces the corresponding transition from conventional perimeter-based security to Execution–Consequence Decoupling. Under this architecture, the ability to compute a result is separated from the authority required to make that result externally usable or effective.

Problem Space

Technical Field The present disclosure relates generally to computer security, enterprise data storage, artificial-intelligence infrastructure, confidential computing, protected data reconstruction, information-flow control, authorization systems, provenance enforcement, and control of computer-generated outputs. More particularly, the disclosure relates to technical architectures for:

• separating semantically different components of an enterprise record among independently controlled protected domains;
• authorizing temporary reconstruction of selected fields and selected associations for a defined artificial-intelligence processing purpose;
• binding reconstruction authority to an attested execution context and protected session state;
• maintaining protected source and association information through artificial-intelligence processing;
• preventing an artificial-intelligence workload from independently releasing a generated result;
• verifying a generated Candidate Output against current authorization, provenance, association, destination, recipient, and disclosure conditions;
• committing protected validation evidence before release authority exists; and
• permitting an output or operation to become externally effective only at a protected Output Release Boundary.

The disclosure addresses not merely whether an artificial-intelligence workload may read data, but whether computation performed using protected data may be converted into an externally usable or consequence-bearing result.

Technical Context and Processing Chain Modern enterprise computing systems increasingly connect artificial- intelligence models, agents, retrieval systems, databases, vector stores, communication services, external tools, application programming interfaces, and automated decision systems. An artificial-intelligence workload may retrieve information from several systems, associate information originating from different records, infer relationships not expressly stored in one source, generate human-readable content, invoke tools, update databases, communicate with external systems, or initiate physical or financial operations. The relevant security problem is no longer limited to protecting a static record from unauthorized reading. The technical problem extends across a processing chain that may include: A security decision performed at the beginning of this chain may not remain sufficient at the end of the chain. Data that was initially accessed for a permitted purpose may later be associated with an identity outside the permitted scope, transformed into a new representation, combined with information from another vault, inserted into a prompt or tool request, written into persistent agent memory, submitted to a downstream model, included in a generated communication, released to a different recipient, sent to a different jurisdiction, used after authorization has been revoked, or converted into an external action. The present technical environment therefore creates a gap between authority to access data and authority to make the result of processing externally effective.

Persistent Enterprise-Record Exposure Many enterprise systems persist identity information, substantive content, and the relationships between them in a directly queryable record, table, document, object, graph, or joined database structure. Even where data is encrypted at rest, an application or privileged service may receive authority to retrieve the complete joined record after decryption. This creates several technical risks:

1. Compromise of one application credential, database interface, privileged account, or administrative plane may expose both the protected content and the identity-content relationship.
2. A workload granted access to selected fields may be able to query, infer, or reconstruct relationships outside the intended purpose.
3. Once a complete or substantially complete record has been delivered to an artificial-intelligence workload, later controls must attempt to govern a workload that already possesses the semantically usable information.
4. Conventional storage permissions may distinguish tables, rows, columns, objects, or files but may not independently control whether two individually accessible values may be associated with one another.

The technical problem is therefore not solved merely by splitting a record into multiple database columns or storage locations if one credential, one query interface, one administrator, or one application process can rejoin the separated values without independent authorization.

Artificial-Intelligence Reconstruction and Correlation Risk Artificial-intelligence workloads can derive or regenerate relationships even where direct identifiers have been removed. A workload may associate protected information using names, aliases, contact information, account identifiers, employee or device identifiers, location data, temporal patterns, behavioural characteristics, quasi-identifier combinations, vector similarity, semantic similarity, retrieval context, prior conversation state, tool responses, or model inference. Conventional field-level redaction or pseudonymization may not prevent reconstruction of an identity-content association. A data item may appear non-identifying in isolation while becoming identifying when combined with another data item. Several individually permissible output fragments may cumulatively disclose a prohibited relationship. This risk is increased in agentic systems because a workload may make repeated queries, call several tools, maintain memory, pass information to another agent, retrieve from a vector store, encode information in structured arguments, or distribute disclosure across several output channels. The security architecture must therefore govern not only individual fields, but also protected associations, cumulative disclosure, provenance, and downstream effectuation.

Separation Between Processing Authority and Output Authority Existing systems commonly make access decisions when data is requested. After access is granted, the workload may receive plaintext, a decrypted object, a database result, a model context, or an application-visible representation. The workload may then possess sufficient practical control to copy, encode, paraphrase, generate a derived disclosure, place information in a tool argument, write to memory, store in another system, or transmit through an available output interface. A later output policy may attempt to inspect the generated result, but the workload may already possess an independently releasable representation or may have access to an alternate path. This creates a structural weakness: the system attempts to regulate release after the workload has already acquired the technical ability to release. A need therefore exists for an architecture in which computation may proceed, a Candidate Output may be generated, but the workload does not thereby acquire Release Authority.

Time-of-Check-to-Time-of-Use Risk An artificial-intelligence execution context may change after reconstruction authorization is granted. Model weights may be changed, agent code updated, a tool substituted, a runtime migrated, a container or virtual machine cloned, the workload moved to another cloud region, a policy updated, authorization revoked, a use count exhausted, a destination or recipient changed, or a session expired or poisoned. An authorization decision made when data was reconstructed may therefore be stale when an output is later transmitted, rendered, committed, or invoked. A system that verifies execution state only once at the beginning of processing may permit a later output under conditions different from those originally approved. The technical problem includes closing the interval between initial authorization, processing delay or state change, and external effectuation.

Prompt Injection and Compromised-Workload Risk Artificial-intelligence workloads may be influenced by malicious prompts, retrieved content, external tools, compromised model weights, altered agent code, or adversarial instructions. Such a workload may produce a Candidate Output that violates the intended policy even though the original enterprise request was legitimate. Examples include disclosure of protected identity information, generation of an unauthorized identity-content association, transmission of protected values through tool parameters, creation of an unauthorized database write, inclusion of protected information in a retrieval query, submission of enterprise data to an external model, use of filenames, headers, metadata, or encodings as an exfiltration path, or initiation of an unauthorized external action. A sandbox or secure execution environment may contain the workload during computation, but containment during computation does not necessarily establish whether a later output is authorized for a specific destination and purpose. The architecture must therefore tolerate the possibility that the workload itself generates a noncompliant result.

Streaming and Cumulative-Disclosure Risk Many artificial-intelligence systems generate output incrementally. A token, audio segment, image region, structured field, partial tool argument, or partial application-programming-interface payload may become externally usable before the complete output has been generated. If verification occurs only after completion, earlier portions may already have crossed the output boundary. Additionally, several segments that appear permissible individually may cumulatively disclose an identity, a protected association, a prohibited event, a sensitive category, or information exceeding a disclosure limit. The technical problem therefore includes controlling per-segment release, cumulative semantic disclosure, rolling association state, and final whole- output effectuation.

Replay, Rollback, and Partial-Session Risk A protected session may terminate after some operations have already occurred. One or more vaults may have released components, reconstruction may have partially completed, temporary keys may have been generated, a Candidate Output may have been formed, a validation receipt may have been prepared, or a provisional capability may have been created. An attacker may attempt to reuse captured components, authorization objects, receipts, keys, capabilities, snapshots, or stale session state to resume or complete the interrupted operation. Virtual-machine snapshots, storage backups, container restoration, process restart, and distributed failover may also restore stale authorization state. A technical need exists to prevent a terminated session from being resumed or reconstructed from captured partial artifacts while still permitting a later legitimate request to begin under fresh authorization.

Composite Technical Problem There remains a need for a computer architecture capable of maintaining technical control over the complete transition from enterprise data storage to externally effective artificial-intelligence output. The architecture should address, in combination, the following technical problems:

1. preventing one storage authority from automatically obtaining a complete semantically usable enterprise record;
2. independently controlling identity information, substantive content, relationship-mapping information, and reconstruction-enablement material;
3. distinguishing permission to access fields from permission to associate those fields;
4. binding reconstruction authority to an attested artificial-intelligence execution context and protected session;
5. preventing copied authorization artifacts from functioning as freely transferable bearer authority;
6. preventing released components from being reused outside the authorized reconstruction session;
7. creating only a purpose-limited and association-limited reconstructed view;
8. maintaining protected correspondence between source components, derived values, and Candidate Outputs;
9. tolerating a compromised or prompt-injected workload that may generate a prohibited Candidate Output;
10. preventing the workload from independently releasing that Candidate Output;
11. re-establishing current authorization immediately before external effectuation;
12. detecting direct, indirect, inferred, and cumulative unauthorized associations;
13. making protected validation commitment a technical prerequisite to Release Authority;
14. binding Release Authority to the exact verified output, destination, recipient, session, and Output Release Boundary;
15. rejecting stale, ambiguous, unavailable, inconsistent, or unverifiable protected state;
16. controlling streamed and fragmented outputs before each externally usable release; and
17. preventing replay or completion of interrupted sessions using captured stale artifacts.

Limitations of Representative Conventional Approaches The following discussion identifies representative categories of conventional technology for explaining the technical context. It is not an admission that any particular reference, system, or combination constitutes prior art against any claim, or that any identified feature was necessarily known or conventional at any relevant date.

Conventional Access-Control Systems Role-based access control, attribute-based access control, database permissions, file permissions, and policy engines may determine whether a requester can access a resource. Such systems are useful for controlling access to a database, table, field, file, object, API, or other resource. However, conventional access control commonly terminates its principal decision at resource access. Once data is released to an authorized process, the access-control system may not technically control which associations the process later forms, which intermediate values are created, which outputs are generated, whether authorization remains current at output time, or whether the generated result becomes externally effective. The present disclosure distinguishes access authority from reconstruction authority, processing authority, and output Release Authority.

Bearer Tokens, API Keys, OAuth Credentials, and Similar Artifacts Bearer tokens, session cookies, API keys, delegated-authorization tokens, and similar credentials may carry identity, role, resource, or scope information. Such mechanisms commonly authorize a request when the presented credential is valid. A copied bearer credential may, however, be exercised by a possessor unless additional context-binding mechanisms are imposed. Descriptive fields stating a purpose, destination, or scope do not necessarily make the credential non-bearer where the enforcing service does not verify correspondence with a particular measured execution context, a protected session, a Session Epoch, a Protected Reconstruction Domain, a permitted association scope, and current protected state. The disclosed Reconstruction Authorization Object is not merely a token describing access rights. Its exercise is conditioned on correspondence with protected execution and session state, and possession alone is insufficient.

Database Sharding, Data Vaulting, Tokenization, and Pseudonymization Database partitioning, data vaulting, sharding, tokenization, masking, and pseudonymization may reduce exposure of directly identifying values. However, a storage arrangement does not provide independent association control where one query engine can rejoin all components, one privileged credential controls all domains, mapping information is available through the same authority, or the application may freely reuse retrieved components. The disclosed architecture treats relationship-mapping information as an independently controlled protection domain and distinguishes authority to retrieve components from authority to associate those components. Released components are further session-bound or restricted to a Mandatory Mediation Path rather than converted into generally reusable data objects.

Trusted Execution Environments and Confidential Computing Trusted execution environments, secure enclaves, confidential virtual machines, and secure coprocessors may protect code and data from selected external attackers while computation occurs. Such technologies may provide memory isolation, measurement, attestation, key protection, or confidential execution. A trusted execution environment alone, however, does not necessarily define which enterprise fields may be reconstructed, which identity-content associations are permitted, which purpose governs processing, which destination may receive the result, whether authorization remains current at output time, whether a validation receipt must be committed before release, or whether the generated result remains non-effective until boundary verification. The disclosed architecture may use a trusted execution environment as one protected implementation substrate, but the claimed technical relationship is not merely execution inside a trusted environment. The architecture controls the transition from independently protected components to an externally effective result.

Sandboxes and Application Containment A sandbox may restrict files, devices, network interfaces, system calls, or other resources available to a workload. Containment may reduce the workload’s ability to communicate directly with external systems. However, a sandbox does not necessarily establish a purpose-bound reconstruction architecture or a receipt-backed output-finality process. A sandbox may permit an approved output channel without determining whether a particular Candidate Output contains an unauthorized association, exceeds a disclosure budget, is directed to the authorized recipient, corresponds to current policy and revocation state, or is bound to a committed validation receipt. The disclosed architecture may employ sandboxing, but adds protected authorization continuity and output-finality conditions not supplied merely by containment.

Data-Loss-Prevention and Output-Filtering Systems Data-loss-prevention systems, content filters, moderation classifiers, and output gateways may inspect data before or during transmission. Such systems may detect keywords, patterns, data categories, personal information, or policy violations. However, an ordinary filter may operate on plaintext that is already available to the workload or to an untrusted application process. It may also operate as an advisory classifier, a monitor, a post-release detector, or one optional output route. Such a filter does not provide Technical Non-Completability where the workload retains another path capable of transmitting, storing, rendering, or invoking the result. Further, an ordinary filter may lack protected continuity with the source vaults, the Reconstruction Authorization Object, the permitted field set, the Permitted Association Scope, the original processing purpose, the current execution context, and the current Protected Session State. The disclosed Output Verification Stage participates in a Mandatory Mediation Path and operates before Release Authority exists.

Provenance, Logging, and Audit Systems Provenance systems, event logs, security logs, blockchains, and audit records may provide evidence that a data access or output event occurred. Such evidence may be useful for investigation, accountability, or compliance. A post-event log, however, does not prevent the event from occurring. Similarly, creation of a receipt after release does not make receipt creation a technical prerequisite to release. In the disclosed architecture, commitment of a Protected Output Validation Receipt may be constitutive rather than merely evidentiary. The Output Release Capability is not issued or activated unless the required receipt commitment succeeds. The protected receipt therefore participates directly in creation of Release Authority.

Digital-Rights-Management and Encryption Systems Encryption and digital-rights-management systems may restrict access to encrypted content or control selected uses of a protected file. Such systems generally protect a pre-existing content object and may release a decryption key when specified conditions are met. The present architecture addresses a different technical sequence in which protected components are selectively reconstructed, an artificial-intelligence workload derives a new Candidate Output, the generated Candidate Output is itself rendered Non-Releasable, current authorization and protected association conditions are evaluated, validation evidence is committed, and a capability is issued for that specific verified output or operation. The disclosed Output Release Capability is therefore not merely a general decryption licence for pre-existing content.

Data Clean Rooms and Controlled Query Environments Data clean rooms and controlled analytics environments may permit approved computations over protected datasets while limiting raw-data export. Such environments can reduce direct exposure of source records. However, a clean room does not necessarily provide the complete disclosed chain of independently controlled semantic vaults, independently controlled relationship-mapping authority, non-bearer execution-context-bound reconstruction authority, session-bound component release, protected provenance through artificial- intelligence processing, Sealed Candidate Output, live output-time re- verification, constitutive Protected Output Validation Receipt commitment, output-specific Release Authority, and Output Release Boundary verification. The disclosed architecture may be deployed within or around a data clean room, but is not limited to a controlled analytics room.

Information-Flow-Control Systems and Agent Tool Permissions Mandatory information-flow-control systems may label data and restrict movement between security domains. Such systems may provide an enforcement substrate for selected embodiments. However, generic labels do not necessarily represent the permitted association between two fields, a purpose-bound reconstruction session, current execution-context attestation, output-specific receipt commitment, or an output capability bound to a destination and boundary. Agent platforms may limit which tools an artificial-intelligence agent can invoke. Permission to invoke a tool does not necessarily determine whether the specific arguments generated by the workload are within the authorized data, association, purpose, recipient, jurisdiction, and disclosure scope. The disclosed architecture treats a tool invocation and its arguments as a Candidate Output and may prevent invocation until output-finality conditions have been satisfied.

Proposed Technical Solution

The Three Architectural Pillars The architecture is organized around three foundational technical principles.

Decomposition of Authority (Technical Non-Joinability) No single ordinary server holds complete authority over the entire data-to- consequence transaction. Protected enterprise information may be decomposed among independently controlled domains, including an identity vault, a content vault, a relationship-mapping vault, a cryptographic-material or reconstruction- enablement domain, a Protected Authorization Domain, an Output Verification Stage, a Protected Receipt Store, and an Output Release Boundary. The relationship between protected identity and protected content is treated as an independently controlled technical asset. Authority to access an identity does not automatically provide authority to associate that identity with protected content. Authority to access protected content does not automatically provide authority to determine the person, account, organization, device, or commercial relationship to which that content belongs. This creates Technical Non-Joinability outside an authorized reconstruction session. Protected information may be joined only where a valid, purpose-bound, context- bound, and session-bound reconstruction operation permits the specific fields and associations required for the authorized task. A compromised AI server therefore does not automatically become a universal enterprise-knowledge reconstruction engine.

Mandatory Mediation Every consequence-bearing Candidate Output must pass through an independent protected finality path. The artificial-intelligence workload does not receive unrestricted authority to release whatever it generates. A Candidate Output may include text, a report, an image, an API request, a database update, a retrieval query, a tool invocation, an email, a payment instruction, an external-model prompt, a memory write, or a physical control signal. Before the Candidate Output can become externally usable, the architecture may re-establish the current execution context, the current model and agent state, current policy, current revocation state, the current Session Epoch, the intended destination, the intended recipient, the permitted field set, the Permitted Association Scope, the authorized purpose, the Disclosure Budget, the Inference-Channel Budget, and the identity of the Output Release Boundary. The Candidate Output may also be evaluated for protected fields, unauthorized identity-content associations, inferred associations, cumulative disclosures, prohibited tool arguments, unauthorized memory writes, destination substitution, and other deviations from the original authorization. Where a required condition is stale, missing, ambiguous, inconsistent, unavailable, or unverifiable, the output fails closed. This extends the established security principle of complete mediation from access control to the complete execution-to-consequence path.

Technical Non-Completability The artificial-intelligence workload may complete computation without acquiring the ability to complete the external consequence. The Candidate Output is maintained as a Sealed Candidate Output, a protected intermediate artifact, a capability-restricted object, protected memory state, or another technically Non-Releasable representation. The compromised workload does not possess sufficient key material, capability, protected state, or output-path authority to independently release the result. Even successful output verification does not necessarily create Release Authority. A Protected Output Validation Receipt may first be generated and committed to protected receipt state. Only after successful receipt commitment may an output-specific Output Release Capability be issued. The Output Release Capability may be bound to the exact verified output, the committed receipt, the session, the Session Epoch, the destination, the recipient, the output type, the expiration condition, and the designated Output Release Boundary. The Output Release Boundary alone completes the final transition from a Non-Releasable Candidate Output to an externally effective result. This establishes the central technical assurance: a breach of computation cannot automatically be escalated into a breach of consequence.

Conventional Attack Path versus Protected Architecture In a conventional architecture the attack path may be: The same compromised server may possess database credentials, plaintext access, mapping logic, network authority, tool credentials, file-writing authority, and message-transmission privileges. Once the server is compromised, the attacker may inherit the complete chain from information access to external effectuation. Under the disclosed architecture the same attack encounters independently enforced technical boundaries: The attacker may control the workload while remaining unable to control the complete data association, the independent validation state, the constitutive receipt commitment, the output-specific Release Authority, or the final effectuation boundary. The attack path is therefore interrupted before the prohibited result becomes externally effective.

Comparison with Conventional Approaches The following table summarizes key distinctions. Comparison of Approaches

Aspect	Conventional Approaches	DAS Protocols Enterprise AI
Primary control point	Access / resource request	Complete execution-to-consequence path
Data association	Often joinable via one credential or query engine	Technical Non-Joinability; independent relationship-mapping vault
Authorization artifact	Typically bearer (token, key, cookie)	Non-bearer Reconstruction Authorization Object bound to context, session, epoch
Output control	Post-generation filtering or DLP (often advisory)	Sealed Candidate Output + constitutive receipt + output-specific capability + boundary
Time-of-check	Often only at initial access	Live output-time re-verification of context, policy, association scope
Receipt / evidence	Usually post-event logging	Constitutive Protected Output Validation Receipt required for Release Authority
Compromise effect	Server compromise often yields full data + join + release chain	Computation compromise does not automatically yield join or consequence authority
Fail-safe behaviour	Varies; often permissive on missing service	Fail-closed on absent, stale, ambiguous, or unverifiable protected state

Detailed Technical Description

Semantically Heterogeneous Protected Storage The proposed architecture decomposes an enterprise record into semantically different protected components. In one embodiment:

• identity components are maintained in an identity vault;
• substantive content components are maintained in a content vault;
• association information is maintained in an independently controlled relationship-mapping vault; and
• cryptographic or reconstruction-enablement material is maintained in a cryptographic-material vault or another protected domain.

Opaque references may replace direct persistent associations. The relationship- mapping vault is treated as an independent authority rather than as a passive table automatically accessible with the identity or content data. Accordingly, possession of identity components and content components does not necessarily provide authority to reconstruct the protected relationship between them.

Non-Bearer Reconstruction Authorization A Protected Authorization Domain evaluates a data-use request and generates a Reconstruction Authorization Object (RAO). The RAO may bind the requester, the tenant, an attested execution-context measurement, an identified artificial- intelligence workload, a session identifier, a session nonce, a Session Epoch, a Policy Epoch, a permitted field set, a Permitted Association Scope, an authorized processing purpose, permitted output types, permitted destinations, permitted recipients, jurisdiction conditions, validity conditions, use-count conditions, Disclosure Budget state, Inference-Channel Budget state, a Protected Reconstruction Domain, and an Output Release Boundary. The Reconstruction Authorization Object is non-bearer because possession alone does not enable exercise. Exercise additionally requires correspondence with current protected execution, session, domain, epoch, and policy conditions.

Independent Vault-Local Release The Reconstruction Authorization Object or a protected derivative is presented independently to each required vault. Each vault applies its own Vault-Local Release Conditions. Approved components are converted into Session-Bound Components or made accessible only through a Mandatory Mediation Path. Each vault may generate a Vault-Local Release Receipt binding the released components to the Reconstruction Authorization Object, the session, the Session Epoch, the releasing vault, and the Protected Reconstruction Domain. This prevents a released component from becoming a general reusable bearer object.

Protected Reconstruction A Protected Reconstruction Domain obtains approved Session-Bound Components and reconstructs only the fields and associations permitted for the authorized purpose. The Protected Reconstruction Domain creates an Ephemeral Reconstructed Data View or another Minimum-Necessary Representation. The complete semantically usable enterprise record is prevented from being persistently exported outside the Protected Processing Span unless separately authorized. The artificial-intelligence workload receives the permitted view through a Restricted Processing Interface and does not receive unrestricted vault credentials.

Provenance and Association Continuity Protected Provenance State is maintained for source components, reconstructed fields, permitted associations, intermediate values, Protected Derivatives, generated fragments, tool arguments, retrieval queries, and Candidate Output portions. The provenance mechanism allows the Output Verification Stage to determine whether a Candidate Output derives from an unauthorized field, an unauthorized identity-content association, an unauthorized transformation, or a source outside the authorized reconstruction. Where explicit provenance labels are not used, equivalent protected source-control state may be maintained using structured intermediates, deterministic schemas, protected references, information- flow state, or confined processing paths.

Sealed Candidate Output The artificial-intelligence workload generates a Candidate Output inside protected memory, a Protected Output Buffer, or another mandatory protected output path. Before the Candidate Output becomes available to an untrusted process or external channel, it is encrypted, sealed, capability-restricted, retained in protected memory, placed under protected state-machine control, or otherwise rendered Non- Releasable. The workload does not possess sufficient key material, capability, protected state, interface authority, or release path to independently make the Candidate Output Externally Usable or Externally Effective. Generation therefore completes computation but does not complete the output path.

Live Output-Time Re-Verification and Association Evaluation Before Release Authority is formed, the Output Verification Stage re-establishes current Protected Authorization State. It may verify a fresh execution-context attestation, current revocation state, current Policy Epoch, current Session Epoch, current use count, destination authorization, recipient authorization, jurisdiction conditions, current Permitted Association Scope, current disclosure state, and Output Release Boundary identity. Where continuity can be established within a Bounded Freshness Window, protected continuity evidence may be used; otherwise fresh attestation is required. The Output Verification Stage evaluates the Candidate Output or a protected representation thereof for protected fields, identity-bearing entities, content- bearing entities, explicit associations, inferred associations, prohibited quasi- identifier combinations, cumulative disclosures, tool arguments, database operations, downstream model prompts, or other consequence-bearing content. Candidate associations are compared with the Permitted Association Scope. Uncertainty does not create Release Authority. A noncompliant output may remain sealed, be denied, or be transformed inside a protected domain and re-verified.

Constitutive Protected Validation Commitment and Atomic Output Finality After successful verification, the Output Verification Stage generates a Protected Output Validation Receipt. The receipt may bind the Reconstruction Authorization Object digest, the original Candidate Output digest, the verified output digest, the Provenance State digest, the execution-context measurement, the Session Epoch, the Policy Epoch, the destination, the recipient, the output type, the Permitted Association Scope, the Output Release Boundary, and the verification result. The receipt is committed to a Protected Receipt Store before Release Authority exists. Receipt commitment is constitutive rather than merely evidentiary. Failure to commit the receipt prevents Output Release Capability issuance. Output verification, Protected Output Validation Receipt commitment, protected state advancement, and Output Release Capability issuance may be performed as an Atomic Output Finality Transaction. The transaction either completes in a protected success state or fails without leaving usable partial Release Authority. The Output Release Capability is bound to the verified output and its authorized effectuation context. A capability presented with another output, destination, recipient, session, Session Epoch, or Output Release Boundary is rejected.

Output Release Boundary and Fail-Closed Controls The Output Release Boundary is positioned at the point where the Candidate Output first becomes Externally Usable or Externally Effective. The boundary may control decryption, transmission, display, rendering, file writing, database commitment, message publication, tool invocation, memory persistence, payment initiation, workflow transition, or actuator operation. Only after successful verification of the Output Release Capability and corresponding committed receipt does the boundary complete effectuation. The capability is then consumed, invalidated, or advanced to a non-reusable state. Where a required condition is absent, stale, ambiguous, unavailable, inconsistent, expired, revoked, or unverifiable, the corresponding operation is denied. No default gateway rule, timeout, cached bearer credential, unavailable security service, or legacy fallback path causes permissive release. Where a session terminates before valid completion, the system may poison the session by advancing the Session Epoch, destroying temporary keys, invalidating Session-Bound Components, revoking provisional capabilities, and closing Vault-Local Release State.

End-to-End Protected State and Authority Workflow The principal progression of protected system state is: Completion of an earlier state does not automatically authorize transition to a later state. In particular: access authority does not constitute reconstruction authority; reconstruction authority does not constitute processing authority beyond the authorized purpose; processing authority does not constitute output authority; successful output verification does not constitute Release Authority until the required Protected Output Validation Receipt has been committed; possession of an Output Release Capability does not authorize release outside its bound output, destination, session, epoch, and Output Release Boundary; and computation of a Candidate Output does not make the Candidate Output Externally Usable or Externally Effective.

JSON Schema for Core Protected Objects This section provides illustrative JSON Schema (draft 2020-12) definitions for key protected objects. Implementations may extend, restrict, or map these schemas to binary, CBOR, or other encodings while preserving the required binding and non-bearer properties.

Reconstruction Authorization Object (RAO)

Protected Output Validation Receipt

Output Release Capability

Latency and the Cost of the Protected Path The most common objection to this architecture is latency: if every association and every release requires evaluation, the assistant becomes slower than an unprotected one. The objection is accepted as accurate and rejected as decisive, for three reasons. First, the comparison is against the wrong baseline. In the deployments this document addresses, a consequential act already carries synchronous authorization. A wire transfer is authorized before it settles. Material crossing a classified boundary is released before it leaves. A trade passes pre-trade risk checks before it reaches the venue. None of those industries treats the check as intolerable overhead, because the alternative is an unrecoverable act. This document asks for the same posture at the two points where an AI seat now creates and emits strategy, and asks for it only there. Second, the cost is not incurred uniformly. Work that can be computed in advance of a request — policy compilation, association-scope derivation, attestation appraisal, key and epoch state — is not on the path of the request that needs it. What remains on the path is the set of checks whose omission would permit an unauthorized reconstruction or release: current authority, current revocation and epoch state, freshness, destination, and receipt commitment. Independent vault evaluations under a single valid Reconstruction Authorization Object are not required to be serial, so the protected stage need not scale with the number of vaults consulted. Third, the residual cost is bounded and measurable rather than speculative. The hot-path and cold-path separation, the permissible parallel vault fan-out, the legacy-integration and incremental-migration guidance, and quantitative observations from a published runnable reference implementation are set out in the companion profile and are not restated here. Readers whose principal concern is deployment cost should read that treatment together with this document; those figures are properties of reference code under stated conditions, not protocol latency guarantees. A deployment that cannot accept a bounded evaluation stage on the join and release paths is outside the scope of this document. That is a statement of applicability, not a defect: an architecture whose purpose is to make an unauthorized consequence impossible cannot also promise that nothing is checked before a consequence occurs.

Resources and Reference Implementations The architecture in this document is accompanied by a set of public, runnable reference implementations covering the same protected chain in different deployment contexts. They are architectural references for the state machine and its failure states, not production isolation systems, and observed timings in them are properties of the reference code rather than protocol guarantees.

• This architecture directly: , implementing multi-vault Technical Non-Joinability, the Reconstruction Authorization Object, Sealed Candidate Outputs, receipt commitment, and Output Release Boundary consumption as a single protected chain.
• Privacy and purpose enforcement: , release , and the purpose-laundering validator .
• Governance and regulatory enforcement: .
• Hardware- and accelerator-rooted enforcement: , , and .
• Agentic, tool-call, and zero-trust automation paths: , , and .
• Telecom and cross-domain sinks: and .
• Sovereignty: , with the policy framing in .

Security Considerations The architecture assumes that at least some independently protected domains (vaults, Protected Authorization Domain, Output Verification Stage, Protected Receipt Store, Output Release Boundary) remain uncompromised under the applicable threat model. Simultaneous compromise of every protected domain and every alternate output path falls outside the claimed assurance. Implementations MUST enforce fail-closed behaviour for absent, stale, ambiguous, inconsistent, expired, revoked, or unverifiable protected state. Implementations MUST NOT treat possession of an RAO, receipt, or capability as sufficient authority without verifying the bound execution context, session, epoch, and other required conditions. Session poisoning, epoch advancement, and destruction of temporary keys upon abnormal termination are RECOMMENDED to mitigate replay and rollback attacks. Streaming outputs SHOULD be controlled per-segment or under a cumulative disclosure budget before any externally usable release. The non-bearer property of the RAO and Output Release Capability is critical. Implementations that reduce these objects to simple bearer tokens lose a core security property of the architecture.

IANA Considerations This document has no IANA actions.

Conclusion The DAS Protocols enterprise-AI architecture divides three powers commonly concentrated in one application server: the power to access protected components, the power to join those components into meaningful enterprise intelligence, and the power to externalize the resulting intelligence or operation. Compromise of one power does not automatically become compromise of all three. The attacker may compromise the AI workload, but does not thereby obtain unrestricted authority to reconstruct the enterprise’s protected knowledge or externalize the enterprise’s future. The architecture is not based on the assumption that artificial-intelligence workloads will always remain trustworthy. It is based on the opposite assumption: the workload may fail, be manipulated, or be compromised—and the architecture must still prevent unauthorized computation from automatically becoming an authorized consequence. That is the purpose of Execution–Consequence Decoupling, Technical Non-Joinability, Mandatory Mediation, and Technical Non-Completability.

Normative References Informative References Companion protocol profile to this document. Public disclosure, version 2, 24 August 2026. Runnable reference implementation of the architecture described in this document. Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das Sangam Das

Acknowledgements This document is part of the broader DAS Protocols body of work. The author thanks reviewers and collaborators who provided feedback on earlier drafts of the architecture.