Why a business associate agreement for AI agent vendors needs new clauses
Someone wrote a standard BAA for 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 one easy sentence.
An AI agent vendor breaks that sentence. The agent does not just store PHI. It reads a chart. It decides what matters. It calls a tool with a piece of that record. Sometimes it 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 new questions. A 2015-era BAA template never asked them. Does the agent's own working memory count as PHI storage? Who can revoke the agent's access mid-task? What proof ties an action back to an allowed person or workflow?
What to ask before signing: the working-memory question
Start with where PHI actually sits once the agent runs. Not where the vendor's architecture diagram says it should sit. The agent's session context, its transcript, or its reasoning steps may include patient data. If so, that context is now a PHI-holding system too. It now faces the same HIPAA Security Rule rules. The same rules as the database it came from. Audit control. Access control. Both apply.
Ask plainly: where does that session context live once the agent has read the file? On the vendor's multi-tenant cloud, where you cannot audit it directly? Or in a setup you control? One where you can point to the exact server and database? The agreement should name this outright. Don't let it hide behind a general "confidential information" clause. That clause was built for a different kind of vendor.
DataShield Commander closes exactly this gap. Claude Code sessions and their transcripts write to a PostgreSQL database on the server you run. That means your own cloud. Or your own data center. Or a dedicated single-tenant server run for you. They never write to the vendor's own multi-tenant cloud. It can name one database on one server. No need to gesture at "our secure infrastructure."
Business associate agreement clauses for revocation and scope
The second question is about control while the agent works. Not just where its output lands. Say you need to cut an agent's access right now, mid-task. Does that happen on its next action? Or only when its token expires?
This is not a hypothetical clause. It maps straight onto access-control language each BAA already has, just sharper. An AI agent vendor should answer it in one sentence. Backed by an architecture you can inspect. DataShield Auth answers it this way. Each MCP tool call carries a scope ceiling. A passed-down token can never reach further than intended. A mid-session revocation check also runs on each governed call. A suspended agent gets downgraded on its very next action. Not at token expiry. The agreement is only as strong as the revocation story behind it. "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 asks for mechanisms that record and check activity touching ePHI (45 CFR 164.312(b)). For a human-operated system, a log file usually covers that. For an agent, the question gets sharper. Can the vendor quietly edit the log after the fact? The same vendor whose behavior it is meant to prove?
Ask for proof you can check on its own. Not a dashboard you just have to trust. DataShield Auth runs a SHA-256 hash-chained audit log with Ed25519-signed checkpoints. It flags tampering, insertion, deletion, and truncation as distinct, detectable verdicts. That beats a single pass-or-fail check. Verify a sample chain yourself. Decide for yourself if a vendor's proof claim is marketing or mechanism.
Ask one more pointed question: 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, not raw identifiers. A leaked transcript then yields tokens, not patient data. That is a second layer behind the BAA's paperwork, on top of it. The agreement is stronger when it can point at a control like this. Not just a promise.
Where DataShield's own BAA stands, honestly
DataShield signs BAAs for dedicated single-tenant SaaS and self-hosted deployments. Healthcare is a big part of why that data plane exists at all. Not an afterthought bolted onto a generic product.
We will not claim more than we have earned. Our SOC 2 Type II attestation is planned, not complete. This post says so directly. It does not hope nobody asks. GDPR's pseudonymization guidance takes the same approach. It treats reversible tokenization as a named fix, not a marketing flourish. It states plainly what it covers. And what it does not. Our answer to that gap is not "trust us anyway." It is an audit chain. Check it yourself. No annual report needed. Run the verification yourself against a real sample log. Try the same check with any vendor you are testing. Not just us. If a vendor won't let you check their proof directly, ask why. The BAA should not be the only proof on the table.
The short list for a vendor's AI agent BAA
Five questions, in order. Where does the agent's working session, transcript included, actually live? Is that named in the BAA? Can you cut the agent's access mid-task? Does the next call actually fail? Or does the token just quietly expire later? Is PHI tokenized before the agent's context includes it? A leaked transcript should yield tokens, not identifiers. Is the audit proof something you can check on its own? 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? Or is it a shared multi-tenant tier? One where the fine print quietly narrows what it covers?
An agreement that cannot answer these five, in plain terms, is a template. An older kind of vendor's template. Someone just added the word "agent" to the first paragraph.
Bring this list to a vendor call before you bring the redline. Most of the real risk gets caught in this conversation. Not in the contract language. The contract can only describe controls that already exist in the product.
- A business associate agreement must set up the permitted and required uses of protected health information by the business associate, and require appropriate safeguards to prevent unauthorized use or disclosure. - HHS.gov, Sample Business Associate Agreement Provisions
- The HIPAA Security Rule's audit control standard, 45 CFR 164.312(b), requires covered entities and business associates to implement hardware, software, or procedural mechanisms that record and examine activity in information systems containing electronic protected health information. - HHS.gov, HIPAA Security Rule
- GDPR's pseudonymization guidance treats reversible tokenization, where identifying fields are replaced with tokens recoverable only under controlled conditions, as a recognized risk-reduction technique distinct from irreversible anonymization. - European Data Protection Board, Opinion 28/2024
Claude Code for banks and hospitals
What changes when a Claude Code repo touches PHI or cardholder data. How transcript custody closes the gap.
2026 SOC 2 for agentsMachine identity audit evidence for SOC 2
What a SOC 2 auditor wants to see for non-human identities, mapped to CC6 and CC7. Where DataShield's own attestation stands.
2026 SOC 2 for agentsThe accountable human for autonomous agent actions
SOC 2 auditors now ask which human is accountable for an AI agent's action. The attribution gap, and how to close it.
2026BAAs for dedicated single-tenant SaaS and self-hosted deployments. Scope-ceiling MCP tokens, mid-session revocation, and a hash-chained audit log you can verify yourself.
Get a quote scoped to your deploymentFrequently asked questions
What must this kind of vendor agreement cover that a normal BAA does not?
It should name where the agent's working session and transcript live. It should say whether access can be revoked mid-task, not just at token expiry. And it should say whether you can check the audit proof yourself. Not just read it off the vendor's dashboard.
Does DataShield sign BAAs?
Yes, for dedicated single-tenant SaaS and self-hosted deployments. Healthcare is a big part of why that data plane exists. Our SOC 2 Type II attestation is planned, not yet complete. We say so directly.
Is a BAA enough on its own to make an AI agent vendor compliant?
No. A BAA is a contract control. It assigns responsibility. On its own, it does not prove PHI is tokenized before an agent sees it. It does not prove access gets cut at once. It does not prove the audit log can't be quietly edited. A BAA should point to those technical controls, not replace them.
Why does mid-session revocation matter for a business associate agreement?
Because an agent session can run for minutes or hours, not seconds. Say access can only be cut at token expiry. Not on the very next tool call. Then the BAA's access-control promise is weaker than it sounds. That stays true no matter how good the surrounding paperwork reads.