An offboarded contractor still has a service‑account token that a nightly batch job uses to push data between two internal services. Engineers copied the token into a CI configuration file and never rotated it. When the job fails, engineers scramble to read logs that live on the source host, but no one can prove which downstream system actually received the payload. The connection is a straight TCP stream between two APIs, authenticated only by the shared secret.
Brazil’s General Data Protection Law (lgpd) requires organizations to demonstrate control over personal data throughout its lifecycle. Controllers must show who accessed what, when, and for what purpose. They must also ensure that only the minimum necessary data is exposed, that sensitive fields are masked when not needed, and that engineers can review and, if necessary, revoke any unusual activity.
In many A2A deployments the reality looks like the scenario above: static credentials stored in code repositories, direct network calls that bypass any centralized policy point, and audit trails that exist only as ad‑hoc log files on the source host. This model satisfies the functional need to move data, but it fails lgpd because there is no immutable record of each request, no way to enforce field‑level redaction, and no just‑in‑time approval for high‑risk operations.
The first step toward compliance is to introduce non‑human identities that are provisioned with the least privileges required for a specific integration. That eliminates the broad, standing token and limits the blast radius of a breach. However, even with scoped service accounts, the request still reaches the target API directly, without any gateway that can observe, mask, or log the transaction. The missing piece is a data‑path enforcement layer.
Why a data‑path gateway is required for lgpd evidence
lgpd demands evidence that organizations can produce on demand: who invoked which endpoint, the exact payload, and any redaction that was applied. To collect that evidence, the control point must sit where the traffic flows, not at the edges of identity or at the target service.
A Layer 7 gateway that proxies the connection can inspect the protocol, apply policies, and write audit entries before the request reaches the backend.
hoop.dev acts as that gateway. It sits between the identity provider (Okta, Azure AD, Google Workspace, etc.) and the A2A endpoint, terminating the TLS session and re‑establishing a new session to the target. Because hoop.dev is in the data path, it enforces the following lgpd‑related controls:
- Session recording. hoop.dev records each request and response, preserving a replayable log that includes timestamps, caller identity, and the exact data transferred.
- Inline data masking. hoop.dev redacts sensitive fields such as personal identifiers in real time, ensuring that downstream services only see the data they need.
- Just‑in‑time (JIT) access. hoop.dev grants temporary permission for a single transaction and revokes it automatically after the session ends.
- Approval workflows. hoop.dev triggers a human approval step before forwarding high‑risk operations, creating a documented decision trail.
hoop.dev generates all of these outcomes because it is the active component in the data path. If the gateway were removed, the same service account would connect directly to the API, and none of the above evidence would exist.
How the evidence aligns with lgpd requirements
lgpd’s accountability principle satisfies when an organization produces a complete audit trail. hoop.dev’s session logs give auditors a chronological view of every integration call, including the identity that initiated it. The masking feature supports the data‑minimization rule by ensuring that only necessary fields are exposed, and the logs retain the original values for forensic purposes without exposing them to downstream services. JIT access and approval workflows show that hoop.dev grants access on a need‑to‑know basis, addressing the purpose‑limitation clause.
Because hoop.dev is open source and self‑hosted, organizations can store the logs in a location that meets their retention policies, preserving the integrity required for regulatory review. The gateway’s architecture also means that the target service never sees the raw credential; hoop.dev holds the secret and presents short‑lived tokens to the backend, reducing the risk of credential leakage.
Getting started with hoop.dev for A2A lgpd compliance
To adopt this approach, start by deploying the hoop.dev gateway in the same network segment as your A2A services. The official getting‑started guide walks you through a Docker Compose deployment, OIDC configuration, and how to register a new connection for your API. Once the gateway is running, define a policy that masks personal identifiers, requires JIT approval for write‑heavy endpoints, and enables session recording.
All configuration is expressed as declarative resources, so you can version‑control the policy definitions alongside your application code. For deeper insight into policy options, see the learn section, which covers masking rules, approval workflows, and audit‑log formats.
FAQ
Do I need to change my existing applications?
No. hoop.dev works as a transparent proxy. Your services continue to use their native clients (HTTP, gRPC, etc.) while hoop.dev intercepts the traffic and applies the configured controls.
How does hoop.dev help with data‑subject access requests?
Because every request is recorded, you can query the audit store for all interactions involving a particular identifier. The logs contain both the masked view (as seen by the downstream service) and the original values (kept securely for compliance), enabling you to respond to a subject’s request without rebuilding the data pipeline.
Can I run hoop.dev on‑premises?
Yes. The gateway is open source and can be self‑hosted in any environment that can reach your A2A endpoints. This gives you full control over where audit data is stored and how long it is retained.
Explore the source code, contribute improvements, or fork the project on GitHub: https://github.com/hoophq/hoop.
