In-Tenant Containerized Verdict Generation with Customer-VPC Isolation Invariant

Executive Summary

Payment-integrity, compliance-attestation, and fraud-detection vendors typically ask customers to pipe claim data to the vendor's own SaaS endpoint - a mismatch with jurisdiction-bound data (HIPAA, GDPR, state-Medicaid contracts, FedRAMP boundaries) that cannot lawfully leave the customer's own authorization perimeter. JIL Sovereign's in-tenant deployment instead packages the verdict engine as a containerized workload, deployed via a managed-container service directly inside the customer's own data-cloud tenant, bound at install time to a signed deployment manifest, a customer-account locator, and a VPC network policy that denies outbound egress beyond the customer's own data plane.

The distinguishing property is not merely that data stays local - several "deploy-in-your-tenant" patterns already claim that. It is that every verdict carries cryptographic proof of the isolation itself: the deployment manifest hash, the account locator, and the VPC identifier are embedded in the verdict body, and any attempted network egress during computation is sealed into the verdict as a structural invalidity, not merely logged.

Problem Statement

Existing in-tenant deployment patterns each fall short of proving isolation cryptographically. SaaS-with-VPC-peering still routes customer data across the peering boundary into the vendor's own compute. On-prem appliances keep data local, but updates are vendor-pushed and the appliance's internal behavior is not independently verifiable by the customer. Customer-hosted Docker images keep data local too, but there is no cryptographic attestation that the running container is the vendor's exact signed image rather than a tampered one, and no per-output proof that computation stayed inside the tenant.

Why Existing In-Tenant Patterns Fall Short

• SaaS-with-VPC-peering: the vendor's endpoint is reachable via peering, but customer data still crosses into vendor-controlled compute.
• On-prem virtual or physical appliance: data stays local, but updates are vendor-pushed and internal appliance behavior is not independently verifiable.
• Customer-hosted Docker image: data stays local, but there is no cryptographic proof the running image matches the vendor's signed version, and no per-verdict attestation that no egress occurred.
• In-tenant analytics tools generally: run inside the customer's own data cloud, but produce no verdict-specific attestation at all.

Technical Architecture

The Signed Deployment Manifest

Before deployment, a manifest is produced containing the verdict-engine binary image digest, the verdict-check catalog version and content hash, the reference-data manifest hash, an explicit (in one embodiment, empty) list of declared external network endpoints, and the vendor's own signature over the whole manifest. The manifest is published to a manifest registry and written into the customer's own governance catalog at install time.

Install-Time Binding

The Egress-Failure-as-Attestation-Failure Rule

If the verdict catalog is authored correctly, no outbound calls are ever attempted - all reference data resolves from in-tenant tables. If a buggy or compromised version does attempt one, the customer-VPC policy denies the call, records a structured egress-failure event (attempted destination, source catalog version, timestamp), and marks the in-flight verdict body with an attestation_invalid: egress_attempted flag. The engine continues computation to produce a complete body, but that body is structurally invalid: a verifier must reject any verdict carrying the flag.

One-Way External Commitment

After a verdict body is produced, the engine commits only a one-way hash of it to an external immutable ledger via a unidirectional egress the customer-VPC policy explicitly permits. The commitment payload contains the verdict body hash, the customer-account locator, and a timestamp - no claim data, no verdict details, no reference data.

Independent Verification Protocol

A third party verifying a verdict body - for example a federal auditor - retrieves the deployment manifest from the vendor's registry using the manifest hash, verifies the manifest signature, verifies the verdict body's own signature against the verdict-engine signing key declared in the manifest, confirms the manifest hash in the verdict body matches the retrieved manifest, confirms the verdict body's commitment exists on the external ledger, and rejects the verdict outright if it carries the egress-attempted flag. The verifier never accesses the customer's tenant and never sees the underlying claim data, yet confirms the verdict was produced by the canonical engine, inside the customer's tenant, with no data egress, anchored in time.

Prior Art Differentiation

Patent Claim