A note before I start. I am a founder writing about how I think about this problem. This is not legal advice, and the one legal position I mention below has not been reviewed by a lawyer yet.
What agents remember
When an agent works inside a hospital for a few weeks, it starts to keep things. Here is a synthetic example of the kind of memory a prior authorisation agent writes: "Payer X asked for 6 weeks of PT notes for lumbar MRI, 12 Oct." On its own that is a fact about a payer. Tie it to a patient, add a date of service or a diagnosis code, and it describes a person's care.
Corrections are the same. A nurse edits the agent's draft letter and the diff gets saved so the agent does better next time. That diff often quotes the patient's chart.
So the honest starting point is that agent memory can be PHI. Some of it will be. A design that assumes memory is harmless notes will be wrong on the first busy day.
The three places it can live
I see three options when I talk to agent vendors.
The first is inside the vendor's own cloud, next to the agent. This is the default for most products, and it is easy to build. It also means the vendor is storing PHI for every hospital it serves, and the hospital's security team has to review the vendor's storage, access and logging as if it were their own system.
The second is in the model provider's memory feature. That moves the question to a third party and usually gives the hospital less to inspect, with retention and access rules it did not write.
The third is inside the hospital's own cloud account, under the hospital's keys and policy. This is what Inhold is designed for. One install per end customer, in their account, with a tenant id on every row anyway. We are not in the data path, and the software sends us nothing.
What the third option buys
The reviewer gets things they can check themselves. The memory sits in a database in their account. The policy that decides reads is a JSON bundle their team owns. Every read and write is checked against it, on the actor, the purpose and the data label, and anything the bundle does not grant is denied. Every decision writes one audit row, allowed or denied, with the hash of the policy that made it.
It also changes who has to be trusted. If Inhold staff have no account in the install and no entry in the bundle, a reviewer does not need to trust our staff. They need to trust their own cloud admins, which they already do.
What it does not settle
Keeping memory in the hospital's account does not keep it there. The vendor's agent still receives whatever the policy lets it read. If that agent runs in the vendor's cloud, the data it reads leaves the hospital's account at that moment. Inhold controls what the agent may read under which purpose. It does not control where the agent runs or which model it calls. Inhold itself makes no model calls; the agent calls whatever model endpoint the vendor and the hospital agreed on.
It does not make labelling perfect either. Inhold labels PHI and PII at write time with local pattern detectors, for MRNs, dates of birth, ICD-10 codes, NPIs, member ids, SSNs, emails and phone numbers. Nothing is sent out to classify it. Patterns miss a name in a sentence, an address, and any value without its usual prefix. An optional local name model, loaded from disk, catches most names on our synthetic test sets and misses some. So I tell vendors not to rely on the tagger. Set a subject on every write about a patient, which makes the item PHI whatever the tagger finds, and give each purpose that handles patient data PHI as its default label.
And the install itself is not finished. v0 runs on one machine with SQLite and synthetic data from a made-up hospital, Contoso General Hospital. The AWS install, with Postgres in private subnets and encryption under the hospital's KMS key, is designed and in build. Until it ships, encryption at rest is whatever the host disk provides.
The business associate question
Vendors ask whether Inhold is a business associate under HIPAA. Our position is no for the software alone, because we never create, receive, keep or send PHI and have no access to the install. If support ever needed access to PHI, that would happen under a BAA.
That is our position, written down so a hospital's counsel can argue with it. A lawyer has not reviewed it yet. It is on our known gaps list, marked to close before the first pilot, and I will update this post when that review happens.
The vendor's own status does not change because Inhold exists. If the vendor's agent reads PHI, the vendor's agreements with the hospital still apply to that agent.
What a reviewer can see
Inhold exports an evidence pack: the audit export, the active policy bundle and its hash, chain verification, anchors, the threat model and a control map against 45 CFR 164.312 and the minimum necessary standard. The control map is a draft for a reviewer to read. I never describe it as a compliance claim, and it does not cover every specification in 164.312 yet.
Where I land
PHI that an agent writes should live where the hospital's existing controls already reach, under a policy the hospital wrote, with a log the hospital can check. The design is mine. Whether it meets a given hospital's obligations is for their counsel and their security team to judge, with the evidence in front of them.
The repo goes public on 9 November 2026 under Apache-2.0, so they can read the code as well as the claims.