A contractor who was off‑boarded last month still has a CI pipeline that spins up a Python agent runtime to pull data from internal services. The team never rotated the token used by that job, and the team stores the logs on a shared file share without any access controls. When the contractor’s account is eventually disabled, the pipeline continues to run, silently exfiltrating personal data that falls under Brazil’s General Data Protection Law, LGPD.
LGPD obliges organizations to protect personal data throughout its lifecycle, to keep detailed records of who accessed what, and to demonstrate that any processing was authorized and limited to the purpose for which consent was given. For agent runtimes that execute code on behalf of users or services, the law expects three concrete capabilities: a verifiable identity for every request, real‑time enforcement that can block or mask data that should not be disclosed, and a tamper‑evident log that can be presented to regulators.
Many teams rely on an identity provider such as Okta or Azure AD to issue short‑lived tokens to their agents. The token proves who started the session, but the enforcement point usually lives inside the agent itself. Because the agent runs on the same host that holds the credentials, the team can reconfigure it, the team can alter the logs, and the agent can emit sensitive fields unfiltered. In other words, the setup decides who may start a connection, but it does not guarantee that every command is inspected or that a complete, tamper‑evident record exists.
hoop.dev inserts a Layer 7 gateway between the identity layer and the target resource. The gateway runs as a network‑resident agent and proxies all traffic from the user or service to the underlying database, Kubernetes cluster, SSH host, or HTTP API. Because the proxy sits in the data path, hoop.dev enforces policies that the original agent cannot. hoop.dev records every session, masks fields that match privacy rules, requires just‑in‑time approval for risky commands, and stores an immutable audit log that can be exported for LGPD audits. The identity provider still determines who may request access, but hoop.dev is the only place where the law‑required enforcement outcomes are realized.
What LGPD expects from agent runtimes
LGPD defines personal data as any information that can identify an individual, directly or indirectly. For an agent runtime that processes requests, the regulation requires:
- Purpose limitation: each execution must be tied to a legitimate business purpose and documented.
- Data minimisation: only the data necessary for that purpose may be returned.
- Accountability: organizations must keep records of who accessed which data, when, and under what justification.
- Security of processing: technical measures must prevent unauthorized disclosure, alteration, or loss of personal data.
When an agent runtime connects to a database or an internal API, the runtime itself often has full visibility into query results. Without a transparent enforcement layer, it can inadvertently return more columns than needed, or a mis‑configured job can dump entire tables. LGPD therefore expects a mechanism that inspects the payload, applies masking rules, and logs the interaction in a way that prevents later tampering.
How hoop.dev creates the required evidence
Because hoop.dev proxies the connection, it can apply policy at the protocol level. The platform offers three evidence‑generating capabilities that map directly to LGPD requirements: