An automated CI job that runs a migration script against a production database often carries a service account with read‑only privileges. The script needs to verify schema changes, but the same connection also returns rows that contain customer PII. Because the job writes logs to a shared storage bucket, anyone with bucket access can see the raw query results, including Social Security numbers and credit‑card fragments. The organization therefore requires data masking to redact those fields before they ever leave the database.
Teams frequently grant tool‑using agents static credentials that map directly to a database user. The credentials live in CI secret stores, and the agents use them without any intermediate check. When the agent issues a SELECT, the database streams the full row back. No component in the path inspects the payload, so sensitive fields travel unfiltered to the agent and then to downstream logs.
When an organization needs to let automated tools read data but must prevent exposure of regulated fields, data masking becomes a non‑negotiable control. Masking replaces or redacts designated columns in real time, ensuring that downstream consumers only see safe values. The challenge is to apply that transformation without rewriting every client or embedding custom logic in each tool.
Why identity alone is not enough
Most teams start by tightening identity. They move from shared passwords to OIDC‑backed service accounts, assign the least‑privilege role to each CI job, and enforce short‑lived tokens. This setup tells the system who is making the request and limits what actions the token can perform. However, the request still travels straight to the database over the network.
Because the database remains the final authority, it delivers exactly what it stores. The gateway that would inspect the response never exists, so there is no place to enforce data masking. The result is a partial solution: the job cannot create new tables, but it can still read raw PII.
Putting a gateway in the data path
This is where a Layer 7 access gateway solves the problem. hoop.dev sits between the authenticated agent and the target database. The gateway receives the OIDC token, validates it against the organization’s identity provider, and then forwards the request to the database using its own managed credential. Because the gateway controls the network flow, it can inspect each protocol message before it reaches the agent.
When the database returns a result set, hoop.dev applies the masking policy that the security team defined. Fields such as ssn, credit_card_number, or any custom column are replaced with placeholder values or hashed tokens. The transformed payload is then streamed back to the agent, and the original raw data never leaves the gateway.
Because hoop.dev owns the data path, it also records the entire session for replay, stores an audit trail, and can route suspicious queries to a human approver before execution. Those outcomes exist only because the gateway sits in the path; removing hoop.dev would eliminate masking, recording, and approval.
How to adopt the approach
- Deploy the gateway on a host that shares the same network segment as the database. The quick‑start Docker Compose file gets you up and running in minutes.
- Register the database as a connection in hoop.dev, supplying the host, port, and the credential that the gateway will use. The tool‑using agent never sees this credential.
- Define a masking policy in the portal or via the YAML configuration. List the columns to mask and the redaction method (static placeholder, hash, or custom function).
- Update the CI job to point its client (psql, mysql, etc.) at the hoop.dev endpoint instead of the raw database host. The client syntax remains unchanged; only the network address differs.
For step‑by‑step guidance, see the getting‑started documentation. Detailed masking examples are covered in the learn section of the site.
Frequently asked questions
hoop.dev applies masking at the protocol layer after the database returns the result set. The overhead is proportional to the number of rows and masked columns, and the gateway is optimized for high‑throughput workloads. Most teams observe only a modest latency increase compared with a direct connection.
Can I mask data from multiple database types with the same gateway?
Yes. hoop.dev supports PostgreSQL, MySQL, MSSQL, and several other databases. You define a masking rule per connection, and the gateway enforces it uniformly across all supported targets.
What happens to the original unmasked data?
The raw data never leaves the gateway. It is stored only in the database and in the encrypted session logs that hoop.dev creates for audit purposes. Those logs are protected by the same access controls that govern the gateway itself.
By inserting a Layer 7 gateway into the data path, organizations can let automated agents read what they need while guaranteeing that regulated fields stay hidden. The combination of identity verification, inline data masking, and session recording gives a complete, enforceable security posture.
Explore the open‑source code and contribute to the project on GitHub.
