A single accidental exposure of PHI can cost an organization millions in fines and irreparable trust loss. For a developer like Devin, the stakes are personal as well: a careless query or a leaked credential can jeopardize patient privacy and stall a product launch.
Devin works on a health‑tech platform that stores electronic health records in a PostgreSQL database. The team shares a static database password in a configuration file, and every engineer runs the same client directly against the database from their laptops. There is no central log of who ran which query, no review of results that contain names, dates of birth, or lab values, and no way to stop a dangerous command before it reaches the server. In practice, the connection is a straight pipe from the developer’s terminal to the database.
Protected Health Information (PHI) is any individually identifiable health data that is created, received, maintained, or transmitted by a covered entity. Regulations such as HIPAA require covered entities to implement safeguards that limit access to the minimum necessary, ensure auditability, and protect data in transit and at rest. When PHI flows through an uncontrolled channel, the organization loses the ability to prove compliance and opens a vector for insider threat, lateral movement, and accidental leakage.
Why identity and least‑privilege alone are not enough
The first line of defense is a strong identity foundation. Devin authenticates to the corporate IdP via OIDC, receives a short‑lived token, and the token is mapped to a role that grants read‑only access to the “clinical‑data” schema. This setup, often called the "setup" layer, decides who can start a request. It is necessary because without a verified identity the system cannot enforce any policy. However, identity alone does not inspect the actual traffic, does not hide sensitive columns, and does not record the exact commands that were executed.
Because the request travels directly from Devin’s client to the database, the database itself becomes the only enforcement point. The database can log connections, but it cannot enforce context‑aware policies such as "mask SSN unless the request is approved by a compliance officer" or "block DELETE statements that target patient tables without a signed change request". Those finer‑grained controls must sit on the data path, not in the identity provider.
The data path must be an active gateway
To meet regulatory expectations, the organization needs a layer that sits between the identity system and the target resource. This layer, referred to as the "data path", is the only place where real‑time inspection, masking, approval, and recording can happen. By positioning a gateway on the network segment that hosts the database, every packet that carries a query or a response passes through a controllable point.
When the gateway is in place, it can enforce policies that are impossible to achieve with identity alone. It can rewrite result sets to hide PHI, require a just‑in‑time approval workflow for high‑risk operations, and reject commands that match a dangerous pattern. Because the gateway is the sole conduit, the enforcement outcomes are guaranteed to be applied to every request.
How hoop.dev fulfills the data‑path requirement
hoop.dev is built exactly for this purpose. It acts as a Layer 7 identity‑aware proxy that sits between Devin’s client and the PostgreSQL instance. The gateway verifies the OIDC token, extracts group membership, and then applies a policy engine to the live traffic. Because hoop.dev is the only path to the database, it can enforce the following outcomes:
- Session recording. hoop.dev records each query and its response, creating a replay log that auditors can inspect.
- Inline masking. When a result contains PHI such as Social Security numbers or medical diagnoses, hoop.dev redacts those fields before they reach the client.
- Just‑in‑time approval. For commands that modify patient records, hoop.dev routes the request to a compliance approver and only forwards it once the approval is granted.
- Command blocking. Dangerous statements like DROP DATABASE or mass DELETE are halted automatically, preventing accidental data loss.
- Audit trail. Every access decision, who approved it, and the masked or unmasked outcome are logged centrally for compliance reporting.
All of these enforcement outcomes exist only because hoop.dev occupies the data path. If hoop.dev were removed, the raw connection would resume, and none of the masking, approval, or recording would occur.
Operational benefits for Devin and the security team
With hoop.dev in place, Devin no longer needs to memorize which columns contain PHI or manually scrub output. The developer can work with the same familiar client tools while the gateway guarantees that sensitive fields never leave the secure zone unless explicitly allowed.
The security team gains continuous evidence for compliance programs. The recorded sessions provide the exact proof required by auditors to demonstrate that only authorized individuals accessed PHI, that every modification was approved, and that no raw PHI was exposed over the network. Because the gateway enforces policies centrally, the organization reduces the blast radius of compromised credentials, an attacker who steals Devin’s token would still be stopped by hoop.dev’s masking and command‑blocking rules.
Getting started with hoop.dev
Deploying the gateway is straightforward. The open‑source project provides a Docker Compose quick‑start that launches the proxy and a network‑resident agent near the PostgreSQL server. After the gateway is running, register the database connection, bind it to an OIDC client, and define policies that mask PHI fields and require approval for write operations. Detailed steps are covered in the getting started guide and the broader learn section which explains policy syntax and approval workflows.
Because hoop.dev is MIT licensed, teams can self‑host the component behind their own firewall, ensuring that no third‑party service ever sees the raw credentials or the PHI itself. The repository on GitHub contains the full source code, example configurations, and contribution guidelines.
Explore the source on GitHub to see how the proxy integrates with OIDC providers and how you can extend the policy engine for custom health‑tech requirements.
FAQ
Do I still need to encrypt the database itself?
Yes. hoop.dev protects data in transit and masks it in responses, but encryption at rest remains a best practice and satisfies additional regulatory controls.
Can hoop.dev work with other databases besides PostgreSQL?
Absolutely. The gateway supports a range of relational and NoSQL stores, each with the same ability to inspect traffic, mask fields, and enforce just‑in‑time approvals.
What happens if an approver is unavailable?
Policies can be configured with fallback rules, such as automatic denial after a timeout or escalation to an alternate reviewer, ensuring that no unapproved change slips through.
