What GDPR Means for Planner-Executor Agents

Planner-executor agents that run unsupervised can leak personal data before anyone notices, putting gdpr compliance at risk.

Current practice: open credentials and invisible runs

In many organisations the planner component receives a task, builds a command, and hands it to an executor that runs directly against production services. The executor often authenticates with a static service account that has broad read‑write rights. Engineers share that credential in documentation or embed it in CI pipelines. Because the connection goes straight from the executor to the database or API, there is no central log of what query was issued, no record of who triggered the run, and no way to scrub personal identifiers from responses. If a gdpr breach occurs, the evidence trail is either missing or incomplete, making it hard to demonstrate accountability.

What a minimal improvement looks like, and what it still misses

Introducing an identity provider and assigning each planner a short‑lived token is a step forward. The token limits the executor to a specific role and forces the planner to request access. However, the request still travels directly to the target service. The gateway that could inspect the traffic is absent, so the system still lacks:

• Real‑time masking of personal identifiers in query results.
• Just-in-time approval for risky operations such as bulk data exports.
• Immutable session recordings that auditors can replay.
• Fine‑grained audit logs that tie each data access back to the original planner identity.

These gaps mean that, even with better tokens, the organisation cannot produce the detailed evidence required by gdpr Articles 30 and 33.

Why the data path must host enforcement

gdpr compliance hinges on two principles: accountability and data minimisation. Accountability demands that every processing activity be traceable to a responsible entity. Data minimisation requires that only the necessary personal data be exposed, and that excess be hidden or redacted.

Both principles can only be guaranteed when the enforcement point sits on the actual data path. The setup stage, identity federation, token issuance, role assignment, decides who may start a request, but it cannot enforce what happens to the data once the request reaches the target. The gateway is the only place where the system can inspect, mask, approve, and record the transaction.

hoop.dev as the gdpr‑ready data‑path gateway

hoop.dev is a Layer 7 gateway that proxies connections from planners and executors to databases, HTTP services, and other infrastructure. By placing hoop.dev between the executor and the target, organisations gain a single control surface that satisfies gdpr evidence requirements.

• Session recording. hoop.dev records every request and response in an immutable log. Auditors can replay the exact sequence of commands that accessed personal data, linking each action to the planner’s identity.
• Inline data masking. When a response contains fields marked as personal identifiers, hoop.dev redacts or hashes those values before they leave the gateway, ensuring that downstream systems only see the minimal data required for the task.
• Just-in-time approval. For operations that match a high‑risk policy, such as exporting more than a threshold of records, hoop.dev pauses the request and routes it to an authorized reviewer. The approval is recorded alongside the session.
• Command-level audit. Each SQL statement, HTTP request, or SSH command is logged with the planner’s user ID, timestamp, and outcome, providing the granular evidence gdpr expects.

Because hoop.dev sits in the data path, these enforcement outcomes exist only because the gateway intercepts the traffic. If the gateway were removed, the planner‑executor pair would revert to the insecure direct connection described earlier.

How the pieces fit together

The compliance architecture follows a clear three‑stage model:

1. Setup. Planners authenticate to an OIDC provider. The provider issues short‑lived tokens that encode the planner’s role and group membership. This stage defines who may initiate a request.
2. Data path. The executor connects through hoop.dev. The gateway validates the token, applies the appropriate policy, and forwards the request to the target service.
3. Enforcement outcomes. While the request passes through hoop.dev, the system records the session, masks personal fields, and, if needed, seeks human approval before the operation completes.

This separation makes it easy to demonstrate gdpr compliance. The audit log produced by hoop.dev can be exported to the organisation’s SIEM or compliance portal, providing the “who, what, when, and why” that regulators require.

Getting started with hoop.dev

Begin with the hoop.dev getting‑started guide, which walks you through deploying the gateway, registering a database connection, and configuring masking rules. The hoop.dev learn hub contains detailed articles on policy design, just-in-time approvals, and session replay.

Explore the source code and contribute at https://github.com/hoophq/hoop.