LGPD for JSON Schema

When a contractor leaves a project, the team often forgets to revoke the API key that allows direct reads of the JSON schema used to validate customer data. The next day a batch job runs against that schema, pulls personal identifiers, and writes them to a log that no one monitors. The incident goes unnoticed until a regulator cites the organization for failing to provide lgpd‑required audit evidence.

lgpd expects organizations to maintain a clear inventory of personal data processing activities, to limit collection to what is strictly necessary, and to be able to demonstrate who accessed what data and when. It also requires that sensitive fields be protected, that any change to processing be approved, and that a replayable record exists for auditors.

In many development pipelines JSON schema lives in a source repository and is consumed directly by services without any runtime guardrails. The schema files are version‑controlled, but the actual data flowing through validation layers is invisible to compliance teams. Engineers can query the schema, inject new fields, or run ad‑hoc validation scripts with broad permissions. No central point records those accesses, no inline masking hides personal identifiers, and no approval workflow blocks accidental exposure.

Why lgpd matters for JSON schema

lgpd treats a schema as a data processing artifact because it defines the shape of personal information. Auditors look for:

• Evidence that only authorized identities have read or modify rights.
• Logs showing each validation request, the payload, and the outcome.
• Proof that fields containing names, addresses, or CPF numbers are masked or redacted in logs.
• Approval trails for schema changes that could broaden data collection.

Without a dedicated control plane, these signals are scattered or missing entirely.

What a proper control surface looks like

The missing piece is a data‑path gateway that sits between every client, human or automated, and the schema validation engine. The gateway must be able to:

1. Authenticate the caller via a federated OIDC provider.
2. Enforce just‑in‑time access policies that grant the minimum scope needed for a single operation.
3. Mask personal fields in responses before they are written to logs.
4. Require a human approval step for any request that attempts to modify the schema or to extract bulk records.
5. Record the full request and response payload, along with the identity and timestamp, for replay.

When these capabilities live in the data path, every enforcement outcome is guaranteed to happen, because nothing can bypass the gateway.

hoop.dev as the lgpd‑ready data path

hoop.dev implements exactly this architecture. It runs a lightweight agent inside the network that proxies all JSON‑schema validation traffic. The gateway authenticates each caller against the organization’s OIDC identity provider, then applies policy checks before the request reaches the validator.

hoop.dev records each session, capturing the raw request, the validated output, and the identity that initiated the call. It masks configured personal fields, such as email or cpf, in the stored logs, ensuring that audit trails contain no clear‑text identifiers. If a request attempts to read an entire dataset or to change the schema, hoop.dev routes the operation to a just‑in‑time approval workflow, requiring a designated reviewer to grant temporary permission.

All of these actions produce the evidence lgpd auditors demand: recorded logs, masked data, and documented approvals. Because hoop.dev sits in the data path, the enforcement outcomes cannot be disabled by altering the downstream validator or by changing client code.

Organizations can start quickly by following the getting‑started guide. The documentation explains how to register a JSON‑schema service, define masking rules, and configure approval policies. Detailed feature descriptions are available in the learn section.

FAQ

Do I need to modify my existing JSON schema files?

No. hoop.dev works as a transparent proxy, so the schema definition files remain unchanged. You only add configuration for masking and approval inside the gateway.

How does hoop.dev help with data‑subject access requests?

Because every validation request is logged with the requesting identity, you can retrieve the exact payloads that were processed for a given data subject. The logs are already masked, satisfying the requirement to provide data without exposing additional personal information.

Can hoop.dev integrate with my current OIDC provider?

Yes. hoop.dev acts as a relying party, verifying tokens from any OIDC‑compatible IdP such as Okta, Azure AD, or Google Workspace. No custom code is required.

Explore the open‑source implementation on GitHub to see how the gateway can be self‑hosted and extended for your lgpd compliance program.