An offboarded contractor’s API token was still embedded in a CI job that drives a Tree of Thoughts reasoning engine. The job kept querying a customer database, returning full rows that contain names, addresses, and health information. No one noticed that the token granted unrestricted read access, and the pipeline never produced an audit trail of who asked for which data.
What LGPD expects from a data‑processing system
LGPD (Lei Geral de Proteção de Dados) requires that any system handling personal data provide clear accountability, traceability, and protection of the data subject’s rights. Key technical expectations include:
- Granular, time‑bound access that can be revoked instantly.
- Immutable logs that capture who accessed what, when, and why.
- Inline masking or redaction of PII when it is not needed for a given operation.
- Approval workflows for high‑risk queries or data‑modifying commands.
- Evidence that can be presented to auditors or data‑subject requests.
Current state of Tree of Thoughts without a gateway
In a typical deployment, Tree of Thoughts runs inside a container that talks directly to a PostgreSQL instance. The connection uses a static credential stored in the container image or an environment variable. The credential is often over‑scoped – it can read any table, write to logs, and even drop schemas. Because the engine uses the native database client, every query passes straight to the database without any intermediate control point.
Consequences of this setup are:
- No per‑request audit – the database only records the service account, not the individual engineer or CI job that issued the query.
- No masking – any SELECT returns raw PII, even when downstream logic only needs a subset.
- No approval step – a newly added prompt can trigger a bulk export of personal data without human review.
- Static credentials persist across deployments, making revocation difficult.
These gaps directly conflict with LGPD’s accountability and data‑minimization requirements.
Why a gateway is the missing piece
The compliance goal is to add just‑in‑time (JIT) access, approval workflows, session recording, and inline masking. The missing piece is a control surface that sits on every request before it reaches the database. Without a gateway, adding those controls would require rewriting the Tree of Thoughts code base, instrumenting the database, or relying on external monitoring that cannot block queries in real time.
Therefore, the architecture must place a Layer 7 proxy between the reasoning engine and its data sources. This proxy becomes the sole point where identity, policy, and enforcement intersect.
hoop.dev as the data‑path gateway
hoop.dev fulfills exactly that role. It is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH, and HTTP services. When Tree of Thoughts initiates a database session, the request is routed through hoop.dev instead of connecting directly to PostgreSQL.
hoop.dev verifies the caller’s OIDC token, reads group membership, and then applies policies that:
- Grant a time‑boxed credential that expires the moment the session ends.
- Require an approval step for queries that match a high‑risk pattern (for example, selecting all columns from a table containing health data).
- Record every command, the full response, and the identity of the requester.
- Mask configured PII fields in the response before they reach Tree of Thoughts.
Because hoop.dev sits in the data path, all enforcement outcomes are guaranteed to happen. The engine never sees raw credentials, never bypasses the masking layer, and never executes a command that has not been approved.
Generating LGPD‑ready evidence with hoop.dev
LGPD auditors ask for proof that access to personal data is controlled and logged. hoop.dev provides that proof in three ways:
- Session audit logs. Each log entry includes the user’s identity, the timestamp, the exact SQL statement, and the masked result set. The logs are immutable and can be exported to a SIEM or a compliance data lake.
- Approval records. When a high‑risk query triggers an approval workflow, hoop.dev stores the approver’s identity, the decision timestamp, and the rationale. This creates a clear chain of responsibility.
- Data‑masking evidence. The masking configuration is versioned inside hoop.dev, and every masked response is tagged with the mask version that was applied. Auditors can verify that only the allowed fields were exposed.
Combined, these artifacts satisfy the LGPD requirements for traceability, purpose limitation, and data‑subject protection.
Implementing the solution
To bring hoop.dev into the Tree of Thoughts architecture, follow the high‑level steps below. Detailed instructions are available in the getting‑started guide and the learn section of the documentation.
- Deploy the hoop.dev gateway in the same network segment as the PostgreSQL instance. The quick‑start uses Docker Compose, but Kubernetes or native AWS deployments are also supported.
- Register the PostgreSQL connection in hoop.dev, supplying the host, port, and a service‑level credential that hoop.dev will use on behalf of callers.
- Configure OIDC authentication with your identity provider (Okta, Azure AD, Google Workspace, etc.). This step defines who can request access.
- Define policy rules that identify high‑risk queries, the fields that must be masked, and the JIT time window for each request.
- Update the Tree of Thoughts deployment to point its database URI at the hoop.dev endpoint instead of the raw PostgreSQL address.
After deployment, every query issued by Tree of Thoughts will pass through hoop.dev, where it will be logged, possibly approved, and masked before reaching the database.
FAQ
Does hoop.dev make Tree of Thoughts LGPD compliant?
hoop.dev generates the audit evidence that LGPD requires, but full compliance also depends on organizational policies, data‑subject handling processes, and other controls outside the gateway.
How does inline masking work?
Masking rules are defined in hoop.dev’s configuration. When a response contains a configured PII field, hoop.dev replaces the value with a placeholder or a redacted token before the data is returned to the caller.
Can I keep using my existing CI pipelines?
Yes. hoop.dev accepts standard client connections, so CI jobs can continue to use the same database client; they simply point to the hoop.dev endpoint.
By placing hoop.dev in the data path, teams that run Tree of Thoughts gain the visibility, control, and evidence needed to meet LGPD’s stringent data‑protection obligations.
Explore the open‑source repository on GitHub to get started.
