When a gdpr audit arrives, you can hand over a comprehensive audit log of every agent‑initiated request, with sensitive fields already redacted and approvals documented.
gdpr demands accountability. Controllers must be able to demonstrate that personal data is accessed only for legitimate purposes, that processing is logged, and that any exposure of identifying information is minimized. Auditors look for persistent logs, evidence of consent or lawful basis, and proof that data‑subjects’ rights can be honored on demand.
Agent runtimes, scripts, CI jobs, or AI‑driven bots, are often the bridge between user intent and data stores. In many organisations the runtime runs with a static credential that grants blanket read and write rights across multiple databases. The code is version‑controlled, but the credential is hard‑coded or stored in a shared vault that many pipelines can reach. When the runtime contacts a database, there is no central point that can inspect the query, redact personal identifiers, or require a human sign‑off before a bulk export.
What auditors expect from a gdpr‑compliant runtime
Auditors request three categories of evidence: a log of who initiated each request, the exact payload sent to the target, and any governance actions (approvals, denials, redactions) applied before the request reached the data store. They also need proof that the runtime never exposed raw credentials to the operator and that any personal data returned to the caller was filtered according to policy.
The unsanitized starting state
In practice many teams grant a service account full‑admin rights to a PostgreSQL instance, then let a nightly CI job run arbitrary SQL scripts. The job writes its output to a log file that lives on the build server, but the log contains raw rows with names, emails, and phone numbers. No one reviews the log, and the CI system never asks for approval before a bulk delete. If a breach occurs, the organisation cannot prove which query accessed the data or whether the operation complied with gdpr’s purpose limitation principle.
The precondition we need to address
What we must fix is the lack of runtime‑level governance: the ability to enforce least‑privilege, require just‑in‑time approval, and mask personal identifiers in‑flight. Even after adding those controls, the request still travels directly to the database, and without a central gateway there is no place to record the decision, hide the credential, or apply inline masking. The setup, identity federation, role assignment, and credential rotation, decides who may start a request, but it does not enforce the gdpr controls on the data path.
hoop.dev as the data‑path enforcement layer
hoop.dev sits in the data path between the agent runtime and the target service. It authenticates the caller via OIDC or SAML, then proxies the protocol‑level traffic. Because the gateway is the only point that can see the request, hoop.dev can enforce gdpr‑required outcomes. It records each session, masks sensitive fields in responses, and can pause a request for a manual approval step before it reaches the database. The gateway never reveals the underlying credential to the runtime, so the agent never sees the secret.
When a runtime issues a query, hoop.dev inspects the SQL statement, applies a policy that redacts columns such as email or ssn, and logs the original statement, the masked response, and the identity of the caller. If the policy requires a data‑export approval, hoop.dev routes the request to an approver, records the decision, and only then forwards the query. All of these actions are stored in a persistent audit log that can be exported to meet gdpr evidence requests.