A single breach of personal data can trigger fines of up to 2 % of a company’s revenue under Brazil’s LGPD, not to mention the loss of customer trust and the cost of remediation.
Many organizations have begun to route large language model (LLM) requests through an MCP gateway so that developers can ask the model to retrieve customer records, run analytics, or generate support replies. In practice the gateway often forwards the request directly to the underlying database or API without any visibility into which fields were read, whether the response contained personally identifiable information, or who approved the operation.
What compliance demands beyond authentication
Even when an organization enforces OIDC authentication for every LLM call, the request still reaches the target system as a regular client. The authentication step tells the gateway who is asking, but it does not automatically capture what data was accessed, mask sensitive fields, or require a human sign‑off for high‑risk queries. LGPD expects concrete evidence that personal data was handled according to purpose, that access was limited to the minimum necessary, and that any deviation was recorded and justified.
hoop.dev as the data‑path enforcement point
hoop.dev sits in the data path between the LLM and the backend service, acting as an identity‑aware proxy that can enforce policy on every wire‑protocol interaction. Because the gateway intercepts the request before it reaches the database, it can apply just‑in‑time approvals, block commands that exceed predefined thresholds, and replace personally identifiable fields with masked placeholders in real time. At the same time, hoop.dev records the full session, including the authenticated user, the exact query, the masked response, and the time of approval, so that an audit log is generated automatically.
Audit artifacts generated for LGPD
The evidence required by LGPD maps directly to the artifacts that hoop.dev produces:
- A chronologically ordered log entry for each session, containing the user identity, the client IP, and the timestamp of the request.
- The exact command or query that was issued, stored in an immutable record.
- The response payload after inline masking, demonstrating that personal data was not exposed in clear text.
- An approval record that shows who granted the just‑in‑time exception and when.
- A replayable session file that can be streamed to auditors to verify the end‑to‑end flow.
Because hoop.dev creates all of these records at the gateway, they remain independent of the underlying database’s own logging, and no one can alter them from the service that processes the request.
Deploying an MCP gateway with hoop.dev
To start generating LGPD‑ready evidence, deploy the MCP gateway component that ships with hoop.dev. You can follow the getting‑started guide and explore deeper features in the learning portal. The quick‑start guide walks you through a Docker Compose launch that configures OIDC authentication, defines the backend connection, and enables masking and approval policies out of the box. Once the agent runs inside your network, point your LLM client at the local proxy port and let hoop.dev handle credential injection, policy enforcement, and audit logging.
Why a gateway beats native database logs
Database‑level audit trails record the fact that a query ran, but they rarely capture the human decision that allowed the query or the transformation that the system applies to the result set. Because hoop.dev sits in front of the database, it can augment the raw query log with the authenticated user, the approval event, and the masked payload. This unified view eliminates gaps that arise when teams rely on separate logging mechanisms, and it guarantees that no attacker can alter the evidence, even if a database instance becomes compromised.
Configuring masking and approval policies
hoop.dev’s policy language lets you declare which JSON or column fields are considered personal data and must be masked, and it lets you set thresholds that trigger a just‑in‑time approval workflow. For example, you can require that any query returning more than ten rows containing a CPF field be paused until a data‑privacy officer approves it. You store the policy file in the gateway’s configuration and version‑control it alongside your infrastructure code, giving you an auditable change history for the policies themselves. When a request matches a rule, hoop.dev automatically logs the rule ID, the approver’s identity, and the decision timestamp.
FAQ
How do I integrate an existing LLM client with hoop.dev?
You keep the same client library and simply change the endpoint to the local proxy address that the MCP gateway exposes. The gateway injects the service credentials, applies the configured policies, and returns the masked response, so no code changes are required beyond the endpoint.
Can hoop.dev automatically hide Brazilian personal data?
Yes. By defining masking rules that target fields such as CPF, CNPJ, or email, hoop.dev replaces those values with placeholders before the data leaves the gateway. The original values never appear in the downstream service logs, and the masked payload is stored in the audit record, satisfying LGPD’s requirement to limit exposure of sensitive identifiers.
What evidence can I export for an LGPD audit?
hoop.dev can export the session log, the masked response, and the approval record as JSON or CSV files. Each file includes timestamps, user IDs, and the policy rule that was applied, giving auditors a complete audit trail that links the request to the final masked output.
For the full source code, contribution guidelines, and issue tracker, visit the hoop.dev GitHub repository.
