Executive Summary
A SaaS compliance vendor normally has to ask a customer to send its regulated records into the vendor's own processing tier - which is exactly the moment a custody obligation and a breach surface are created, regardless of how well the vendor's cloud is secured. JIL Sovereign's client-perimeter edge/cloud split removes the request entirely: a connector runs inside the customer's own network boundary, is the only component in the entire pipeline that ever touches cleartext, and the key that would let anyone re-identify the resulting tokenized data is generated and held on the customer's side, never transmitted anywhere.
The edge connector reads source records incrementally, using a watermark plus column projection to avoid pulling more than is needed. It evaluates applicable compliance checks locally, de-identifies the record to a Safe Harbor standard, tokenizes any remaining identifiers via HMAC using a per-tenant key generated and held entirely client-side, seals the result, and emits only de-identified, tokenized output outbound. The control plane on the vendor's side never holds cleartext regulated data at rest - structurally, not merely by policy, because the vendor's infrastructure never possesses the tokenization key needed to reverse the transformation.
Problem Statement
Standard SaaS compliance connectors pull customer records into the vendor's own cloud for processing, which means the vendor's infrastructure - and any breach of it - becomes part of the customer's custody chain for regulated data, and typically requires a business associate agreement covering the vendor's own compute. Confidential-computing enclaves address integrity of the processing environment, but as discussed under Claim 34, they still centralize compute inside the vendor's infrastructure; the input still crosses the customer's perimeter to get there. Generic tokenization-as-a-service offerings solve part of the re-identification-risk problem, but the vendor typically holds the tokenization key itself, which means the vendor - or anyone who compromises the vendor - can still reverse the tokenization.
What none of these approaches do is keep the re-identification key itself outside the vendor's reach entirely, generated and held on the customer's own infrastructure and never transmitted in either direction, while still producing a court-verifiable sealed output the vendor's downstream systems can consume without ever seeing the underlying records.
Why Existing Approaches Fall Short
- Standard SaaS compliance connectors: pull customer records into the vendor's cloud, extending the customer's custody chain to the vendor's own infrastructure.
- Confidential-computing enclaves (see Claim 34): attest to processing integrity but still centralize compute inside the vendor's environment; input still crosses the customer perimeter.
- Generic tokenization-as-a-service: the vendor typically holds the tokenization key, so the vendor (or an attacker who compromises it) can reverse the tokenization.
- Old Claim 94 (Proof-Without-Custody Client-Resident Audit Edge): the direct predecessor concept - this claim generalizes it into the edge/cloud split with the non-exportable key as the load-bearing architectural element.
Technical Architecture
Edge Connector Responsibilities
| Step | Operation |
|---|---|
| 1. Incremental read | Reads source records using a watermark plus column projection, pulling only newly-relevant data rather than full-table scans. |
| 2. Local evaluation | Evaluates applicable compliance checks against the records while they remain on the customer's own infrastructure. |
| 3. De-identification | De-identifies the record to a Safe Harbor standard before anything is prepared for transmission. |
| 4. Tokenization | Tokenizes remaining identifiers via HMAC using a per-tenant key generated and held entirely client-side; the key is never transmitted in either direction. |
| 5. Sealing | Seals the de-identified, tokenized result under the platform's evidentiary sealing mechanism. |
| 6. Outbound-only emission | Emits only the sealed, de-identified result to the control plane - never the source record. |
Structural, Not Policy-Based, Guarantee
The non-exportable key is the load-bearing element: because the key needed to reverse the tokenization is generated on and never leaves the customer's own network, the vendor's control plane is structurally incapable of re-identifying the customer's data, regardless of the vendor's internal access controls or the state of the vendor's own security posture. Verification of any downstream output requires only the seal and the client-held record - the control plane's own copy is sufficient to confirm authenticity without ever needing the original cleartext.
Relationship to the No-Retention Enclave
Where a specific check needs richer processing than the edge connector can perform locally - for example, judging an unstructured narrative - the connector can invoke the no-retention ephemeral enclave described in Claim 34 for that specific item, preserving the same overall guarantee: cleartext exists only transiently, inside a boundary the vendor's persistent infrastructure never crosses.
Prior Art Differentiation
| Approach | Cleartext ever leaves customer perimeter | Vendor holds re-identification key | Outbound-only data flow | Court-verifiable sealed output |
|---|---|---|---|---|
| Standard SaaS connectors | Yes | N/A (no tokenization) | No | No |
| Confidential-computing enclaves | Yes (crosses perimeter to reach enclave) | N/A | No | Varies |
| Generic tokenization-as-a-service | Depends | Yes, typically | No | No |
| JIL Sovereign | No, never | No, structurally cannot | Yes | Yes |
The defensible combination is the customer-resident edge connector paired specifically with a non-exportable, client-generated per-tenant tokenization key - prior art either brings the data to the vendor's compute or leaves the re-identification key in the vendor's hands even when it doesn't.