Signing the BAA
Request the BAA during onboarding or at contact@npclabs.org. We do not knowingly accept PHI onto hosted hardware without one.
It is a negotiated document reviewed by both sides, not a checkbox in a settings page. If PHI reaches a machine with no BAA in place, tell us: we will treat that as an incident.
You need one whenever a machine you own with us will create, receive, maintain, or transmit ePHI. HHS guidance on cloud computing treats a provider of “no-view” services (one that maintains ePHI it has no ability to decrypt) as a business associate. Encryption reduces the risk; it does not remove the relationship. Two cases fall outside it: a machine shipped to your own facility, which sits under your physical controls and never has us maintaining your ePHI, and a machine that never touches PHI.
On the ordinary hosted gateway, the routing edge and control plane can see prompt and completion content in memory, but do not store it. For private_transport jobs, B3IQ's routing layers relay ciphertext they cannot decrypt. The node operator can see content on both paths because the model must process it. Encrypted transport is not confidential execution. Read the privacy boundary.
What HIPAA actually asks of a vendor
Three concrete things: a signed Business Associate Agreement, safeguards that are in place, and a customer who has done their own risk analysis.
No government body certifies, endorses, or approves any product, vendor, or cloud service as HIPAA compliant. The Department of Health and Human Services runs no certification program, and neither does any accreditor on its behalf. Every “HIPAA certified” badge is either self-issued or sold by a private company whose seal carries no regulatory weight.
Why owned hardware clears a review faster
Owned hardware gives your reviewer a specific server and hosting arrangement to assess. The review still needs to cover who can access the machine, which workloads can run on it, and where request content is visible.
The machine is a serial number in a rack you can visit. Oregon: name it in your data-flow diagram, or come see it. If your policy will not allow that, take ship-to-you and put it in your own building.
Your customer key routes only to machines you own. That boundary is checked server-side on every request. It does not establish that all other workloads or operator access are excluded; confirm those separately before provisioning, as what the BAA covers sets out.
Setting up a machine for PHI
None of this is exotic, but the order matters.
Execute the BAA, and name the machines
Before provisioning, not after: the agreement lists the specific machines that may handle PHI.
Keep the machine in its dedicated mode
Dedicated is the default; leave it there. Earn mode is outside the BAA.
Turn on encryption at rest at build time
Your hardware, your OS image, your disk key: we do not want a copy. Ask during the build and we will set it up with you.
Decide who can reach the machine
Set fleet SSH keys once for your org, close the SSH lane on machines that do not need it, and approve each support grant yourself.
Encrypt the request body if the model is not enough
Use the
private_transportpath when your threat model includes us: the request is encrypted to your node’s transport key.Keep PHI inside the reviewed path
Before the first week, tell your team which surfaces sit outside it; the scope list below names them.
Do your own risk analysis
No vendor can do it for you, and it is the first thing an auditor asks for.
What the BAA covers, and what it does not
Coverage attaches to your machines and the path to them. It stops where the product deliberately involves somebody else’s hardware or somebody else’s traffic.
In scope under an executed BAA
- Your hosted machine. The specific server you own, in its rack in our Oregon facility, including physical security, power, networking, and the on-site engineering that maintains it.
- Routing to your own machines. Every key on your account reaches your machines and nothing else. This is not a setting you turn on: the router resolves your machine list server-side on each request, drops any machine id you do not own, and refuses the request outright if none of your machines can serve it. There is no shared pool to fall through to.
- Encrypted private jobs. The
private_transportpath, where the request body is encrypted to your node’s transport key and B3IQ relays ciphertext it holds no key for. - Usage metadata and receipts. Request identifiers, timestamps, model, machine, token counts, latency, and status: the records we keep to measure usage. They carry no prompt or completion text.
- Remote access to the machine. The per-machine SSH lane and any scoped, expiring support grant you approve for diagnostics.
Not in scope: keep PHI out of these
- B3IQ-directed workloads. A separate routing path exists for B3IQ-directed workloads, outside your BAA. Serving inference produces no per-request earnings. Customer-key scoping does not establish operational workload exclusivity: if your risk analysis requires all other workloads to be excluded, confirm that isolation with B3IQ before provisioning.
- Earn mode. Renting the machine out on external GPU marketplaces instead. It withdraws the machine from every B3IQ inference path (including your own keys), closes its SSH lane, and reboots it onto a separate encrypted volume for the renter. The renter has the machine, not us, and the earn volume cannot read your bare-metal disk.
- The hosted playground. The dashboard playground runs on your own machines, but it is a development tool, not part of your reviewed application path. Do not paste PHI into it.
- The GPU marketplace. Renting capacity from other operators, or listing yours to them, is multi-tenant by definition, so it is outside the BAA.
- b3iq.org itself. The marketing site, the analytics on it, and the “Book a call” form are ordinary web surfaces. Do not put patient information in a contact form.
Safeguards
- Technical
- Private jobs use an X25519 key exchange to the node’s transport key with AEAD encryption, and streaming responses bind a sequence number and final-frame flag into each frame’s authenticated data, so truncated, reordered, dropped, or replayed frames are detected.
- API keys and tokens are stored only as hashes.
- IP addresses and user agents appear in admin audit logs only as hashes, with the IP under a keyed HMAC.
- The per-machine SSH lane can be closed from the dashboard, which then refuses inbound SSH even where your fleet key is trusted elsewhere.
- Support grants are diagnostics-scoped, expiring, revocable, and are not authorized to reach raw prompt or output content.
- Physical
- The Oregon facility runs N+1 power, 24/7 on-site engineering, and physical security.
- The facility operator maintains its own physical-security and availability attestations, which we can provide during a security review.
- Managed Hosting insures the machine at replacement value while it is racked in our facility.
- Administrative
- Per-request metadata is deleted automatically after 90 days; aggregate counters derived from it identify no individual request.
- Stored private-job ciphertext is purged after about 30 days, leaving only a billing record behind.
- We do not train on your prompts or completions, we do not sell them, and no human reviews them.
- Everyone with access to B3IQ systems completes security awareness training.
- Our written security policy set is available on request.
Compliance and assurance
Our SOC 2 Type II audit is underway with A-LIGN. We expect the report in 2027. The full list, including our completed HECVAT, is on the Security page.
Incidents
Under an executed BAA we will report security incidents affecting your ePHI to you without unreasonable delay, and cooperate with your own breach-assessment obligations. Report anything you see to contact@npclabs.org; if it concerns a specific machine, include its identifier from the dashboard and nothing else. Do not send PHI in the report.
Contact
BAA requests, security questionnaires, and compliance questions go to the address below.
NPC Labs, Inc.1801 N. 16th AvePhoenix, Arizona 85007United Statescontact@npclabs.org