When a subagent runs a database query on behalf of a user, the organization loses visibility into who saw what personal data.
Most teams deploy subagents as long‑lived processes that hold static credentials and connect directly to the target system. The subagent trusts the caller, the caller trusts the subagent, and no central point records the exact query, the response, or the decision to allow the request. In practice this means that personal data can flow through a subagent without any immutable audit trail, making a gdpr audit a guessing game.
gdpr requires demonstrable evidence that personal data is accessed only for legitimate purposes, that every access is attributable, and that any exposure is detectable. The missing piece in the typical subagent model is a control surface that can capture the who, what, when, and why of each request while still allowing the subagent to perform its job. Even if the organization adds role‑based tokens or federated identities, the request still reaches the database directly, without any inline masking, approval workflow, or replayable session record.
hoop.dev inserts a Layer 7 gateway between the subagent and the target infrastructure. By proxying every protocol‑level request, hoop.dev becomes the only place where enforcement can happen. It records each session, masks sensitive fields in real time, and routes risky operations through a just‑in‑time approval workflow. Because the gateway sits in the data path, every enforcement outcome is attributable to hoop.dev, not to the subagent or the identity token.
How subagents generate gdpr evidence through hoop.dev
When a subagent initiates a connection, it authenticates to hoop.dev using an OIDC token. hoop.dev validates the token, extracts group membership, and then forwards the request to the target database. At that moment hoop.dev creates a session record that includes the subagent identity, the user identity (if delegated), the timestamp, and the exact query string. The record is immutable and stored outside the subagent’s process, ensuring that even a compromised subagent cannot erase the evidence.
Session recording for accountability
hoop.dev records every byte that travels in both directions. The resulting logs show which rows were returned, which columns contained personal data, and whether the subagent attempted to modify that data. Auditors can replay a session to verify that the subagent respected data‑minimisation principles and that no unauthorized export occurred.
Inline masking of personal data
Before the database response reaches the subagent, hoop.dev can apply field‑level masking based on gdpr‑defined categories such as "personal identifier" or "location data." The masking rules are defined once in the gateway configuration and applied to every matching response, so the subagent never sees raw personal data unless an explicit exception is granted.
Just‑in‑time approvals and audit trails
When a subagent request matches a high‑risk pattern, such as exporting a large number of rows or accessing a protected table, hoop.dev pauses the request and creates an approval ticket. An authorized reviewer can approve or deny the operation in real time. The decision, the reviewer identity, and the reason are all appended to the session record, providing a complete chain of custody for gdpr‑required accountability.
Operational workflow
- Deploy the hoop.dev gateway close to the target resource. The agent runs inside the same network segment, keeping credentials out of the subagent’s reach.
- Register the target (e.g., a PostgreSQL instance) in hoop.dev and define masking policies for columns that contain personal data.
- Configure the subagent to authenticate to hoop.dev via OIDC. The subagent presents its token, and hoop.dev maps it to the appropriate user or service identity.
- All subsequent queries flow through hoop.dev, which enforces masking, records the session, and triggers approvals when needed.
For a step‑by‑step guide, see the getting‑started documentation and the broader feature overview at hoop.dev/learn. The source code and contribution guidelines are available on GitHub at https://github.com/hoophq/hoop.
FAQ
Does hoop.dev replace the subagent?
No. The subagent continues to perform its business logic. hoop.dev only proxies the network traffic, adding governance controls without requiring code changes in the subagent.
Can I use hoop.dev with existing OIDC providers?
Yes. hoop.dev acts as a relying party for any OIDC or SAML identity provider, so you can keep your existing IdP and still gain gdpr‑ready audit evidence.
What happens to the audit logs after a session ends?
hoop.dev stores the logs in a store that is separate from the subagent’s host. The logs are retained according to your retention policy and can be exported for regulator review.
