Imagine the request lands: a regulator, or your own DPO, wants the package that shows how personal data was accessed last quarter. Not a policy document, the actual record. Who reached the table of customer records, what they read, what was returned, and whether anything sensitive was exposed in the clear. Now imagine half of those access events were autonomous agents acting on their own, and you have to produce the same package for them.
That export package is the lens that makes GDPR concrete for automated access. Work backward from what it has to contain, and the controls you need fall out.
What the export package has to show
For agent access to systems holding personal data, a reviewer expects to see, per event:
- The identity behind the access, resolvable to a real principal, not an anonymous shared account.
- What the agent did: the queries and commands it ran against personal data.
- What data left the system, and whether sensitive fields were masked before they did.
- The basis for the access: that it was granted for a purpose, scoped, and time-bound rather than standing.
GDPR's principles of data minimisation and integrity show up here directly. The export package is not paperwork you generate at the end. It is a readout of records that either exist because access was built to produce them, or do not exist because it was not.
Why an agent cannot assemble its own package
If the only account of what an agent did with personal data is the agent's own log, the package is worthless. The audited process wrote its own evidence and could have dropped, reordered, or never captured the events that matter. An autonomous agent that changes its plan mid-task makes this worse, because the interesting access is often the access nobody anticipated.
The requirement that follows is blunt: the record of agent access to personal data has to live outside the agent process. Only then is the export package trustworthy, because it was written by something the agent could not edit.
Producing the package as a side effect of access
hoop.dev is an open-source access gateway that sits between the agent and the infrastructure holding personal data. The agent connects through it rather than holding a direct credential. The gateway authenticates against your identity provider, attributes the session to a named principal, grants access just in time and scoped to the task, records every command at the protocol level, and can mask personal data in returned results through a configured DLP provider.
Because the gateway writes the record, the export package is something you read off, not something you reconstruct. For a given window you can show each agent session, the identity behind it, the commands it ran, and that sensitive fields were redacted before they reached the agent. A session that would expose personal data unnecessarily can be routed for approval or blocked.
hoop.dev governs the infrastructure actions an agent takes, not its prompt or model output. For GDPR that is the right scope, because the obligation attaches to how personal data is accessed and what happens to it, which is exactly what crosses the gateway.
The getting-started guide covers connecting a data source with recording enabled, and the learn library walks through masking personal data inline.
FAQ
Does hoop.dev guarantee GDPR compliance for my agents?
No tool guarantees GDPR compliance. hoop.dev generates the access evidence a reviewer asks for, per-identity command-level records and proof that personal data was masked, which supports your GDPR program. The legal posture is yours to establish.
How does the export package handle agents versus humans?
The same way. Every connection through the gateway is recorded and attributed, so an agent session appears in the package with the same fields as a human session.
Can I show data minimisation for an agent?
Yes. Just-in-time, scoped access and inline masking are recorded, so the package shows the agent reached only what it needed and saw sensitive fields only when it had to.
Inspect it yourself
The most honest way to evaluate an evidence pipeline is to read it. hoop.dev is open source on GitHub, where you can see how sessions are recorded and how the export is built before you rely on it for a regulator.
