The Short Answer
ibl.ai's agent PII filter detects thirteen entity types. Five match HIPAA Safe Harbor's eighteen identifiers cleanly, five partly, eight not at all. A filter is a control, not de-identification. On ibl.ai you own all the code and the data, so you read the rule, not a promise.
Two controls shipped for every agent on the platform in October 2026: PII filtering, which handles personal data before the model sees a message, and Incognito, which decides whether the conversation is written to chat history and memory at all.
This post does the thing the release notes do not. It maps the detector's thirteen categories onto the eighteen identifier classes in HIPAA's Safe Harbor method, and says plainly which ones are not covered.
Which HIPAA Safe Harbor identifiers does an entity-type PII detector actually cover?
HIPAA's Safe Harbor de-identification method, at 45 CFR 164.514(b)(2) and explained in HHS's de-identification guidance, names eighteen classes of identifier that must be removed before health information stops being protected health information.
ibl.ai's agent Privacy tab detects thirteen entity types: Person, Email, Phone, SSN, Credit Card, Location, Date / Time, Passport, Driver's License, IP Address, IBAN, Medical License and Bank Number. The two lists are not the same shape.
Here is the mapping, class by class.
| Safe Harbor identifier class | ibl.ai entity type | Coverage |
|---|---|---|
| (A) Names | Person | Covered |
| (B) Geographic subdivisions smaller than a State | Location | Partial — detects a place, does not apply the three-digit ZIP rule |
| (C) All elements of dates except year; all ages over 89 | Date / Time | Partial — detects a date, not an age expressed in prose |
| (D) Telephone numbers | Phone | Covered |
| (E) Fax numbers | Phone | Partial — caught by number format, no fax-specific type |
| (F) Electronic mail addresses | Covered | |
| (G) Social security numbers | SSN | Covered |
| (H) Medical record numbers | — | Not enumerated |
| (I) Health plan beneficiary numbers | — | Not enumerated |
| (J) Account numbers | Credit Card, IBAN, Bank Number | Partial — financial accounts only |
| (K) Certificate / license numbers | Passport, Driver's License, Medical License | Partial — three document types, not the class |
| (L) Vehicle identifiers and serial numbers | — | Not enumerated |
| (M) Device identifiers and serial numbers | — | Not enumerated |
| (N) Web URLs | — | Not enumerated |
| (O) Internet Protocol (IP) address numbers | IP Address | Covered |
| (P) Biometric identifiers | — | Not enumerated |
| (Q) Full face photographic images | — | Not enumerated — not a text entity |
| (R) Any other unique identifying number, characteristic, or code | — | Not enumerable by design |
The tally: five classes match a detector category cleanly, five match only partially, and eight have no counterpart at all.
That is not a criticism of the detector. It is the honest shape of every entity-type PII filter on the market, and it is the number a compliance reviewer needs before deciding what a filtered agent may be used for.
Why can't a PII detection filter deliver HIPAA Safe Harbor de-identification on its own?
Two sentences in the regulation decide it, and neither is about detection quality.
The first is the catch-all. Class (R) reads: "Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section" — paragraph (c) being the narrow allowance for a re-identification code.
A detector works from a fixed list of entity types. A rule written as "any other" cannot be reduced to a list, so no finite set of categories satisfies it.
The second is the condition attached to the whole method. Safe Harbor also requires that the covered entity "does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual."
That is a statement about the organization's knowledge, not about a filter's output. Software cannot hold or discharge it.
Two of the eighteen classes also need a transformation, not a deletion. Ages over 89 must be aggregated into "age 90 or older", and a ZIP code may be kept at three digits only where that three-digit area holds more than 20,000 people, per the Census.
Detecting a date and rewriting "94-year-old" to "90 or older" are different operations. The detector does the first.
So the accurate statement is narrow and still useful: ibl.ai's PII filter is a strong runtime control over what personal data reaches a model. It is not a de-identification certification, and we are not going to imply it is.
What should a healthcare team do about the eight identifier classes no detector enumerates?
Four things, in the order they actually get decided.
Decide per agent whether PHI is ever in scope. For agents that should never receive it, the right action is Block, not Redact — the message is rejected and your own wording is shown instead of a generic error. That turns a detection into a policy.
Narrow the entity list to the agent's job. An intake agent needs Person, Email, Phone and Date / Time. A finance-adjacent agent needs SSN, Credit Card, IBAN and Bank Number.
A narrow list produces fewer false positives on clinical prose, which is what makes staff stop pasting around the filter.
Turn on the outbound pass. The Also filter AI responses toggle runs the same detection over the agent's own output. Retrieval-augmented agents can surface an identifier the user never typed, and an inbound-only filter never sees it.
Keep de-identification in the pipeline, not the chat box. The eight unenumerated classes are medical record numbers, beneficiary numbers, vehicle identifiers, device serials, URLs, biometrics, photographs and the catch-all.
They belong to a data-engineering step upstream of the agent, or to an Expert Determination.
That split is the same one described in Why PII Redaction Breaks Enterprise AI — and What Fixes It: transformation before the model ever trains, runtime filtering for everything that arrives afterwards.
The workload tiering in Shadow AI in Healthcare is the other half — which workloads may leave the perimeter at all.
Who decides whether a healthcare AI conversation is written to chat history at all?
Four tiers do, and the resolution order is the interesting part. Incognito keeps a conversation out of chat history and memory; who may turn it on is answered across all four.
| Tier | Who sets it | What it answers |
|---|---|---|
| Agent policy | Agent administrator | Always Incognito, Never Incognito, or Users Decide |
| Organization gate | Organization administrator | Whether people may control chat privacy at all |
| This conversation | The person chatting | One chat, from the chat header |
| User default | Each person | Normal, Anonymized or Incognito, in their profile |
The resolved answer has three values — normal, anonymized and disabled, where disabled is Incognito. One platform endpoint resolves all four tiers and reports which tier decided and whether the result is locked.
That last field is what lets a chat header show an honest locked state instead of a toggle that silently does nothing. For a regulated deployment, a control that lies about being in effect is worse than no control.
One detail is worth a compliance reviewer's attention. A chat started in Incognito is created with no owner record at all, so the guarantee rests on a missing row rather than a flag someone can flip back. Each turn is still metered for usage.
The teaser wording for this release said conversations "leave no trace". The accurate claim is narrower: Incognito decides whether the message text reaches chat history and memory.
It is not a statement about your own infrastructure logs or backups — those are yours, which is the point.
How is a four-tier retention control different from a privacy setting in a model vendor's console?
Not by being possible where the alternative is impossible. As of October 2026 all four major model providers — Anthropic, OpenAI, Google and Microsoft — will sign a HIPAA business associate agreement for specific tiers, and several offer zero-retention endpoints.
Anyone telling you otherwise is selling something.
The difference is where the control lives and what kind of thing it is.
A retention setting in a vendor console is a contractual guarantee: you accept a term, and an auditor reads the agreement. A retention rule inside a deployment you run is an operational one: your own team reads the configuration, the resolver response and the absent history row.
Both can be true at once. Only the second is inspectable by the organization that carries the liability, and that is the whole of the claim we make. The limits of the contractual version are the subject of HIPAA-Compliant AI: Why a BAA Is Not Enough.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
What does a compliance review of agent-level privacy controls look like on ibl.ai?
It looks like reading configuration, which is the only reason this post can quote exact numbers.
With role-based access control enabled, seven fields on the Privacy tab carry independent permissions: the PII capability switch, the handling action, the block message, the entity list, the response filter, and the two Incognito flags.
A field someone may read but not write renders disabled rather than hidden, so a reviewer can see a policy they are not allowed to change. Members typically see Incognito read-only and no PII Filtering at all.
Both sub-tabs are documented in Agent Settings: Privacy and shipped in the iblai/vibe toolkit — PII filtering first in v1.2.0 on May 25, 2026, the current four-action build and the Incognito tiers in v2.12.0 on October 12, 2026.
The release detail is in Incognito and PII Filtering for Every Agent.
Agentic OS runs both controls today. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
Want to map these controls against your own HIPAA posture?
We will walk your privacy and security teams through the thirteen entity types, the eight Safe Harbor classes they do not cover, and the four tiers that decide retention — on infrastructure you own.