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, and 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 from a demo two years ago. None of that is unusual. It is just how repos actually 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. If that transcript sits on somebody else's server, you have just handed a third party a copy of data your BAA never mentioned and your risk analysis never listed.

So this starts with one plain question, asked before the first session: where does the session actually live once the agent has read the file? The honest answer for most coding-agent setups is 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, and the current update to that rule pulls AI tooling explicitly into your risk analysis. A Claude Code session that reads a patient record is now a system that touches ePHI, whether or not anyone planned for that when they installed the CLI.

This is where DataShield Commander draws a hard, boring line: sessions and transcripts are 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. Every logged session is indexed, searchable and archivable, so a security team can answer what the agent saw without asking 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 is table stakes. What a bank or hospital actually 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 delegated token can never grant more access than its owner intended, checked on every call, not just at login. Auth's dispatch pipeline runs a mid-session revocation re-check on every 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 is why a bank or hospital cannot govern this the way it would govern a coding agent 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.

Every one of those calls, allowed or denied, is sealed into a SHA-256 hash-chained audit log 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, because the honest answer here is narrower than the one for PHI. DataShield does not carry a PCI attestation, and payments tokenization is not our market. We say that plainly rather than let a sales page imply otherwise. If cardholder data is your primary exposure, a PCI-scoped vault built for that job, per the PCI Tokenization Product Security Guidelines, is the right tool.

What still applies to a bank running Claude Code is the same discipline 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, so joins across tables still work. The raw value never sits in the query path an agent reads from. Detokenization stays a privileged, 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 conversation about running Claude Code, so let's answer both without hedging. First, where do the keys live? In self-hosted and dedicated single-tenant deployments, the tokenization key and the audit-signing key are yours. They are held on your instance, as a secret you set or a key directory only the service reads. KMS or HSM custody is a built seam in Auth today, not a shipped integration, and this post will keep saying that until it ships.

Second, will DataShield sign a BAA? Yes, for dedicated single-tenant SaaS and self-hosted deployments. Healthcare and regulated-finance deployments are a large 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, and this post will not pretend otherwise. What we offer instead of an annual attestation is an audit chain you can check 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, and 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 cardholder fields and PHI fields tokenized before an agent ever reads them? Is a BAA on the table for the deployment model you actually chose?

Every one of those five questions has a concrete, checkable answer, and 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 requires slowing engineering down. It requires deciding, once, where the pieces live before the first real session runs, so that the deployment is a documented decision rather than a discovery your incident response team makes later.

Frequently asked questions