All posts

PHI for AI Agents: A Compliance Guide

When an AI‑driven clinical assistant reads patient records, organizations must prove that every query and response is captured in an immutable, tamper‑evident audit trail. Health‑care privacy rules require that any system handling protected health information (PHI) produce verifiable evidence of who accessed what data, when, and for what purpose. The evidence must be time‑stamped, linked to a strong identity, and immutable. In addition, any downstream transmission of PHI must be filtered so tha

Free White Paper

AI Compliance Frameworks: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

When an AI‑driven clinical assistant reads patient records, organizations must prove that every query and response is captured in an immutable, tamper‑evident audit trail.

Health‑care privacy rules require that any system handling protected health information (PHI) produce verifiable evidence of who accessed what data, when, and for what purpose. The evidence must be time‑stamped, linked to a strong identity, and immutable. In addition, any downstream transmission of PHI must be filtered so that only the minimum necessary data leaves the protected environment. Finally, privileged operations, such as bulk exports or schema changes, must receive explicit, documented approval before execution.

Why the data path matters

Many organizations deploy AI agents as background services that connect directly to databases using a shared service account. That account often carries broad read/write rights, and the connection bypasses any gateway that could inspect the payload. The result is a blind spot: the agent can retrieve or modify PHI without any audit record, and there is no mechanism to redact sensitive fields before they are returned to downstream models.

Even when teams introduce identity federation, issuing short‑lived tokens to the agent, the request still travels straight to the database. The token proves who is calling, but the enforcement point remains inside the database process, which cannot guarantee that every response is logged, masked, or routed through an approval workflow. The missing piece is a controlled data path where policy can be applied consistently, regardless of the caller’s identity.

Continue reading? Get the full guide.

AI Compliance Frameworks: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

A practical architecture for PHI compliance

hoop.dev acts as a Layer 7 gateway that sits between the AI agent and the protected resource. By positioning the gateway on the data path, hoop.dev becomes the only place where traffic can be inspected and controlled. It records each session, applies inline masking to PHI fields, and enforces just‑in‑time approval for high‑risk commands. Because the gateway holds the credential, the agent never sees the secret, eliminating credential leakage risk.

When an AI agent issues a query, hoop.dev validates the OIDC token, checks the agent’s group membership, and then decides whether the request is allowed. If the query matches a rule that requires masking, hoop.dev rewrites the response on the fly, redacting identifiers, dates, or any other PHI element defined in the policy. If the operation is classified as dangerous, such as a bulk delete, hoop.dev pauses the request and routes it to a human approver. The approval decision, along with the full request and response payloads, is stored in an audit log that provides a reliable, time‑stamped trail for auditors.

Because hoop.dev runs as a network‑resident agent, it can proxy connections to databases, Kubernetes clusters, SSH endpoints, and internal HTTP services. The same enforcement model works for any of those targets, meaning organizations do not need a separate solution for each protocol. The unified gateway simplifies evidence collection: a single log source contains every PHI‑related interaction across the entire stack.

To get started, teams can follow the getting‑started guide that walks through deploying the gateway, registering a database connection, and defining masking rules for PHI. The learn section provides deeper examples of approval workflows and session replay, which are essential for demonstrating compliance during audits.

FAQ

  • Does hoop.dev replace the need for database‑level logging? No. hoop.dev complements existing logs by providing a protocol‑aware view that captures every request and response, including masked data. It ensures that the audit trail is complete even when the underlying database does not log query results.
  • Can hoop.dev be used with existing AI agent deployments? Yes. The gateway works with standard client libraries, so an agent can point its connection string at the hoop.dev endpoint without code changes. The agent continues to use its usual credentials, but the gateway mediates the session.
  • What evidence does hoop.dev generate for PHI audits? hoop.dev produces immutable‑looking session logs, approval records, and masked response snapshots. Each entry includes the identity of the caller, timestamps, and the policy decision that was applied, satisfying the core requirements of PHI regulations.

Explore the open‑source repository to see how the gateway is built and to contribute your own compliance extensions: hoop.dev on GitHub.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts