Are Claude Code, Cursor, and Copilot HIPAA compliant?

Are Claude Code, Cursor, and Copilot HIPAA compliant?

No coding agent is HIPAA compliant on its own, because HIPAA applies to how your organization handles patient data, not to a product. Anthropic, Cursor, and OpenAI each offer a business associate agreement that covers named configurations of Claude Code, Cursor, and Codex. GitHub doesn't publish one for Copilot, and the GitHub Data Protection Agreement that covers Copilot bars you from providing PHI without GitHub's prior, written, and specific consent. A signed agreement covers the vendor's processing, not what the agent reads on a developer's laptop.

HIPAA has its own vocabulary, so it helps to define it before going further. Protected health information (PHI) is health information that can be linked to a specific person, such as a diagnosis next to a name or a lab result next to a medical record number. A covered entity is a health plan, a health care clearinghouse, or a health care provider that conducts transactions such as billing electronically. A business associate is a person or company that creates, receives, maintains, or transmits PHI on a covered entity's behalf, as defined in 45 CFR 160.103. A business associate agreement (BAA) is the contract that 45 CFR 164.504(e) requires between the two before PHI changes hands.

When a coding agent sends PHI to a model provider, that provider is receiving PHI on your behalf, so you need a BAA with it and you need to use the configuration that the BAA covers. This article also covers how PHI reaches a coding agent session and which controls keep it out. It's technical guidance, not legal advice, so confirm your obligations with your privacy officer or counsel.

Which AI coding assistants sign a BAA?

Anthropic, Cursor, and OpenAI publish BAA terms that cover specific surfaces of Claude Code, Cursor, and Codex. Each one limits coverage to a plan, a configuration, or both. GitHub's Copilot documentation places Copilot under the GitHub Data Protection Agreement, and that agreement bars customers from providing PHI without GitHub's prior, written, and specific consent. The following table lists what each vendor's own pages say.

The table was checked on November 6, 2026, against Anthropic's BAA article for commercial customers and its zero data retention article, Cursor's BAA documentation, GitHub's Data Protection Agreement and Copilot approval resources, Microsoft's HIPAA offering page, and OpenAI's HIPAA Implementation and Configuration Guide, posted July 9, 2026. Third-party sites disagree about Cursor and Copilot, and they aren't used here. Vendors revise these terms often, so ask your account team for the current version in writing before any PHI goes through a tool.

Two vendor details change how teams deploy. Anthropic's table marks Claude Code through an LLM gateway or a custom base URL as not covered, so routing traffic through a proxy for inspection can take you outside the BAA. And OpenAI's guide forbids PHI in Codex Cloud outright: "Customer may not upload, transmit, or process PHI using Codex Cloud."

What does a BAA cover for a coding agent?

A BAA covers what the vendor does with PHI after it reaches the vendor's service. It doesn't cover the developer's machine, the repositories the agent opens, the MCP servers it calls, or the tools it runs. Those stay your responsibility, and the HIPAA rules on access, minimum necessary use, and audit controls still apply to them.

OpenAI's guide says this plainly. It states that the BAA "does not apply to the execution of the Codex Local Client on Customer's client machines or to any Third-Party Services accessed by the Codex Local Client," and it makes the customer responsible for "establishing a managed configuration that meets their requirements for use with PHI." Anthropic's BAA article makes the same point about permission modes: "Covered means only that your BAA applies. Whether to allow a feature, such as bypass permissions mode, is your organization's decision."

The gap matters because of the minimum necessary standard in 45 CFR 164.502(b), which requires reasonable efforts to limit uses and disclosures of PHI to the minimum necessary for the purpose. A developer fixing a date-parsing bug doesn't need 40,000 real patient rows in the model's context. With a BAA in place, sending them to the provider may be a permitted disclosure. It's still more PHI than the task needs, and it now sits in a session transcript, a model provider's logs, and possibly a pull request.

How does PHI end up in a coding agent session?

PHI reaches a coding agent the same way it reaches any developer: through production data that ends up in a repository, a terminal, or a chat window. With a coding agent, everything it reads goes into the model's context and to the model provider. Most cases follow one of five routes.

A test fixture holds real rows. Someone exported a few hundred patients from the staging database three years ago to reproduce a bug, committed them as fixtures/patients.json, and nobody removed them. The agent reads the file when it writes a new test, and the names, dates of birth, and member IDs go into the session.

A database dump sits in the working tree. A developer restored a production backup locally to debug a migration, and the .sql file is still in the repository folder. An agent asked to "find where we store allergy codes" can search it with grep as readily as it searches the source.

A developer pastes a production log. An HL7 message or an API error that includes a patient's name and medical record number gets pasted into the prompt with "why does this fail?" The agent needs the stack trace, and it receives the record too.

An MCP server connects the agent to clinical data. MCP is a standard that lets an agent call tools that a separate server exposes. An MCP server wired to an electronic health record (EHR) or a FHIR API, the standard web interface for health records, can return a full patient record as a tool result. Anthropic's BAA article notes that data MCP servers and connectors send to third parties isn't covered under its BAA.

A developer pastes a patient record into the prompt. A support engineer copies a discharge summary into the chat to ask the agent why a field renders wrong. That's PHI in the most direct form, and the developer typed it.

How do you keep real PHI out of repositories?

Keep real patient data out of every repository and working directory that a coding agent can open, and replace it with synthetic data. This control removes the problem rather than detecting it, and it costs less than any detection tool you could buy.

Generate fixtures from a synthetic data generator instead of copying production rows. Where you need realistic records, de-identify them first with one of the two methods in 45 CFR 164.514(b): Safe Harbor, which removes 18 listed identifier classes, or expert determination. HHS's de-identification guidance explains both. Restore production backups to a separate location outside source folders, and delete them when the debugging is done.

Some of it will slip anyway. A fixture from before the policy existed, a dump in a sibling folder, and a log file in /tmp all sit within reach of an agent that runs as the developer. The following sections cover the controls that catch what the repository rules miss.

How do you stop a coding agent reading patient data files?

Deny the read before the file opens. Coding agents fire a hook before each tool call. A hook is a request the agent sends to an external service, and the answer decides whether the tool runs. A policy at that hook can match file paths and shell commands against the places where your patient data lives and refuse the call.

Arcjet coding agent hooks do this for Claude Code, GitHub Copilot, Cursor, OpenAI Codex, and Muse Code with one policy, decided from the hooks that the agents already fire. A policy in Arcjet is a set of rules written in Rego, the policy language of Open Policy Agent, and published from the Arcjet Console. The following policy adapts the coding-agent.credential-access starter, which denies tool calls and commands that name credential files such as .env files and SSH keys, to patient data paths. It reads the paths, command, and tool_kind inputs and runs with Execute on set to Tool call:

1
package arcjet.guard
2

3
import rego.v1
4

5
# Replace with the places your organization keeps patient data.
6
data_markers := {"fixtures/patients", "db/dumps/", "prod-logs/", ".hl7"}
7

8
deny contains "patient-data-path" if {
9
  some path in input.values.paths
10
  some marker in data_markers
11
  contains(path, marker)
12
}
13

14
deny contains "patient-data-command" if {
15
  input.values.tool_kind == "shell"
16
  some marker in data_markers
17
  contains(input.values.command, marker)
18
}

The first rule covers file tools, such as Claude Code's Read or the Copilot CLI's view, where the path arrives as a structured argument. The second covers shell commands such as cat db/dumps/prod.sql, where the path is part of the command text. Substring matching is coarse: it can't see a path built from variables, and it matches anything that contains a marker. Start the policy in dry run, a mode that records what a rule would deny without blocking anything, and tune the markers against your repositories. For the full approach, see how to stop coding agents reading secrets.

How do you screen developer prompts for PHI?

Run a sensitive information detector over each prompt before it reaches the model, and deny the prompt when the detector finds a PHI identifier. A detector is a check that a policy declares and reads the result of. In Arcjet, publish the coding-agent.sensitive-info starter and add the PHI entity types to its deny list.

The starter runs a server-side sensitive information detector with the ID pii over the prompt input, with Execute on set to Prompt. By default it denies card numbers and Social Security numbers. Add MEDICAL_RECORD_NUMBER, HEALTH_PLAN_BENEFICIARY_NUMBER, and the other PHI types, plus names, phone numbers, and email addresses if your policy calls for them. The Rego stays the same:

1
prompt_events := {"user-prompt-submit", "user-prompt-expansion", "user-prompt-transformed"}
2

3
deny contains "prompt-has-sensitive-info" if {
4
  input.values.event in prompt_events
5
  input.signals.sensitive_info.pii.detected
6
}

Identifiers with a fixed format, such as a device serial number or a vehicle identification number, are recognized from their structure. A medical record number or member ID looks like any short code, so Arcjet recognizes it from the surrounding text, such as MRN or Member ID next to the value. Arcjet detects identifiers. It doesn't decide whether the text around them is health information, and it doesn't redact or de-identify anything. A detector you already published stays on the entity list it was written against, so move it forward to pick up the PHI types. For the full list, see PHI detection.

Claude Code, Codex, Cursor, and Muse Code honor a prompt denial. Copilot drops hook output on its prompt event, so Arcjet records the decision and marks it as not enforced.

Can a hook block PHI in a tool result?

Not with Arcjet. Arcjet receives a tool result from a hook that runs after the tool has run, and its hooks don't replace or withhold that result, so the agent reads it. Some agents let a post-tool hook replace an MCP tool's output before the model reads it, and products such as Nightfall use that. Neither approach undoes the tool's side effect: the file was read and the query ran. What an Arcjet policy can do is screen the result as it arrives and restrict what the rest of the session can do.

That's what Arcjet session analysis does. It screens each tool result with the sensitive information detector, and when a result contains an entity type the policy denies, Arcjet sets the sensitive_data_exposure flag on the session. The coding-agent.session-analysis starter then refuses web and MCP calls, the calls that could send data out, until the flag is cleared or expires, while shell commands and file writes continue. You can add shell to that set. The starter's own sensitive information detector, pii, lists only card numbers and Social Security numbers, so add the PHI types to that detector's deny list for PHI in a tool result to set the flag. The approach is called session tainting.

Take the EHR case. The agent calls an MCP tool, and the result contains a patient's medical record number. Arcjet can't stop the agent reading that record. It flags the session, and the agent's next attempt to post to a web API or call another MCP server is denied. The agent can't set or clear the flag. A Console user who can edit the project clears it with a required reason, which goes to the audit log.

Session analysis has limits. It can't undo what happened before the flag was set, and some analysis runs in the background, so the agent can make more calls before the flag lands. The PHI has also already gone to the model provider, which is one more reason the BAA configuration in the first table matters. To narrow which MCP servers an agent can call at all, see how to restrict MCP servers for coding agents.

How do you stop developers removing the controls?

Install the hooks through each agent's managed settings, which an administrator deploys and a developer can't override without administrator access. A hook in a repository file or a user settings file is a pilot setup, because anyone with write access can delete it. Each agent has its own mechanism.

For Claude Code, deploy a managed settings file such as /etc/claude-code/managed-settings.json, or use server-managed settings in the claude.ai console, and add allowManagedHooksOnly if you want only your hooks to run. For Cursor, deploy hooks.json through MDM or use team hooks from the dashboard on the Enterprise plan. For Codex, put the hooks in requirements.toml with allow_managed_hooks_only = true. For the Copilot CLI, put the hook file in /etc/github-copilot/policy.d/, root-owned. The per-agent guides cover each install: Claude Code, Cursor, GitHub Copilot, and OpenAI Codex.

The vendor settings that a BAA depends on are administrator controls too. Cursor requires Privacy Mode locked organization-wide, and Anthropic's coverage depends on a HIPAA configuration that the organization's Primary Owner applies, or on zero data retention. Claude Code and Copilot HTTP hooks fail open on a timeout or network error, so the tool call goes ahead. The Arcjet wrapper for Codex, Cursor, and Muse Code fails closed.

Does Arcjet need a BAA too?

Yes, if prompts or tool results that carry PHI reach Arcjet. The hooks send prompts, tool call details, and tool results to Arcjet so that it can decide and screen them, which puts Arcjet in the same position as any other vendor that receives PHI on your behalf. Arcjet enters into a BAA with Enterprise-level customers whose use involves PHI, and both parties must sign it before any PHI is processed.

Arcjet supports HIPAA compliance and offers a HIPAA-compliant environment. Using it for PHI without a signed BAA may leave your organization out of compliance, the same as with any model provider. Arcjet holds a SOC 2 Type 2 report, available in the Arcjet Trust Center.

Know what Arcjet keeps. By default, it stores coding agent activity, including hook events, for 90 days. When the server-side detector flags a value in a policy input, Arcjet removes the value and keeps only the entity types and positions. With zero data retention, Arcjet keeps the decision structure, such as the conclusion, the rules that fired, and tool names, but not prompts, tool arguments, or input values. Even with zero data retention, session analysis keeps session data, such as prompts, tool call details, findings, and a screened tool-result excerpt, while the session is active and for up to 24 hours after, then deletes it. For details, see Arcjet privacy.

Detection has gaps. Of the Safe Harbor identifier classes, Arcjet doesn't detect dates related to a person or ages over 89, biometric identifiers, full-face photographs, or the catch-all class of other unique codes. It detects bank account numbers but not other account numbers, and driver's license numbers but not other license numbers. It relies on labels to find a medical record number in free text. Every decision is recorded in the Arcjet Console, which gives you activity records of the kind that 45 CFR 164.312(b) audit controls ask for, but a record isn't a compliance program. None of these controls make a coding agent HIPAA compliant. They reduce how much PHI reaches the agent and limit where it can go afterward. For the wider picture, see HIPAA compliance for AI agents.

To start, publish coding-agent.sensitive-info with the PHI types and coding-agent.session-analysis in dry run, read what they would have denied on the Activity page in the Arcjet Console, and then set them live.

Learn more: Coding agent policies · PHI detection · Session analysis