AI coding assistants in HIPAA-regulated teams

There is no such thing as a HIPAA-compliant code editor

Vendors advertise it anyway, which is why the phrase keeps circulating. In practice, compliance is a property of what an organisation does, not a badge a tool carries, and no editor can confer it on you.

The question that actually decides whether your engineering team can use an AI assistant is narrower and much easier to reason about: does the tool cause protected health information to be handed to somebody outside your organisation, and if so, is that somebody a party you have taken through the process you use for parties in that position.

That framing is useful because it converts an unanswerable question into a factual one about where data goes, which an engineer can verify rather than argue about.

Does your engineering environment touch PHI at all

Teams building healthcare software usually answer “production does, the repository does not”. That is the answer worth testing, because the ways it turns out to be wrong are boringly consistent.

• Fixtures and seed data from a real export. The classic. A de-identification that was done once, quickly, by somebody who has left.
• Bug reports with real payloads. A failing request body pasted into a test case or an issue, then committed so it can be reproduced.
• Integration recordings. Captured HL7 or FHIR messages, or cassettes recorded from a staging system that was fed real data.
• Logs attached to incidents, which is where identifiers and payload fragments usually survive longest.
• Developer machines connected to real systems, where the editor is open beside a terminal holding a live query result.

What a cloud assistant adds to the picture

If PHI can end up in a prompt and the prompt goes to a vendor, that vendor is now handling it on your behalf. Organisations in this position have a routine for that: a written agreement covering the handling, a security assessment, a place on a vendor register, and a periodic re-check because subprocessors change.

Some AI vendors will sign such an agreement, usually on their enterprise tiers and often not on the individual plans your developers already installed. That gap is where most of the risk in practice lives: the plan a developer signs up for personally is rarely the plan the agreement covers, and nobody finds out until an assessment asks.

With Onyx Code running locally, the prompt does not leave the workstation for the inference step, so there is no outside party to bring into that process for that step. What remains is the ordinary question of the workstation itself: who controls it, how it is secured, and who can read what is on it. That is a question your organisation already answers for every laptop it issues.

The controls a reviewer can verify, rather than take on trust

A note on the sanitizer, because it is easy to oversell: it is a safety net for the moment somebody attaches the wrong file, not a de-identification tool. It matches patterns. It will not reliably recognise a patient name in prose, and it should never be described to a reviewer as though it will.

A practical setup for a healthcare engineering team

None of this is a compliance programme. It is the tooling half, written so that the person who owns the programme has less to argue with.

• Commit an .onyxnoai to every repository that could hold real data, covering fixtures, recordings, captured messages and incident attachments. Because it is in the repository, it is reviewed like any other change rather than living in one person’s settings.
• Decide the position on bring-your-own-key deliberately. It is off by default. If cloud models are not acceptable for a given codebase, Air-Gap Mode makes that a property of the environment rather than a rule people are asked to remember.
• Add sanitizer patterns for your own identifier formats, such as internal record numbers, so the net catches the shapes specific to your systems.
• Export an Activity Log PDF during the evaluation, not at audit time. It shows the reviewer what evidence will look like before they have to ask for it.
• Keep the de-identification discipline you already have. A local model does not make a production export in a fixtures directory acceptable; it just means one fewer party sees it.

What you can put in front of a reviewer

Reviews in this sector end with a request for artefacts, usually at the least convenient moment.

Whatever the framework, a review comes down to the same two questions: what did the tool touch, and can you show it. Onyx Code answers both from the machine rather than from a vendor policy page.

• AI Activity Log. Every prompt, every file the AI read, every edit it proposed, with timestamps, recorded locally.
• Audit PDF export. The same record as a document you can hand to somebody who is never going to open your editor. This is usually the artefact that ends the conversation.
• .onyxnoai exclusion patterns. Gitignore-style paths no AI surface may read: not chat, not the index, not autocomplete, not agents. It lives in the repository, so it is reviewable in a pull request and it travels with the code.
• Prompt sanitizer. Every send and attachment is scanned locally for credentials, keys, tokens and certificates, with redaction offered before the prompt is built.
• Air-Gap Mode. A switch that blocks outbound traffic, enforced in three independent layers, with blocked attempts written to the log.
• No telemetry by default. Nothing to disable and nothing to negotiate.

All of the above are on the Free tier. Privacy and audit features are never behind the paywall, which also means a reviewer can evaluate every one of them before anybody spends money. The air-gapped development page covers the enforcement mechanisms in more depth, and the documentation gives the commands to verify them independently.

Questions

Is Onyx Code HIPAA compliant?

No tool is, including this one. Compliance describes an organisation’s practices. What can be stated factually is that in local mode inference happens on your machine, so using it does not hand data to us, and that Onyx Code provides exclusion patterns, a local prompt sanitizer, an air-gap switch and an exportable activity log that a reviewer can inspect.

Do we need an agreement with you to use it?

That is a judgement for your compliance function, and it depends on whether we receive anything. In local mode we do not receive prompts, code or telemetry. The Free tier has no account at all; a Pro licence involves an activation exchange with our licensing service, which is licence and device information rather than anything from your repository. Write to us and we will answer a questionnaire in writing.

Can we stop the AI reading our test fixtures?

Yes, with .onyxnoai patterns, which every AI surface honours including agents. It is committed to the repository, so it is reviewable in a pull request rather than depending on each developer configuring their editor correctly.

Does the prompt sanitizer remove PHI?

It is a pattern matcher aimed at credentials and secrets, with custom patterns you can add. Treat it as a safety net for a mis-attached file, not as de-identification, and do not present it to a reviewer as more than that.

What about developers who work from home?

The model runs on the laptop, so the tool behaves identically on a home network, on a plane or on a segmented office network. There is no dependency on reaching a service, which is usually the point that makes this workable for teams whose machines are managed but whose networks are not.