When an autonomous model pulls patient records without proper safeguards, the organization faces regulatory fines, loss of trust, and costly remediation. A single exposed PHI element can trigger HIPAA penalties that run into millions of dollars, while the brand suffers long‑term damage.
Today many teams drop an agentic AI service straight onto internal APIs or databases. The model authenticates with a shared service account, reuses a static token, and runs with broad permissions that were never intended for a non‑human actor. There is no per‑request audit, no real‑time visibility into what data is returned, and no way to block a query that drifts into protected health information.
Why phi protection matters for agentic AI
Even when an organization provisions a dedicated non‑human identity and scopes it to the minimum set of operations, the request still travels directly to the target system. The AI can still read a full patient table, write notes, or exfiltrate data because the enforcement point lives inside the target, not at the gateway. The result is a blind spot: the system knows who called, but it cannot see what was asked, what was returned, or whether a human approved the action.
Introducing a data‑path enforcement layer
What is missing is a boundary that sits between the AI and the resource, where policies can be applied consistently regardless of the underlying service. The boundary must be able to inspect the wire‑level protocol, mask sensitive fields, halt disallowed commands, and capture a replayable record of every interaction.
hoop.dev as the identity‑aware proxy
hoop.dev fulfills that role. It is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH hosts, and HTTP services. The gateway authenticates the AI via OIDC or SAML, reads group membership, and then enforces policy before any traffic reaches the target.
Setup: identity and provisioning
The first step is to create a service account for the AI and bind it to an OIDC provider. The account receives a short‑lived token that proves the AI’s identity. hoop.dev validates that token, extracts the principal’s attributes, and maps them to a policy that defines which resources the AI may contact and what operations are allowed. This step decides who the request is, but it does not enforce any data‑level rule on its own.
The data path: where enforcement lives
All traffic from the AI passes through hoop.dev before reaching the backend. Because the gateway operates at the protocol layer, it can examine each SQL statement, each Kubernetes API call, or each SSH command. It is the only place where masking, approval, and command blocking can be reliably applied.
Enforcement outcomes delivered by hoop.dev
- hoop.dev records every session, creating an audit trail that auditors can replay.
- hoop.dev masks PHI fields in query results in real time, ensuring that downstream logs never contain raw patient data such as ssn or medical_record_number.
- hoop.dev requires just‑in‑time human approval for any request that matches a sensitive‑data pattern, preventing accidental exposure.
- hoop.dev blocks commands that are explicitly denied by policy, such as bulk extracts or DELETE operations on protected tables.
- hoop.dev makes the session available for replay, so incident responders can see exactly what the AI asked and received.
Because each of these outcomes is produced by the gateway itself, the organization gains concrete evidence for PHI‑handling compliance without having to trust the AI’s internal logging.
Getting started with PHI‑safe AI integration
Review the Getting started guide to deploy the gateway in your network. The documentation walks you through connecting a PostgreSQL database, configuring OIDC, and defining masking rules for PHI columns such as social security number or medical record number. For deeper insight into policy design, see the Learn section, which covers approval workflows, session replay, and best practices for limiting blast radius.
FAQ
How does hoop.dev prevent accidental PHI leakage?
hoop.dev sits in the data path and inspects each response before it leaves the target. It replaces or redacts any field that matches a PHI pattern, so even if the AI issues a broad SELECT, the returned payload never contains raw protected information.
Do I still need existing IAM policies?
Yes. The identity setup defines which AI identity can authenticate, but hoop.dev is required to enforce per‑request controls. Without the gateway, the IAM policy alone cannot guarantee that a permitted read does not include PHI.
Explore the source code and contribute to the project on GitHub.
