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 A compromised enterprise AI server is no longer just a data-breach risk. It can become a continuously updated reconstruction engine of the enterprise’s future — correlating customer records, engineering defects, financial systems, and internal communications into competitive intelligence and then externalizing that intelligence. Conventional security concentrates the powers of data access, semantic joining, and external effectuation inside the same workload. When that workload is compromised through prompt injection, model substitution, credential theft, or full server takeover, existing access-control, sandbox, TEE, DLP, and clean-room approaches do not structurally stop the escalation from computation to real-world consequence. This document presents the DAS Protocols enterprise-AI architecture, a focused embodiment of the broader execution-finality framework disclosed in PCT/IB2026/055615 (“THE DAS PROTOCOLS”). It introduces Execution–Consequence Decoupling enforced by three pillars: Decomposition of Authority (Technical Non-Joinability) across independently controlled identity, content, relationship-mapping, and cryptographic vaults; Mandatory Mediation of every consequence-bearing Candidate Output; and Technical Non-Completability so that computation can finish without the ability to complete 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. Live output-time re-verification and constitutive Protected Output Validation Receipt commitment are required before an output-specific Release Capability can be issued and exercised only at a designated Output Release Boundary. Compromise of the AI computation plane therefore cannot automatically escalate into unrestricted enterprise-knowledge reconstruction or unauthorized external consequence. The document elaborates the full problem space, compares the architecture against representative conventional technologies, provides a detailed technical description, and supplies JSON Schema definitions for the core protected objects (Reconstruction Authorization Object, Protected Output Validation Receipt, and Output Release Capability). Intellectual-property disclosures of related Indian provisional applications and PCT filings appear in the final appendix.

Introduction

Scope and Relationship to the Mothership Architecture The present document describes a focused enterprise-data and artificial-intelligence embodiment of the broader execution-finality architecture disclosed in International Application No. PCT/IB2026/055615, titled “THE DAS PROTOCOLS,” filed on 4 June 2026 (the “Mothership Application”). The Mothership Application provides the wider architectural framework for separating 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 present invention 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.

The present work is also technically aligned with the Applicant’s broader body of work developed across 32 Indian provisional patent applications addressing protected data use, artificial-intelligence execution governance, authority separation, mandatory mediation, hardware- or cryptographically rooted enforcement, and prevention of unauthorized digital, financial, communicative, or physical consequence. Identification of related applications is provided for architectural context and does not, by itself, alter priority entitlement or legal status of any individual application. Related International Applications include, among others, PCT/IB2026/053385, PCT/IB2026/054453, PCT/IB2026/055615 (Mothership), PCT/IB2026/055760, PCT/IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056353, PCT/IB2026/056771, PCT/IB2026/056809, PCT/IB2026/056941, and PCT/IB2026/057198.

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 disclosed architecture introduces a 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 Description of the Invention

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

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 invention 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 Applicant

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.

Appendix A. Intellectual Property Disclosure — Related Applications The present document is technically related to subject matter disclosed in one or more of the following applications. This statement is provided for architectural and transparency context. Any claim of priority to one or more of the foregoing applications is made only to the extent that the respective application is validly and expressly identified in the Request, priority declaration, or other official filing record of a corresponding patent application. Identification of an application in this appendix is not intended, by itself, to create, add, correct, or modify a priority claim.

A.1. Related Indian Provisional Applications The present work is technically aligned with the Applicant’s broader body of work developed across the following Indian provisional patent applications (identified by the Applicant):

1. Indian Patent Application No. 202531123959, filed 9 December 2025;
2. Indian Patent Application No. 202531123977, filed 9 December 2025;
3. Indian Patent Application No. 202531125643, filed 12 December 2025;
4. Indian Patent Application No. 202531129538, filed 20 December 2025;
5. Indian Patent Application No. 202531130168, filed 22 December 2025;
6. Indian Patent Application No. 202531130665, filed 23 December 2025;
7. Indian Patent Application No. 202631000572, filed 3 January 2026;
8. Indian Patent Application No. 202631001586, filed 7 January 2026;
9. Indian Patent Application No. 202631002990, filed 12 January 2026;
10. Indian Patent Application No. 202631004331, filed 16 January 2026;
11. Indian Patent Application No. 202631005583, filed 20 January 2026;
12. Indian Patent Application No. 202631005645, filed 20 January 2026;
13. Indian Patent Application No. 202631006616, filed 22 January 2026;
14. Indian Patent Application No. 202631007467, filed 26 January 2026;
15. Indian Patent Application No. 202631009579, filed 30 January 2026;
16. Indian Patent Application No. 202631011216, filed 3 February 2026;
17. Indian Patent Application No. 202631011630, filed 3 February 2026;
18. Indian Patent Application No. 202631016797, filed 16 February 2026;
19. Indian Patent Application No. 202631018571, filed 18 February 2026;
20. Indian Patent Application No. 202631024957, filed 3 March 2026;
21. Indian Patent Application No. 202631030760, filed 14 March 2026;
22. Indian Patent Application No. 202631034260, filed 21 March 2026;
23. Indian Patent Application No. 202631035846, filed 24 March 2026;
24. Indian Patent Application No. 202631038227, filed 27 March 2026;
25. Indian Patent Application No. 202631041923, filed 1 April 2026;
26. Indian Patent Application No. 202631043195, filed 4 April 2026;
27. Indian Patent Application No. 202631043507, filed 6 April 2026;
28. Indian Patent Application No. 202631046689, filed 11 April 2026;
29. Indian Patent Application No. 202631046739, filed 12 April 2026;
30. Indian Patent Application No. 202631047382, filed 14 April 2026;
31. Indian Patent Application No. 202631049021, filed 17 April 2026; and
32. Indian Patent Application No. 202631051652, filed 23 April 2026.

A.2. Related International (PCT) Applications The present document is also technically related to subject matter disclosed in one or more of the following international applications:

1. PCT/IB2026/053385, filed 7 April 2026;
2. PCT/IB2026/054453, filed 5 May 2026;
3. PCT/IB2026/055615, filed 4 June 2026 (the “Mothership Application” / “DAS Protocols Mothership”);
4. PCT/IB2026/055760, filed 7 June 2026;
5. PCT/IB2026/055870, filed 10 June 2026;
6. PCT/IB2026/056058, filed 13 June 2026;
7. PCT/IB2026/056353, filed 22 June 2026;
8. PCT/IB2026/056771, filed 1 July 2026;
9. PCT/IB2026/056809, filed 1 July 2026;
10. PCT/IB2026/056941, filed 6 July 2026; and
11. PCT/IB2026/057198, filed 12 July 2026.

The foregoing applications may disclose related, complementary, overlapping, upstream, downstream, domain-specific, or implementation-specific aspects of protected execution governance, non-bearer authority, protected validation evidence, technical non-completability, mandatory mediation, artificial- intelligence governance, telecommunications governance, data governance, and execution-finality enforcement.

A.3. Relationship to the Mothership Application (PCT/IB2026/055615) International Application No. PCT/IB2026/055615, filed 4 June 2026, is referred to in the present disclosure as the “Mothership Application,” “DAS Protocols Mothership,” or “Mothership.” The Mothership Application discloses a broader execution-finality architecture in which computation is separated from authority to produce an externally effective consequence through one or more protected authorization states, mandatory enforcement operations, protected validation evidence, scoped finality authority, protected-state transitions, and verification at a Finality Sink. The present disclosure is technically connected to and develops focused implementations within that broader architecture, particularly for enterprise- data vaults, non-bearer reconstruction authorization, Technical Non-Joinability, Sealed Candidate Outputs, live output-time verification, Protected Output Validation Receipts, output-specific Release Authority, and Output Release Boundary control for artificial-intelligence processing. The relationship to the Mothership Application does not require every embodiment of the present disclosure to contain every component, term, sequence, or implementation described in the Mothership Application.