A former contractor still has a personal access token that points at the company’s inference endpoint. The team never revoked the token, and the contractor can submit queries that include citizens’ names, addresses, and health details. When a data‑privacy audit arrives, the team cannot prove who ran which query, whether any personal data was exposed, or if the request was authorized. This scenario illustrates a common gap: modern AI inference services often run behind static credentials and receive traffic directly, leaving no verifiable trail.
Brazil’s General Data Protection Law (lgpd) requires organizations to demonstrate accountability for any processing of personal data. For inference workloads, accountability means knowing exactly which identity accessed the model, what input data was provided, whether the request was approved, and what output was returned. The law also mandates minimisation of personal data exposure, the ability to mask or redact sensitive fields, and the retention of immutable logs that auditors can review.
What lgpd expects from AI inference services
lgpd defines several technical and organisational controls that apply to inference pipelines:
- Purpose limitation and consent. Each request must be tied to a legitimate purpose and, where required, to explicit consent from the data subject.
- Access accountability. The system must record the identity of the requester, the time of the request, and the specific model version used.
- Data minimisation. Personal identifiers should be stripped or masked before they are stored or returned.
- Auditability. hoop.dev stores logs in a tamper‑evident, searchable store and retains them for the period defined by the organisation’s data‑retention policy.
- Incident response. When a breach is suspected, the organization must be able to replay the exact session that caused the exposure.
Meeting these expectations becomes straightforward when a control plane fronts the inference service and enforces policies before the request reaches the model.
Why the data path matters
Most teams already have a solid setup: they provision OIDC or SAML identities, assign least‑privilege roles to service accounts, and configure the inference engine with a static API key. This setup decides who may start a request, but it does not enforce any of the lgpd controls listed above. The request still travels straight to the model, bypassing any opportunity to log, mask, or require approval. In other words, the enforcement outcomes that lgpd demands exist only if a gateway sits in the data path.
How hoop.dev delivers the required evidence
hoop.dev is an identity‑aware proxy that sits between the requester and the inference endpoint. By placing the gateway in the data path, hoop.dev can apply every lgpd control without changing the client code.
Setup. Teams configure OIDC or SAML authentication in hoop.dev, map groups to inference permissions, and grant the gateway a minimal service‑account credential that can invoke the model. The gateway never stores user secrets; it only validates the presented token.