How must an instance persist data residency constraints across cross-border session handoffs?

**Date of Record:** 2026 October 26 **Scope:** Applies when an agentic session processes data subject to data residency regulations (e.g., GDPR, PIPL, CCPA) and hands off state to a successor instance running in a different geographic jurisdiction. Does not apply to sessions operating entirely within a single jurisdiction or data that is fully anonymized and exempt from residency requirements.

Core Distinction

The separation between **data location** (the physical or logical storage location of the payload) and **data residency constraints** (the legal and regulatory boundaries that dictate where the data may be processed, not just stored). Failing to distinguish these creates the **Jurisdictional Pivot**: the data is stored in the EU, but the successor instance runs in the US and processes the data in memory, violating residency rules because the constraint applies to compute as well as storage. The residual must bind the data to its processing jurisdiction, not just its storage bucket.

What Was Observed

In globally distributed agent architectures, failing to persist residency constraints produces three primary failure modes:

  1. **Cross-Border Compute Violation:** The predecessor stores EU user data in an EU bucket but hands off processing instructions to a US-based successor. The successor reads the data into memory, processes it, and violates the EU's restrictions on cross-border compute.
  2. **Sub-Processor Blindness:** A successor spawns a sub-agent hosted in a third country to run inference. The successor did not know the data was EU-resident, so it routes it to the sub-agent without a Data Processing Agreement (DPA).
  3. **Residency Drift:** The data is copied for a backup, and the backup service silently stores it in a jurisdiction not allowed by the original constraint. The successor inherits the backup pointer without knowing it is non-compliant.

Recorded Elements

  1. **`processing_jurisdiction_boundary`:** The exact geographic or regulatory region (e.g., `EU`, `US-CA`, `CH`) where the data may be processed.
  2. **`data_residency_receipt`:** The cryptographic attestation of the data's origin and classification (e.g., "EU-origin personal data"), signed by the data controller.
  3. **`permitted_sub_processor_list`:** The explicit allowlist of jurisdictions where sub-agents or downstream services may process the data.
  4. **`handoff_geofence_directive`:** The fail-closed instruction that prevents the successor from spawning in an unauthorized jurisdiction (e.g., `REJECT_HANDOFF_IF_JURISDICTION_NOT_ALLOWED`).

Condition of Validity

* **Applies when:** The data is subject to residency laws, and the successor's compute environment, sub-agents, or backup services may be located in a different jurisdiction than the predecessor. * **Does not apply when:** The data is fully anonymized to the point of being exempt from residency laws, or the system operates in a single country with no cross-border routing.

Decision Boundary

  1. **Is the data subject to residency constraints?** If no, standard state handoff applies. If yes, proceed.
  2. **Is the `processing_jurisdiction_boundary` and `data_residency_receipt` recorded?** If no, the successor cannot verify compliance. The instance must halt and re-classify the data.
  3. **Is the successor's jurisdiction in the `permitted_sub_processor_list`?** If no, the handoff must be blocked, and the successor must be re-routed to an authorized region.
  4. **Conversely, when can an instance ignore residency constraints?** Only when the data is explicitly and verifiably anonymized before the handoff, such that it no longer falls under the jurisdiction's definition of personal data.

Operational Effect

  1. **Cross-Border Compute Compliance:** Prevents agents from inadvertently processing data in a jurisdiction where it is not allowed, satisfying the "processing location" requirements of modern data protection laws.
  2. **Sub-Processor Audit:** Ensures every sub-agent invoked respects the same residency constraints as the primary agent, closing a common compliance loophole.
  3. **Deterministic Routing:** Replaces implicit trust in infrastructure routing with explicit geofence directives, preventing residency drift in backups and caches.
from dataclasses import dataclass
from enum import Enum, auto
import hashlib
import json

class ResidencyVerdict(Enum):
    JURISDICTION_COMPLIANT = auto()
    JURISDICTION_VIOLATION = auto()
    UNKNOWN_JURISDICTION = auto()

@dataclass(frozen=True)
class DataResidencyState:
    data_origin_jurisdiction: str
    processing_jurisdiction: str
    permitted_processing_jurisdictions: frozenset[str]
    has_residency_receipt: bool

@dataclass(frozen=True)
class HandoffManifest:
    verdict: ResidencyVerdict
    directive: str
    manifest_digest: str

class DataResidencyGuard:
    @staticmethod
    def _hash(data: str) -> str:
        return hashlib.sha256(data.encode("utf-8")).hexdigest()

    @classmethod
    def evaluate_handoff(cls, state: DataResidencyState) -> HandoffManifest:
        
        # Gate 1: Receipt presence
        if not state.has_residency_receipt:
            return HandoffManifest(
                verdict=ResidencyVerdict.UNKNOWN_JURISDICTION,
                directive="HALT: No data residency receipt. Cannot verify jurisdiction.",
                manifest_digest=cls._hash("NO_RECEIPT")
            )

        # Gate 2: Processing jurisdiction allowed
        if state.processing_jurisdiction not in state.permitted_processing_jurisdictions:
            return HandoffManifest(
                verdict=ResidencyVerdict.JURISDICTION_VIOLATION,
                directive=f"BLOCKED: Processing in {state.processing_jurisdiction} is not permitted for data originating in {state.data_origin_jurisdiction}.",
                manifest_digest=cls._hash(f"VIOLATION:{state.processing_jurisdiction}")
            )

        # Gate 3: Compliant
        digest = cls._hash(json.dumps({
            "origin": state.data_origin_jurisdiction,
            "processing": state.processing_jurisdiction,
            "allowed": tuple(sorted(state.permitted_processing_jurisdictions))
        }, sort_keys=True))
        
        return HandoffManifest(
            verdict=ResidencyVerdict.JURISDICTION_COMPLIANT,
            directive="PROCEED: Processing jurisdiction is compliant with data residency constraints.",
            manifest_digest=digest
        )