Keeping Function Calling LGPD-Compliant

Failing to prove compliance with LGPD can trigger multi‑million‑real‑currency penalties and erode customer trust. When an LLM‑driven application invokes external functions, data moves across network boundaries, and every request becomes a potential audit liability. Without concrete evidence that only authorized users triggered those calls, that data was masked where required, and the operation was approved, an organization cannot demonstrate the controls demanded by the law.

Function calling is attractive because it lets developers offload complex work to micro‑services, but it also expands the attack surface. Sensitive personal identifiers, names, addresses, CPF numbers, can be passed as arguments, stored in logs, or returned in responses. LGPD mandates that any processing of personal data be logged, that access be limited to the minimum necessary, and that the organization retain proof of consent and justification for each use.

Most teams rely on identity providers, OIDC tokens, and role‑based access controls to decide who may invoke a function. Those setups answer the question “who is calling?” but they do not capture what was actually sent, whether the payload contained protected data, or whether a human approved the operation. The missing piece is a control plane that sits on the data path, watches every request, and produces the audit artifacts required by regulators.

Why the data path matters for LGPD evidence

LGPD compliance evidence must be trustworthy, complete, and tamper‑evident. A system that records only after the request reaches the downstream service cannot guarantee that the request was not altered, that sensitive fields were not exposed, or that an unauthorized user did not bypass approval. The enforcement point therefore has to be the gateway that all function‑calling traffic traverses.

Placing controls at the gateway gives three concrete benefits:

• Session recording: Every function call, its arguments, and the response are recorded in a durable log.
• Inline masking: Sensitive fields are redacted in real time, ensuring that logs never store raw personal data.
• Just‑in‑time approval: High‑risk calls can be routed to a human reviewer before they are forwarded to the target service.

These outcomes exist only because the gateway can inspect and act on the traffic. The surrounding identity setup alone cannot provide them.

Introducing hoop.dev as the LGPD‑ready gateway

hoop.dev is an open‑source Layer 7 gateway that sits between callers and the functions they invoke. It consumes OIDC or SAML tokens to authenticate users, but the enforcement happens inside the gateway itself. Because hoop.dev proxies the connection, it can apply the three enforcement outcomes described above.

When a user initiates a function call, hoop.dev checks the user’s group membership and any policy that marks the call as sensitive. If the policy requires approval, the request is paused and presented to an authorized reviewer. Once approved, hoop.dev forwards the call to the target service while simultaneously recording the full request and response payload.

During recording, hoop.dev applies inline masking rules that strip or hash personal identifiers before the data is written to the audit store. The resulting log contains a complete, audit‑ready trail that shows who called what, when, and with which arguments, exactly the artifact an LGPD auditor expects.

Because the gateway holds the service credentials, the caller never sees them. This separation satisfies the “least‑privilege” principle and reduces the risk of credential leakage.

How the evidence fits into an LGPD audit

Auditors typically ask for:

1. Proof of user identity for each data‑processing event.
2. Records of the data that was processed, with any personal fields redacted.
3. Evidence of approval for high‑risk operations.
4. Retention of logs for the period required by LGPD.

hoop.dev generates each of these artifacts automatically:

• The session log includes the authenticated user ID extracted from the OIDC token.
• Inline masking guarantees that personal data never appears in clear text within the stored log.
• Approval workflows are captured as part of the session record, showing who granted permission and when.
• Logs are written to a durable store that can be configured for the statutory retention period.

By centralising these controls, organizations avoid the “point‑solution” trap where each micro‑service emits its own logs, leading to gaps and inconsistencies.

Getting started with hoop.dev for function calling

To adopt hoop.dev, begin with the standard deployment model: run the gateway in Docker Compose or Kubernetes, configure an OIDC provider, and register your function‑calling endpoint as a connection. The gateway will hold the service credentials, and your existing client libraries (for example, the HTTP client that invokes the function) can point at the hoop.dev address without any code changes.

For detailed steps, see the getting‑started guide and the broader learn section, which cover identity configuration, policy definition, and how to enable masking and approval workflows.

FAQ

Do I need to modify my function code to use hoop.dev?

No. hoop.dev works at the protocol layer, so existing clients continue to call the function endpoint as before. The only change is the network address they target.

Can I mask only specific fields for LGPD?

Yes. Masking rules are defined in the gateway’s policy file, allowing you to target any JSON key, header, or query parameter that contains personal data.

What happens if a call is rejected by the approval workflow?

hoop.dev returns a clear error to the caller and records the rejection, including the reviewer’s identity, providing a complete audit trail of the denied request.

Explore the source code and contribute on GitHub.