Routing CrewAI LLM Calls Only to BAA-Covered Models for HIPAA

What a BAA covers and what code can verify

Under 45 CFR 164.502(e), a covered entity may disclose PHI to a business associate only if it obtains satisfactory assurance that the business associate will appropriately safeguard the information. For ePHI, the Security Rule applies the same condition, with assurances obtained in accordance with 164.314(a). HHS states that these assurances must be in writing, as a contract or other agreement. As of November 2026, the current eCFR text reflects these requirements.

The practical consequence is that coverage attaches to a contracted provider and the services described in the agreement. The HHS model BAA, for example, permits use or disclosure of PHI as reasonably necessary to provide the services described in the agreement. A model name such as a well-known model family does not establish coverage. The same model can be offered through different providers, services, and endpoints under different contract terms.

This separates two questions. Legal and compliance teams decide which provider services an executed BAA covers. Engineering decides how to make sure PHI only reaches those services. Configuration conventions answer the second question only for the calls someone remembered to configure.

Where model restrictions fail in multi-agent workflows

Multi-agent frameworks such as CrewAI let individual agents specify or default to different providers and models through configuration, environment variables, or code. Each of those is a place where a model choice can differ from what the security team approved. NIST material on agentic systems notes that agents dynamically choose extensions and make repeated LLM calls, using earlier outputs to guide later actions. The full set of calls therefore cannot be known from static configuration.

Three failure points deserve explicit review. The first is agent-level model settings, where one agent is pointed at a different provider than the rest of the crew. The second is tool-invoked calls, where a tool makes its own model request outside the path you inspected. The third is default and fallback models, where a missing setting or a provider error causes a request to land on a model nobody listed.

A static allowlist in application code covers only the paths that code controls. A post-hoc review can find a violation after PHI has already been sent, and it cannot show that every call stayed within covered models. Both leave a HIPAA exposure and a gap in audit evidence. The control has to sit where the request is made.

Define the allowlist from executed BAAs

Build the allowlist from the agreements you have signed, not from the models developers want to use. Each entry should be specific enough that a reviewer can trace it to contract language.

• Provider and service: Record the contracted provider and the specific service named in the BAA. Do not infer coverage from general availability.
• Endpoint and region: List the exact endpoints and regions you intend to call. Confirm eligible services, regions, and retention conditions in the provider's current BAA documentation.
• Model identifiers: Add the model identifiers permitted on each endpoint. Treat any model not explicitly listed, including defaults and fallbacks, as non-conforming until reviewed.
• Contract reference: Store a reference to the written BAA beside each entry, so the agreement and the entries it supports are kept together.
• Owner and version: Assign an owner, require approval for changes, and version the list so each call can be tied to the policy in force at that time.

Governance, tradeoffs, and where Trussed fits

Enforcement does not replace governance work. Section 164.308(a) requires a risk analysis of risks to ePHI and periodic evaluation in response to environmental or operational changes, so LLM routing belongs in both. Re-run the allowlist review whenever models, providers, or endpoints change. Name an owner for the BAA inventory, and decide how the organization's sanction policy applies to developers who bypass the routing policy. Also confirm separately how the LLM provider is contracted, since the covered entity's assurance requirement does not extend directly to subcontractor business associates. Provider commitments such as no-training terms should be confirmed contractually, and the FTC has said companies that fail to honor such privacy commitments may face liability.

There are tradeoffs. A strict allowlist will block calls that developers expect to work, and escalation needs a reviewer who can respond. Blocking by default is the safer starting point, and escalation paths can be added once the volume of exceptions is understood.

Trussed is one way to implement this pattern. It enforces policy in the execution path across models, agents, and tools, with allow, redact, block, rate limit, and escalate decisions on individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it produces audit-ready evidence mapped to HIPAA. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Trussed runs in production with healthcare organizations. The approach above works with any enforcement point that sits in the call path and records each decision.