Claude Code for Banks and Hospitals

Why Claude Code for banks and hospitals is a different problem

A developer at a normal software shop can point Claude Code at a repo. And not think twice. A developer at a bank or a hospital cannot. Here is the plain reason why. Test fixtures grow real-looking fast. A support ticket gets pasted into a session for context. A seed script for the claims database still has three real patient names in it. Left over from a demo two years ago. None of that is odd. It is just how repos look, after a few years of real use.

Once an agent reads that content, the content does not stay in the terminal. It becomes part of a transcript. It may become part of a tool call. Say that transcript sits on somebody else's server. You have just handed a third party a copy of data. Data your BAA never mentioned. Data your risk analysis never listed.

So this starts with one plain question, asked before the first session. Where does the session live, once the agent has read the file? The honest answer for most coding-agent setups: wherever the vendor's cloud happens to put it. That answer stops working the moment PHI or cardholder data enters the picture.

The transcript is the new PHI boundary

The HIPAA Security Rule asks for audit controls over anything that touches ePHI. The current update to that rule pulls AI tooling right into your risk analysis. A Claude Code session that reads a patient record touches ePHI. It is now that kind of system. Whether anyone planned for that when they installed the CLI.

This is where DataShield Commander draws a hard line. Sessions and transcripts get written to a PostgreSQL database, on the server you run. Not to Anthropic's servers. Not to a personal Claude web account. And not to DataShield. The only thing that leaves the building is the API call to the model itself. The same call any Claude Code install makes. Each logged session is indexed, searchable, and archivable. A security team can then answer what the agent saw. No need to ask an outside vendor to check its own logs on your behalf.

That is not a compliance certificate. HIPAA does not certify products. It is the difference between a transcript you can produce for an auditor this afternoon. And one you would need a subpoena to get back.

Why this deployment needs per-call authorization

A capable coding model? Table stakes. What a bank or hospital needs to answer is narrower. When Claude Code calls an MCP tool: what stopped it from reading the wrong table? And what happens the instant somebody revokes it?

DataShield Auth issues MCP tool tokens as scope-ceiling tokens. A passed-down token can never grant more access than its owner intended. That gets checked on each call, not just at login. Auth's dispatch pipeline runs a mid-session revocation re-check on each governed tool call. Suspending an agent's access lands on its very next call. Not at the end of a session that might run for hours. That single design choice explains something. It is why a bank cannot govern this like it would a coding agent. Not one for an internal tools team. The blast radius of one wrong scope is a claim file or a patient chart. Not a typo on a marketing page.

Each one of those calls, allowed or denied, is sealed into an audit log. SHA-256 hash-chained, with Ed25519-signed checkpoints. That is the same construction the NIST Digital Identity Guidelines expect for high-assurance authenticator events. Verify a sample chain yourself rather than take a vendor's word for it.

What changes for card data specifically

Cardholder data deserves its own paragraph. The honest answer here is narrower than the one for PHI. DataShield does not carry a PCI attestation. Payments tokenization is not our market. We say that plainly, rather than let a sales page imply otherwise. Is card data your main exposure? Then a PCI-scoped vault, built for that job, is the right tool. Per the PCI Tokenization Product Security Guidelines.

One discipline still applies to a bank running Claude Code. The same one that protects PHI. Tokenize the value at ingest, so the repo holds a token, not sixteen digits. The agent then works against tokens. The same way it would work against any other de-identified field. DataShield Ontology tokenizes datasets at ingest, with a reversible HMAC scheme. Joins across tables still work. The raw value never sits in the query path an agent reads from. Detokenization stays a special, audited action. Gated the same way a break-glass grant is.

Keys, BAAs, and what we will not claim

Two things come up in almost every bank and hospital talk about running Claude Code. Let's answer both without hedging. First, where do the keys live? In self-hosted and dedicated single-tenant setups, the tokenization key and the audit-signing key are yours. They sit on your instance. As a secret you set, or a key directory only the service reads. KMS or HSM custody is a planned path in Auth today. Not a shipped integration. This post will keep saying that until it ships.

Second, will DataShield sign a BAA? Yes, for dedicated single-tenant SaaS and self-hosted setups. Healthcare and regulated-finance customers are a big part of why the self-hosted option exists at all.

Third, and nobody has to ask twice: is DataShield SOC 2 attested? Not yet. SOC 2 Type II is planned, not done. This post will not pretend otherwise. What we offer instead of an annual attestation: an audit chain. Check it yourself, on your own schedule, without waiting on us.

A checklist for running Claude Code at a bank or hospital

Before a bank or hospital runs its first Claude Code session against a real repo: walk through five questions. Where do transcripts land, and can you name the database? Does the agent's MCP access carry a scope ceiling? Is revocation checked on the next call, or only at re-login? Is there a hash-chained audit log a third party can verify without trusting the vendor's dashboard? Are card fields and PHI fields tokenized before an agent ever reads them? Is a BAA on the table for the deployment model you chose?

Each one of those five questions has a clear, checkable answer. That checkability is the real difference. Between Claude Code as a developer convenience. And Claude Code for banks and hospitals as a governed piece of regulated infrastructure. Read the Commander architecture or get a quote scoped to your deployment.

None of this needs slowing engineering down. It needs one thing: deciding, once, where the pieces live before the first real session runs. So the deployment is a documented call. Not a discovery your incident response team makes later.

Frequently asked questions