An offboarded contractor still has a CI job that pushes updates to a Claude skill, and the skill continues to read and write personal data stored in a customer database. The organization discovers that the skill is still active, but there is no record of who approved the last change, no visibility into the queries the skill executed, and no way to prove that sensitive fields were masked before they left the system. Under Brazil’s General Data Protection Law (lgpd), that gap can translate into heavy fines and reputational damage.
What lgpd expects from AI‑powered integrations
lgpd defines personal data broadly and requires data controllers to demonstrate accountability for every processing activity. The law imposes four technical obligations that directly impact Claude Skills:
- Purpose limitation and consent tracking: Each access to personal data must be linked to a documented purpose and, where required, an explicit consent record.
- Data minimisation and masking: Only the data necessary for the task may be exposed, and any excess must be redacted before leaving the processing environment.
- Auditability: Controllers must retain immutable logs that show who accessed what data, when, and under which policy.
- Incident response evidence: If a breach is reported, the organization must produce detailed logs that prove the breach scope and the remedial actions taken.
Meeting these obligations with a traditional CI/CD pipeline is difficult because the pipeline itself does not see the data flowing through the Claude skill. The skill runs inside a container, authenticates directly to the database, and returns results to the calling service. Without a dedicated control point, the organization cannot enforce masking, cannot require just‑in‑time approval for risky queries, and cannot capture a reliable audit trail.
Why the control point must sit on the data path
All three lgpd requirements above rely on a single source of truth that observes the traffic between the skill and the underlying resource. A setup that only configures identity providers, service accounts, or IAM roles can decide who may start a connection, but it cannot enforce what that connection does once it reaches the target. The enforcement outcomes, masking, approval, logging, must be applied where the data actually moves.
Placing a gateway in the data path gives the organization a place to:
- Inspect each query or API call before it reaches the database.
- Apply real‑time redaction to any response that contains personal identifiers.
- Require a human approver for operations that exceed a predefined risk threshold.
- Record the full session, including timestamps, identities, and the exact payloads exchanged.
Without that gateway, the skill could continue to read raw rows, write unmasked data, and leave no trace for auditors.
How hoop.dev satisfies lgpd evidence requirements
hoop.dev is an open‑source layer‑7 gateway that sits between identities and infrastructure. When a Claude skill connects through hoop.dev, the gateway becomes the sole point that can enforce the lgpd controls described earlier. Specifically, hoop.dev:
- Generates evidence for lgpd audits: Every session is recorded and stored outside the skill’s runtime, providing immutable logs that tie each request to a user, a purpose, and a policy decision.
- Applies inline masking: Sensitive fields identified in the response are redacted before they leave the gateway, ensuring data minimisation without modifying the skill code.
- Enforces just‑in‑time approval: High‑risk queries trigger an approval workflow that must be satisfied before the gateway forwards the request.
- Scopes access at request time: The gateway checks the caller’s group membership and purpose against policy, allowing only the minimum privileges needed for the operation.
These outcomes exist only because hoop.dev sits in the data path. The identity layer (OIDC or SAML) decides who may start a connection, but hoop.dev is the active component that masks, approves, and logs. If the gateway were removed, none of the lgpd‑specific evidence would be produced.
Getting started with hoop.dev for Claude Skills
Deploying the gateway is a single‑step Docker Compose operation for most environments. The official getting‑started guide walks you through installing the agent, registering the target database, and configuring the OIDC provider that authenticates your CI jobs and service accounts. Once the gateway is running, you point your Claude skill’s client library at the hoop.dev endpoint instead of the raw database host. All traffic then flows through the gateway, where the policies you define are enforced automatically.
The learn section contains deeper explanations of policy syntax, masking rules, and approval workflow design. Those resources let you tailor the enforcement to the exact lgpd clauses that apply to your data processing activities.
FAQ
Do I need to modify my Claude skill code to use hoop.dev?
No. hoop.dev works at the protocol layer, so the skill continues to use its standard database driver or HTTP client. You only change the connection endpoint to point at the gateway.
How long are the session logs retained?
Retention is a configuration choice made in the gateway’s storage backend. For lgpd compliance you typically keep logs for the period required by the regulator, and hoop.dev makes it easy to adjust that window without touching the skill.
Can hoop.dev mask only specific columns?
Yes. Masking rules are defined per‑field, allowing you to redact personal identifiers while leaving other data visible for analytics.
Ready to see how the gateway can protect your Claude Skills and generate the audit evidence lgpd demands? Explore the source code on GitHub.
