Many assume that a planner‑executor pair automatically respects data residency simply because the planner runs in a compliant zone. The reality is that the executor often reaches out to resources without any guarantee that the data stays within the intended geography.
Data residency is not a property of the code alone; it is a property of the entire request path. When a planner asks an executor to run a job, the executor’s network traffic, logs, and temporary artifacts can cross region boundaries unless the connection is explicitly constrained.
How teams typically wire planner‑executor agents today
In practice, many organizations deploy a planner service that generates tasks for a fleet of executor agents. The agents authenticate with static service‑account keys that are shared across environments. Connections to databases, caches, or internal APIs are made directly from the executor, often using the same credential set that the planner uses. There is little visibility into which region the executor contacts, and audit logs are scattered across individual services or written to local files on the agent host.
This model creates three hidden problems. First, the executor can inadvertently query a replica in a different country, breaking regulatory mandates. Second, logs that contain query results or error details may be written to disks that are not subject to the same residency controls as the primary data store. Third, because the planner and executor share credentials, revoking a single compromised key revokes access everywhere, increasing blast radius.
The missing piece: a controlled data path
The precondition for solving data residency is to treat the executor’s access as a non‑human identity that is granted the minimum permissions needed for each task. Federation with an identity provider and just‑in‑time role assignment reduce the attack surface. However, even with tight identity controls, the request still travels straight to the target service. No component in that path inspects the traffic, enforces geographic constraints, or records the exact query for later review.
Without a gateway in the middle, you cannot guarantee that every request respects the residency rule, nor can you produce a reliable audit trail that shows where data was read or written.
hoop.dev as the enforcement layer
hoop.dev solves the problem by becoming the mandatory data path for every planner‑executor interaction. The executor connects through hoop.dev instead of reaching the target directly. hoop.dev verifies the caller’s OIDC token, applies policy that defines allowed regions, and then proxies the request to the actual service.