Abstract

6 April 2026 filing

Most AI controls sit beside the data, not with it. Access lists, sensitivity labels, policies and audit logs describe what a model may do. But nothing travels with the data to stop an AI result from being released to the wrong recipient, by the wrong model or for the wrong purpose. Logs are usually written after the action, and refusals are often not recorded at all.

Based on Indian Provisional Filing: 202631043507, filed 6 April 2026, and disclosed with the Mothership (PCT/IB2026/055615) on 16 July 2026.

This disclosure describes an execution-governance architecture in which the data carries its own rules and hardware enforces them at the moment an AI result would take effect. It works in five steps:

  1. Rules are sealed to the data.When data is collected or ingested, a protected environment computes a cryptographic commitment to it. This can be a trusted execution environment, a hardware security module or an equivalent secure module. The commitment is sealed to a governance envelope of approved conditions, such as:
    • purpose, consent state and freshness;
    • approved model or logic class and transformation class;
    • recipient class and output class;
    • retention, join restrictions and non-training rules;
    • tenant boundary and policy version.
  2. The result is held back. The AI computes normally, but its result stays withheld and cannot propagate.
  3. Live conditions are matched at release. At the release point, the protected environment measures runtime conditions and compares them with the envelope bound to the data. These conditions include a behavioural fingerprint of the model actually running (computed from normalised weights, architecture and quantisation state), the requested output class, the destination, real-time authority and revocation status, and quorum. A cryptographic finality handshake happens only on a full match.
  4. A receipt is committed first. Before anything is released, a signed, ledger-anchored validation receipt is generated and committed. This happens whether the outcome is allow, deny, downgrade, fallback or escalate.
  5. Only then is the capability released. The key or signature that lets the result cross into the outside world is released only after that receipt exists. Possible effects include output release, message transmission, transaction commitment, network forwarding, settlement or physical actuation.

The disclosure gives concrete, buildable mechanisms:

  • a BLAKE2b- and HMAC-based model fingerprint algorithm;
  • ECDSA P-256 capability tokens with time-to-live and context binding;
  • a real-time authority and revocation protocol with domain-specific timeouts;
  • a SHA-256 hash-chained sealed state with monotonic entries against rollback;
  • a multi-authority quorum protocol (threshold, ordered or unanimous), in which a single compromised authority cannot complete an operation;
  • an 11-stage financial-transaction walkthrough;
  • a formal threat model.

Latency. The filing estimates governance overhead of about 150–250 ms for financial workflows, within a 5–10 s timeout. An optimised vehicle or safety path runs at about 15–20 ms within a budget of about 50 ms. The optimised path uses a warm enclave, bounded-freshness caching (where stale state means deny, never allow), and fingerprint recomputation only when a model changes.

Legacy systems. The AI application stays unchanged. Enforcement moves to key and signing points that most organisations already operate: payment HSMs, cloud key management, enclave key release and device secure enclaves.

Industry relevance. This section was generated with AI assistance. These are potential fits and collaboration opportunities only, not confirmed adoption or implementation. The architecture could complement existing products such as:

  • Microsoft Purview sensitivity labels, Azure confidential computing and Managed HSM;
  • Google Cloud Confidential Space attestation-based key release;
  • AWS KMS key policies with Nitro Enclaves attestation, and Bedrock AgentCore;
  • Apple Private Cloud Compute and the Secure Enclave;
  • NVIDIA confidential GPUs and BlueField DPUs;
  • Meta’s open-weight Llama models, with TEE-based Private Processing;
  • OpenAI enterprise connectors and agentic commerce;
  • Anthropic’s MCP connectors and credential-attaching sandbox proxies;
  • data platforms such as Snowflake and Databricks Unity Catalog;
  • SAP, Salesforce and ServiceNow enterprise agents;
  • Visa, Mastercard and Stripe agent payments.

It is also relevant to Chinese and European ecosystems, including:

  • China: Alibaba’s Qwen and Alipay agent payments, Tencent WeChat agents, Huawei Ascend and AgenticCore, and Xiaomi and BYD vehicles.
  • Europe: SAP Joule, Siemens Industrial Copilot, Mistral AI, Deutsche Telekom, Orange, Ericsson, Nokia and European banks.

In each case, the existing labels, attestation hardware and audit logs would be joined at the moment an AI result is released.

Filing details. Indian provisional patent application no. 202631043507, filed 6 April 2026. It is available on WIPO PATENTSCOPE among the priority documents of the Mothership application PCT/IB2026/055615 (WO 2026/150382), filed 4 June 2026 and publicly disclosed 16 July 2026. Inventor: Sangam Das ([email protected]). The inventor is open to acquihire or strategic collaboration.

Disclaimer. The invention is the work of its human inventor. This title, abstract and the accompanying summary, including all company and product references, were prepared with AI assistance. Readers must cross-check every statement against the original filed documents on WIPO PATENTSCOPE and against official company sources, and draw their own conclusions from those primary documents. Naming a company or product shows topical relevance only. It is not an endorsement, a validation, a criticism or a statement of infringement, and no company named is affiliated with the inventor. The application is pending, and nothing here is legal advice. Licence: CC BY-NC 4.0.

Keywords: AI safety; data-bound governance; data-centric security; sticky policy; usage control; purpose limitation; consent enforcement; governance envelope; cryptographic commitment; confidential computing; trusted execution environment; HSM; attestation-based key release; model attestation; model fingerprinting; algorithmic logic fingerprint; behavioural fingerprint; BLAKE2b; HMAC; capability token; ECDSA P-256; time-to-live; real-time revocation; hash chain; sealed state; rollback resistance; validation receipt; receipt before release; signed audit record; multi-party approval; quorum; allow deny escalate; fail-closed; output release control; transaction signing; agent payments; autonomous vehicles; latency budget; legacy integration; EU AI Act; GDPR; DPDP Act; Purview; Confidential Space; Nitro Enclaves; AWS KMS; Private Cloud Compute; confidential GPU; BlueField; Llama; MCP; Snowflake; Unity Catalog; Qwen; Alipay; Ascend; SAP Joule

Relation to the earlier filing. This filing builds on Indian provisional application 202631043195 (4 April 2026), which introduced runtime allow, deny and escalate decisions checked against the purpose and approved logic of each request, with seven named causes of uncertainty. The present filing moves the rules into the data itself, sealing them at ingestion and checking them against the AI result at release. It adds a signed receipt that must be committed before any release, for refusals as well as approvals. It also gives concrete algorithms (model fingerprinting, ECDSA capability tokens, a revocation protocol, a hash-chained sealed state and a quorum protocol) and a latency analysis.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS