An offboarded contractor still has a service account that talks to the company’s vector database used for long-term memory. Weeks later a data-subject request arrives, and the team discovers that personal records have been read by that stale credential. The breach triggers a costly investigation and a notice to the regulator.
What lgpd expects from long-term memory stores
LGPD (Lei Geral de Proteção de Dados) requires organizations to keep a complete trail that cannot be altered without detection for every access to personal data. The law also mandates purpose limitation, data minimisation, the right to access, the right to erasure, and the ability to mask or redact personal information when it is not needed for a given operation. In practice, a system that stores embeddings, cached chat histories, or any persistent LLM-derived artefacts must be able to answer three questions for every request:
- Who accessed which record and when?
- Was the access aligned with a legitimate purpose?
- Did the response expose personal data that should have been hidden?
Meeting those expectations is easy to overlook because the underlying storage engine (a PostgreSQL instance, a Redis cache, a cloud-hosted vector DB, etc.) typically offers only basic authentication and logging. The default logs do not capture query-level details, they do not support inline redaction, and they cannot enforce approval workflows for high-risk queries. As a result, organizations often rely on ad-hoc processes that do not produce the audit evidence LGPD demands.
Why a single control surface is required
The first step toward compliance is to establish a trustworthy identity layer. Using OIDC or SAML, the organisation can issue short-lived tokens that represent a specific engineer, a CI job, or an AI-driven agent. That setup decides *who* can start a session, but it does not enforce *what* the session may do. Without a gate that sits on the data path, a token can still be presented directly to the database, allowing the bearer to run any command, read any row, and bypass any masking policy.
Therefore, compliance requires a second, distinct component: an identity-aware proxy that intercepts every protocol exchange, applies policy, and records the outcome. Only when the proxy sits between the user and the long-term memory service can the organisation guarantee that every read, write, or delete operation is subject to LGPD-aligned controls.
hoop.dev as the data-path enforcement layer
hoop.dev provides exactly that enforcement layer. It is a layer-7 gateway that proxies connections to databases, Redis, or any supported long-term memory backend. The gateway verifies the caller’s OIDC token, extracts group membership, and then inspects each request at the protocol level. Because the gateway is the only point where traffic flows, it can:
- Record every session, including the identity, the exact query, and the response payload.
- Apply inline masking to hide personal fields before they leave the backend.
- Require just-in-time approval for queries that match a high-risk pattern (for example, bulk export of user identifiers).
- Enforce time-boxed, least-privilege access so that a token can only read the data needed for a specific task.
All of these enforcement outcomes exist only because hoop.dev sits in the data path. The identity system alone cannot provide them, and the backend storage cannot enforce them without an external gate.