PII/PHI redaction for AI agents on Postgres

A support-automation agent queries a patient or customer table and the result set comes back full of names, dates of birth, and medical record numbers. The agent needed a status flag and a ticket ID. Everything else is regulated data now sitting in a model context and a log. PII/PHI redaction for AI agents on Postgres exists to stop that, by removing the regulated fields before the agent ever receives them.

This post explains redaction for agents on Postgres and where hoop.dev applies it.

What PII/PHI redaction means here

Redaction means personally identifiable information and protected health information in query results are replaced before they leave the database connection. The agent still receives a usable result, with non-regulated columns intact, but the protected values come back redacted rather than in cleartext. The goal is to keep regulated data out of the agent's data flow entirely.

Redaction belongs on the connection

Regulated columns can show up in any query, including ones nobody anticipated, and in free-text fields that hide identifiers inside prose. Redaction that depends on specific views or on the agent going through your application will miss those paths. The reliable place is the connection every result crosses, where redaction applies regardless of the query shape.

How hoop.dev redacts on Postgres

hoop.dev is an open-source Layer 7 access gateway. Its agent speaks the native Postgres wire protocol. As results stream back, hoop.dev sends content to a configured DLP provider, Microsoft Presidio or Google DLP, which classifies fields, and redacts the matches before the rows reach the AI agent. Classification is the provider's job, so detection covers structured columns and identifiers embedded in text, not just a fixed list.

Redaction as evidence for your compliance program

Frameworks that govern PII and PHI expect you to demonstrate that regulated data is not exposed beyond its purpose. Inline redaction at the connection, paired with recorded sessions attributed to identity, generates evidence you can show: which identity accessed which data, and that protected fields were redacted in transit. hoop.dev produces that evidence; it does not by itself make any system "compliant" or "certified," and you should not describe it that way. It supports the program; the framework attestation stays yours.

Where it sits in the connection

Setup mirrors any hoop.dev connection. Deploy the gateway, run its network-resident agent next to Postgres, register the connection, and configure a DLP provider so there is a classifier for the result stream. Then enable redaction for the entity types your data contains and route the agent through the hoop.dev endpoint. The getting started guide covers the install. Because redaction runs on the connection, it does not depend on the agent using a particular view or going through your application, which is exactly what you want when the consumer is an autonomous agent writing its own queries.

The result is that regulated fields never enter the agent's data flow. A name or a record number that would otherwise land in a prompt, a tool result, or a downstream store is redacted before the agent receives the row, so the surface area for an accidental disclosure shrinks to the columns you deliberately allow.

Pitfalls

• Redaction requires a configured DLP provider. Without Presidio or Google DLP there is no classifier and nothing is redacted.
• Free-text fields are where PHI hides. Classify narrative columns, not only structured identifiers.
• Redaction limits exposure in results; it is not access control. Scope which agents reach regulated tables at all.

FAQ

Does redaction change the stored data?

No. Postgres returns its real rows. hoop.dev redacts in the result stream before the agent receives them.

Does redaction make my system HIPAA compliant?

No. It generates evidence that supports your compliance program. Certification and attestation remain your responsibility under the relevant framework.

What detects PII and PHI in the results?

A configured DLP provider, Presidio or Google DLP, classifies the streaming content and hoop.dev redacts the matches.

Does redaction alone satisfy a regulatory requirement?

No single control does. Redaction reduces exposure and produces evidence you can show an auditor, but you still need access scoping, recorded sessions, and the framework's own attestation process. Treat redaction as one part of the program, not a checkbox that certifies it.

hoop.dev is open source. See how inline redaction works on a Postgres connection in the hoop.dev repository on GitHub, and read the masking model at hoop.dev/learn.