A fintech startup rolls out a fleet of autonomous agents that scrape customer transaction data from a PostgreSQL store, all while trying to meet LGPD requirements. Each agent is packaged with the same service‑account key, embedded in the container image, and the CI pipeline pushes new binaries without any review of the queries they run. When a regulator asks for a record of who accessed personal data, the team can only point to a vague log entry that says “agent‑123 executed a query”.
Even after the company moves to per‑agent OIDC tokens and restricts each token to read‑only access on specific tables, the agents still connect directly to the database. The request travels over the network straight to PostgreSQL, and nothing intercepts the response. Sensitive fields such as CPF numbers or credit‑card fragments flow back to the agent unfiltered, and there is no immutable proof of which query returned which rows.
LGPD (Lei Geral de Proteção de Dados) expects data controllers to enforce data minimization, provide audit trails, and protect personal data at rest and in transit. The law requires that any processing of personal information be logged with the identity of the processor, the purpose of the access, and the exact data elements that were disclosed. It also mandates that organizations be able to mask or redact personal data when it is not needed for the business purpose, and that evidence of compliance be readily available for auditors.
How LGPD requirements map to multi‑agent systems
To satisfy LGPD, a multi‑agent architecture must address three core controls:
- Identity‑driven access: each agent must present a verifiable identity, and the system must enforce the principle of least privilege for that identity.
- Runtime governance: every request and response must be inspected, logged, and, when necessary, altered to hide personal data that is outside the approved scope.
- Evidence collection: the platform must retain immutable records that auditors can query to prove who accessed what, when, and under which policy.
Without a dedicated gateway, the first bullet is only partially met – agents can be given distinct tokens, but the gateway that would enforce per‑request policies is missing. The second and third bullets rely on a component that can sit between the agent and the target service, inspect the wire‑protocol, and apply masking or approval workflows in real time.
Why hoop.dev is needed in the data path
hoop.dev is a Layer 7 gateway that sits exactly where the enforcement must happen – between the agent’s identity and the infrastructure resource. Because hoop.dev proxies the connection, it can:
- Record every session, including the full request and response payloads, and associate them with the agent’s OIDC identity. This creates the audit trail LGPD demands.
- Apply inline data masking on fields that are classified as personal data, ensuring that downstream services only see the minimal subset required for the operation.
- Require just‑in‑time approval for high‑risk queries, such as bulk extracts or operations that touch sensitive columns, and block commands that violate policy before they reach the database.
- Enforce least‑privilege scopes per agent, because the gateway validates each request against the token’s claims and can deny access that exceeds the granted role.
All of these outcomes exist only because hoop.dev occupies the data path. The identity system alone cannot guarantee that a token‑holder does not accidentally run a query that leaks personal data, and the database itself does not provide per‑request masking or approval. By placing hoop.dev in front of PostgreSQL, MongoDB, or any other supported target, the organization gains a single, auditable control point that satisfies the core LGPD controls.