Business Associate Agreement for AI Agent Vendors

Why a business associate agreement for AI agent vendors needs new clauses

A standard BAA was written for a world of static systems: a billing vendor stores claims, a cloud host stores backups, a fax-to-EHR service moves documents from one place to another. Each of those vendors touches PHI in a way that is easy to describe in one sentence.

An AI agent vendor breaks that sentence. The agent does not just store PHI. It reads a chart, decides what matters, calls a tool with a piece of that record, and sometimes calls a second tool with the first tool's output. "We store your data securely" is not the risk anymore. "What did the agent do with it, and can you prove it" is.

So the agreement has to answer questions a 2015-era BAA template never asked. Does the agent's own working memory count as PHI storage? Who can revoke the agent's access mid-task? And what evidence exists after the fact that ties an action back to an authorized person or workflow?

What to ask before signing: the working-memory question

Start with where PHI actually sits once the agent is running, not where the vendor's architecture diagram says it should sit. The agent's session context, its transcript, or its intermediate reasoning steps may include patient data. If so, that context is now itself a PHI-holding system, subject to the same HIPAA Security Rule audit-control and access-control expectations as the database the data came from.

Ask plainly: where does that session context live once the agent has read the file? On the vendor's multi-tenant cloud, in a way you cannot audit directly? Or in an environment you control, where you can point to the exact server and database? The agreement should name this explicitly rather than leave it implied by a general "confidential information" clause written for a different kind of vendor.

This is exactly the gap DataShield Commander is built to close on the vendor side. Claude Code sessions and their transcripts write to a PostgreSQL database on the server you run: your own cloud, your own data center, or a dedicated single-tenant server operated for you. They never write to the vendor's own multi-tenant cloud. It can name a specific database on a specific server instead of gesturing at "our secure infrastructure."

Business associate agreement clauses for revocation and scope

The second question is about control while the agent is working, not just where its output lands. If you need to cut an agent's access right now, mid-task, does that actually happen on its next action, or does it happen whenever the token it holds expires?

This is not a hypothetical clause. It maps directly onto access-control language every BAA already has. An AI agent vendor should be able to answer it in one sentence, backed by an architecture you can inspect. DataShield Auth answers it this way. Every MCP tool call passes a scope ceiling, so a delegated token can never reach further than intended. A mid-session revocation re-check also runs on every governed call, so a suspended agent is downgraded on its very next action rather than at token expiry. The agreement is only as strong as the revocation story behind it, and "we'll revoke it within 24 hours" is not the same commitment as "the next call fails."

What to ask before signing: evidence you can check yourself

HIPAA's audit-control standard, 45 CFR 164.312(b), asks for mechanisms that record and examine activity in systems touching ePHI. For a human-operated system, a log file usually satisfies that. For an agent, the question sharpens: can the log be quietly edited after the fact by the same vendor whose behavior it is supposed to prove?

Ask for something you can verify independently, not a dashboard you have to trust. A SHA-256 hash-chained audit log with Ed25519-signed checkpoints, the pattern DataShield Auth runs, turns tampering, insertion, deletion and truncation into distinct, detectable verdicts rather than a single pass-or-fail check. Verify a sample chain yourself before you decide whether a vendor's evidence claim is marketing or mechanism.

Ask one more pointed question here: is PHI tokenized before the agent's context ever includes it? DataShield Ontology tokenizes datasets at ingest with a reversible HMAC scheme. The agent then works against tokens rather than raw identifiers, so a leaked transcript yields tokens instead of patient data. That is a second, independent layer behind the BAA's paperwork, and the agreement is stronger when it can point at a control like this rather than only a promise.

Where DataShield's own BAA stands, honestly

DataShield signs BAAs for dedicated single-tenant SaaS and self-hosted deployments. Healthcare deployments are a substantial part of why that data plane exists at all, not an afterthought bolted onto a generic product.

What we will not do is claim more than we have earned. DataShield's own SOC 2 Type II attestation is planned, not complete, and this post says so directly instead of hoping nobody asks. GDPR's pseudonymization guidance takes the same approach: it treats reversible tokenization as a named mitigation rather than a marketing flourish, precise about what it does and does not cover. Our answer to that gap is not "trust us anyway." It is an audit chain you can verify without an annual report: run the verification yourself against a real sample log. It should let you do the same thing with any vendor you are evaluating, not just us. If a vendor cannot let you check their evidence directly, ask why the BAA is the only proof on the table.

The short list for a vendor's AI agent BAA

Five questions, in the order to ask them. Where does the agent's working session, including its transcript, actually live, and is that named in the BAA? Can you cut the agent's access mid-task, and does the next call actually fail, or does the token just quietly expire later? Is PHI tokenized before the agent's context includes it, so a leaked transcript yields tokens rather than identifiers? Is the audit evidence something you can verify independently, or only something the vendor's own dashboard reports? And is the deployment model, self-hosted or single-tenant, one where a BAA actually applies, rather than a shared multi-tenant tier where the fine print quietly narrows what it covers?

An agreement that cannot answer these five in concrete, checkable terms is a template from an older kind of vendor with the word "agent" added to the first paragraph.

Bring this list to a vendor call before you bring the redline. Most of the actual risk in this kind of agreement gets caught in this conversation, not in the contract language. That is because the contract can only describe controls that already exist in the product.

Frequently asked questions