The HIPAA BA definition: 45 CFR § 160.103
The HIPAA Privacy Rule defines a "Business Associate" at 45 CFR § 160.103. The operative language is:
A person who… on behalf of a covered entity or an organized health care arrangement… creates, receives, maintains, or transmits protected health information.
Four verbs govern BA status: create, receive, maintain, or transmit. Any one of them is sufficient. The analysis turns on whether CloakAPI does any of these four things with PHI — not with data generally, but specifically with protected health information.
PHI is defined at 45 CFR § 160.103 as individually identifiable health information transmitted or maintained in any form or medium by a covered entity. The HIPAA Safe Harbour de-identification standard (45 CFR § 164.514(b)) specifies 18 categories of identifiers that, when removed or generalised, eliminate PHI status.
The structural argument
CloakAPI's client SDK runs inside your application boundary — before any data crosses a network to our infrastructure. The SDK identifies spans of text matching PHI patterns (names, dates, medical record numbers, device identifiers, geographic data finer than state, and so on — the full § 164.514(b) list) and replaces each span with a format-preserving placeholder token before the request is serialised and transmitted.
A request that starts as:
Patient John Smith (MRN 00423819), DOB 1971-03-14, presented
with chest pain at St. Mary's Hospital, Boston MA on 2026-04-10.Leaves your application boundary as something like:
Patient [NAME:a8f3] ([MRN:c9d2]), DOB [DATE:b1e7], presented
with chest pain at [ORG:d4f2], [GEO:e5c1] on [DATE:f6a3].The CloakAPI gateway receives the tokenised form. It never sees John Smith, 00423819, 1971-03-14, St. Mary's Hospital, or Boston MA. It sees opaque tokens with no information content.
Applying the four-verb test:
- Create PHI? The gateway does not generate health information. It proxies token streams.
- Receive PHI? The gateway receives placeholder tokens, not PHI.
- Maintain PHI? The gateway stores signed receipt envelopes recording metadata (model, token count, timestamp). Receipt envelopes contain no PHI fields.
- Transmit PHI? The gateway transmits the tokenised request to the AI provider and the tokenised response back to your application. PHI does not transit the gateway at any point.
If none of the four verbs applies, CloakAPI is not a Business Associate with respect to those requests. The covered entity remains responsible for what happens inside its own application boundary — including the SDK operation, the token mapping table, and the de-tokenisation step on the return path.
Counter-arguments and responses
"You transmit it — the tokenised form is still PHI"
This is the strongest counter-argument. The claim would be that placeholder tokens are themselves PHI because they link back to PHI through the token mapping table held by the covered entity.
The response: HIPAA de-identification under the Expert Determination method (45 CFR § 164.514(b)(1)) requires that the probability of re-identification is very small, not zero. The Safe Harbour method (§ 164.514(b)(2)) requires removal of all 18 categories of identifiers. CloakAPI's tokens satisfy the Safe Harbour requirement on their face — they contain none of the 18 categories. Whether the token mapping table creates a re-identification risk is a question about your application's data governance, not about the data that transits the CloakAPI gateway. The gateway cannot re-identify a token; only your application, which holds the mapping table, can.
This mirrors the logic courts and HHS have applied to keys held by a different party: if the gateway lacks the decryption key, it has not "received" the underlying data in a meaningful HIPAA sense. Here, the gateway lacks the mapping table — a functional equivalent.
"You maintain it — you keep receipts"
CloakAPI retains signed receipt envelopes. A receipt envelope records: req_id, tenant_id, ts, model, provider, token_in, token_out, latency_ms, and the chain hash. None of these fields are PHI fields. Token counts and latency are operational metadata, not health information.
The counter-counter-argument is that metadata could be used to infer PHI in aggregate. This is a legitimate concern for sufficiently detailed metadata; we do not dismiss it. Our response: receipt envelope fields are constrained to operational fields by the OpenReceipt specification. Adding PHI fields to receipts would require a specification change that we have deliberately foreclosed.
"Your SDK runs in the application — it's part of your service"
The SDK is a library that runs entirely within the covered entity's application process, on the covered entity's infrastructure. It is not a separate service, not a SaaS component, and not a subprocessor that CloakAPI operates. The covered entity controls the SDK runtime, the token mapping store, and the de-tokenisation keys. CloakAPI supplies the library but does not operate the PHI-side processing.
This is analogous to a covered entity using an open-source encryption library. The library vendor is not a BA simply because the covered entity uses their code to encrypt PHI before sending it to a storage provider.
"What if the SDK has a bug and leaks PHI?"
That is a bug in the covered entity's application, and the covered entity bears responsibility for it. SDK bugs that cause PHI to transit the gateway would be a breach reportable under 45 CFR § 164.410. We publish the SDK source code so covered entities can audit it. We also maintain a coordinated disclosure programme at security@cloakapi.io.
Why we still offer a BAA
Despite the structural argument above, CloakAPI offers a Business Associate Agreement to any customer who requests one. We do this for three reasons:
- Procurement simplicity. Healthcare compliance teams routinely require a BAA from every vendor with access to patient data systems, regardless of whether HIPAA technically mandates it. Declining to sign creates a procurement obstacle that serves no one.
- Belt-and-suspenders coverage. If our architectural analysis is wrong, or if a future HHS guidance shifts the boundaries of BA status, covered entities with a BAA retain HIPAA protections. The BAA is insurance against legal uncertainty.
- Data flow evolution. Your application's data flows may change. You may add a feature that sends different data through the gateway. A BAA in place means you do not need to re-evaluate BA status every time your integration evolves.
Our BAA is available at /legal/baa.html. It is a standard Omnibus Rule-compliant BAA. If you need a redlined version, request one at hello@cloakapi.io.
Practical checklist for healthcare customers
- Verify that your integration uses the CloakAPI SDK (not a direct proxy) so tokenisation occurs in your application boundary before PHI transits the network.
- Audit the SDK's PHI entity types against your specific PHI — ensure all 18 § 164.514(b)(2) identifier categories that appear in your data are covered by SDK entity detectors.
- Store the token mapping table in your HIPAA-compliant data store, not in a third-party system. The mapping table is PHI by association.
- Enable receipt export and run offline chain verification periodically. This gives you an independent audit trail that does not depend on CloakAPI's systems.
- Sign a BAA with CloakAPI if your procurement process requires it, or if your counsel advises it.
- Review your Business Associate Agreements with downstream AI providers (OpenAI, Anthropic, etc.) separately — CloakAPI's BA status does not affect theirs.
- Document your de-identification methodology as required by 45 CFR § 164.514(b). Your risk analysis should address the token mapping table and re-identification risk.
The downstream AI provider question
Even if CloakAPI is not a BA, the AI provider receiving the tokenised request may be. If the AI provider receives data that could be re-identified by a party with access to the mapping table, a conservative reading of HIPAA may treat the AI provider as receiving PHI. This analysis depends on the specific AI provider, their data handling commitments, and HHS guidance that remains unsettled as of 2026.
You choose which provider a request is routed to, and each provider has its own HIPAA posture and — where it offers one — its own BAA to evaluate. Because you control provider selection (and, with BYOK, the contractual relationship), you can direct PHI-adjacent traffic only to providers whose terms your counsel accepts. Our current sub-processor list is on the Trust Center.
Honest summary
The structural argument is sound, and we believe it is correct. But "we believe it is correct" is not the same as "HHS has confirmed it" or "a court has upheld it." HIPAA enforcement is fact-specific and guidance on AI-gateway architectures has not yet been formally issued. The safe posture is: implement the tokenisation architecture (which protects your patients regardless of the legal analysis), sign a BAA, document your de-identification methodology, and have qualified counsel review your specific data flows.