Your Agency's New AI Agent Never Signed a HIPAA BAA

What actually launched on May 13, 2026

Anthropic announced Claude for Small Business on May 13, 2026². The pitch is simple and, for an agency owner drowning in renewal season admin, genuinely appealing: fifteen ready-to-run agentic workflows and fifteen skills, wired straight into the tools a small business already runs on. QuickBooks for payroll planning and monthly close. PayPal for invoicing and disputes. HubSpot for lead triage and campaign attribution. Docusign for contract signatures. Google Workspace and Microsoft 365 for the inbox and the files².

The mechanism is a toggle, not a build. Anthropic's own words on the announcement page: "Toggle on Claude for Small Business inside Claude Cowork, connect the tools you already use, and pick the job"². That "inside Claude Cowork" phrase is not marketing filler. It is the exact detail that matters for anyone running a Medicare, ACA, or group health book, and almost nobody reads that far into a product announcement before flipping the switch.

Once connected, the agent works the way you would expect an assistant to work. It reads what is already in HubSpot or Drive, drafts the follow-up, chases the invoice, reconciles the books. Anthropic states that existing permissions carry over: "Your existing permissions hold. If an employee can't see something in QuickBooks or Drive today, they can't see it through Claude"². That is a real access control, and it is a reasonable one. It says nothing about what happens to the data once Claude can see it, which is a separate question from who can ask Claude to look.

A worked example: one renewal-season afternoon

The abstract version of this story is easy to skip past. The concrete version is what actually happens on a Tuesday in October. A two-producer ACA agency has connected Claude for Small Business to its HubSpot pipeline and its shared Google Workspace inbox, because renewal season is buried in email and the fifteen ready-made workflows genuinely save time on the parts that are not client-specific.

One of the producers asks the connected agent to draft a batch of renewal check-in emails for clients whose plans are changing for the next plan year. To write a useful email, the agent has to read the HubSpot deal record for each client, which is exactly where the notes live: which metal tier they are on, a note from March about a medication that drives their formulary needs, the household income figure used to estimate their subsidy. None of that was typed into Claude directly. It was already sitting in HubSpot, and the connector's whole job is to read what is already there and act on it².

Nothing about that afternoon looks reckless from inside the agency. The producer used the tool exactly the way Anthropic's own announcement describes it being used. The gap is not a mistake in judgment. It is that the surface doing the reading, Claude Cowork, is on the exclusion list in Anthropic's own BAA documentation, and the connector carrying the HubSpot data into it is excluded a second time, separately, for sending data to a third party¹. The email got written well. The compliance question underneath it was never asked.

Why the product it runs inside isn't covered

Anthropic will sign a Business Associate Agreement. That is true, and it is the sentence most coverage of Claude and HIPAA stops at. What gets left out is which specific surfaces that agreement actually reaches. According to Anthropic's own commercial BAA documentation, coverage extends to two places: the Claude API, once an organization's Primary Owner signs the BAA and works with Anthropic's sales team to enable it, and Claude Enterprise plans, once HIPAA compliance is explicitly activated in organization settings and the BAA is accepted there¹. Claude Code is covered only in specific modes with zero data retention enabled¹.

Then comes the exclusion list, and it names the product at the center of this article directly. The documentation states the BAA "excludes features such as Claude Console, Claude Cowork, or features currently in beta such as Claude in Office, Claude Design, Claude Slides, and Claude Docs"¹. Claude for Small Business runs inside Claude Cowork, by Anthropic's own description of how it works². It is not covered by the same document that says Anthropic will sign a BAA, because the specific surface it runs on is one of the named exceptions.

The connector piece closes the loop. Even where a plan otherwise qualifies, Anthropic's documentation states that "sending data to 3rd parties via this feature isn't covered under Anthropic's BAA"¹, referring to connector and Enterprise Search features. Claude for Small Business's entire value proposition is connectors: QuickBooks, HubSpot, Google Workspace, all wired in so the agent can read and act on what is already there². Two separate exclusions in the same document both point at the same product, from two different directions.

As of the date this article was fetched and verified, September 20, 2026, the Claude for Small Business announcement page itself does not use the word HIPAA once². It talks about permissions, about not training on your data by default on Team and Enterprise plans, and about a Trust Center for more detail. It never tells a small business owner that the specific surface being sold to them is one of the named carve-outs in Anthropic's own BAA policy. You have to read a second, separate support document to find that out, and almost no one does before connecting their CRM.

It is worth being precise about what "covered" even requires, because the bar is higher than checking a box in a settings menu. On the Claude Enterprise side, the documentation is specific: the organization's Primary Owner has to activate HIPAA compliance in the "Data and privacy" section of organization settings and separately accept Anthropic's BAA there before anything is covered¹. On the API side, covered models require a minimum 30-day data retention window and are explicitly not available with zero data retention enabled¹, which is the opposite of how a privacy-minded team usually wants a vendor to handle sensitive data, and a detail almost no one expects walking in. Compliance coverage and data minimization are not the same goal, and HIPAA's business associate framework optimizes for the first one.

That distinction matters because it means simply picking the version of a product marketed as more secure is not, on its own, enough. An agency has to know which specific setting to turn on, who at the organization is authorized to turn it on, and what retention behavior comes attached to it, before any of the coverage applies. Claude for Small Business skips all three of those steps by design, because skipping them is what makes it a toggle instead of an onboarding project.

What actually makes an AI tool a business associate

None of this hinges on what Anthropic decides to call a product. HIPAA defines the term separately, at 45 CFR 160.103, and the definition does not care whether a vendor signed anything. A business associate is a person or entity that, on behalf of a covered entity, "creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter," including claims processing, data analysis, billing, benefit management, and practice management³.

Read that against what an AI agent connected to a CRM actually does on a Medicare or ACA book. Reading a HubSpot note that mentions a client's plan choice or a health condition is receiving protected health information. Drafting the renewal follow-up is practice management. Reconciling premium records in QuickBooks against client accounts is billing. Every one of those is on the regulation's own list, and none of them requires the AI vendor's agreement to trigger the status. A vendor that never signs a BAA does not stop being a business associate under the law. It just means the agency using it has no contractual protection while the disclosure happens anyway.

This is the part most agency owners get backwards. The question is not "did I sign something that makes this legal." The question is "does this tool's actual behavior meet the regulation's definition," and if the answer is yes, an agency disclosing PHI to that tool without a BAA is the one out of compliance, not just the vendor. The vendor's exclusion list in the last section tells you exactly which surfaces to keep client health information away from. It does not change whether the underlying legal obligation exists.

The regulation extends one layer further than most agency owners expect, and it is worth naming because it covers the exact category of vendor this article is about. Beyond the health-plan functions above, the definition also reaches parties providing "legal, actuarial, accounting, consulting, data aggregation... management, [and] administrative" services where doing so involves disclosure of protected health information³. An AI agent managing pipeline administration on a Medicare book is squarely inside that broader category too, not just the narrower claims-and-billing list. There is very little daylight in the regulation's own language for treating a connected AI agent as somehow outside its scope.

This isn't only an Anthropic problem

Anthropic is the one with a clear, dated, publicly fetchable exclusion list right now, which is why this article uses it as the worked example. The underlying pattern is not specific to one vendor. Every AI company selling agentic tools into small businesses this year is drawing the same line somewhere: a fast, self-service surface built for general office work, and a separate, contract-gated surface built for regulated data, usually reached through a sales call rather than a toggle. The self-service surface is the one getting marketed to small business owners in 2026. The contract-gated surface is the one that actually covers protected health information.

The fix is the same regardless of which vendor an agency is looking at: never assume a general-purpose "connect your business tools" feature covers health information just because the vendor also sells a version that does. Go find that vendor's own compliance or trust documentation, specifically, and check whether the exact feature being turned on is named as covered or excluded. Marketing pages sell the integration. Compliance documentation states the boundary. They are usually not the same page, and reading only the first one is how this gap opens.

There is a reason this split exists at every vendor rather than at just one. Building a connector that reads and writes across QuickBooks, HubSpot, and a shared inbox with almost no setup friction is what makes a small-business product sell itself. Building the audit trail, the access logging, the contractual breach-reporting obligations, and the retention controls a BAA requires is slower, and it usually shows up as a separate sales-managed tier because it has to be configured deliberately rather than toggled. Agencies buying the fast version are, by construction, buying the version that skipped the second list of work. That is not a flaw in any one product. It is what "self-service" and "regulated data" trade off against each other, at every vendor building both.

What connecting the wrong surface actually costs

Two numbers, from two different places, describe why this gap matters in practice rather than in theory. The first is about how few agencies would even catch it. The second is about what it costs when a business, in any industry, gets this kind of data handling wrong.

The 2026 Big "I" Agents Council for Technology Tech Trends Report, a national survey of independent agents, carriers, and technology providers published February 18, 2026, found that 56 percent of agencies have no written AI use policy or guidance at all⁴. That is not a statistic about AI capability. It is a statistic about oversight. In an agency with no written policy, nobody has a defined job of checking a new AI feature's compliance documentation before an employee connects it to the CRM. The toggle gets flipped because it looked useful, not because anyone signed off on where the data goes.

IBM's 2026 Cost of a Data Breach Report puts the global average cost of a data breach at $4.99 million, a 12 percent increase over the prior year's figure⁵. That number spans every industry IBM tracks, not insurance specifically, and it would be dishonest to present it as an insurance-agency figure. What it does establish, with a real number rather than a guess, is the direction breach costs are moving industry-wide while more businesses connect more AI tools to more of their live systems. A CRM holding Medicare or ACA client health details, wired into a connector that the vendor's own documentation says its compliance agreement does not reach, is exactly the kind of exposure that shows up in next year's version of that same report.

Put those two numbers side by side and the shape of the problem is plain. Most agencies have no process to catch this. When something built on an uncovered surface goes wrong, in any industry, the average cost is climbing, not falling. Neither number requires a hypothetical breach at your specific agency to matter. They describe the conditions the gap opens under.

There is also a cost that shows up before any breach ever happens. A carrier that discovers an agent routed Medicare or ACA client data through an AI connector with no BAA behind it can treat that as a contract violation independent of anything HHS OCR does. Most carrier agreements require an agent to control who and what handles plan and health information on the carrier's behalf, and "an AI tool I connected because it looked useful" is not an answer that satisfies that obligation. Losing an appointment over a settings toggle, rather than over how well a plan was sold, is a genuinely avoidable outcome, and it is the more likely first consequence for most agencies, well before a headline-scale breach ever enters the picture.

How to check what your own connectors are doing

You do not need a compliance department to run this check, and most of it takes an afternoon rather than a project.

List every AI tool with a live connector into a system that holds client data. CRM, email, calendar, a quoting tool, anything an agent can read from or write to automatically. If it is not on a written list, nobody can audit it later.

For each one, find the vendor's own HIPAA or compliance documentation, not the product page. Search the vendor's site for "business associate agreement" or "HIPAA" specifically. If the product's own marketing page never uses either phrase, that silence is itself the answer: the surface you are using was not built with PHI in mind.

Check whether the exact feature is named, not just the plan tier. As this article shows, a vendor can offer a covered plan overall while excluding the specific connector or workspace feature you are actually using. Read for the feature name, not the plan name.

Segregate by data type before you segregate by tool. An AI connector wired to draft marketing copy, schedule a general callback, or manage a life-only pipeline is a different risk profile than one reading a Medicare client's plan notes. Where possible, keep the AI agent on the non-PHI half of the workflow and route anything touching real health information through a covered surface, or none at all until it is covered.

Write the policy down, even a short one. A one-page AI use policy that names which tools are approved for which data, and who checks a new tool's compliance documentation before it gets connected, closes most of the gap the 56 percent figure describes. It does not need to be complicated to be real.

Re-run the check every time a tool adds a feature, not just when you first connect it. Anthropic's own exclusion list separates Claude Cowork from Claude Enterprise today. Vendors change what is covered as products mature, sometimes expanding coverage and sometimes narrowing it around a new beta feature. A tool that was fine to connect in the spring is worth re-checking before it becomes the thing an employee builds a new workflow around in the fall.

None of these five steps requires new software or a developer. The hardest part is usually the first one, listing every connector honestly, because doing that inventory tends to surface tools an owner forgot a producer had turned on months earlier. Once the list exists, checking each vendor's own compliance page against it is genuinely a one-afternoon task, not a project that needs to wait for a slower quarter.

How we build this instead

Our own custom builds route anything touching real client data through Ambrose first, which masks protected health information before it reaches any AI model that has not signed a Business Associate Agreement, then restores the real record for the person who actually needs to see it⁶. That keeps the compliance boundary at the infrastructure layer, decided once by the people who built it, instead of depending on every connector's fine print staying current and every employee reading a second support document before flipping a toggle.

Custom AI agents and automations, including this kind of PHI-aware architecture, are scoped and priced on a call rather than sold as one fixed package⁶, because what a Medicare-heavy agency needs gated looks different from what a life-only agency needs at all. The build runs on your own accounts, your own domain, and your own CRM, so the automation keeps working whether or not you keep working with us, and the AI layer never has to be the thing standing between your data and a vendor's exclusion list.

The point is not that a general-purpose AI connector is bad technology. Claude for Small Business does what it says it does, for the businesses and the data it was actually built to touch. The point is that a Medicare or ACA book is not that data, and the fix is architectural, not a settings toggle: keep the PHI-touching work behind a boundary that was built for it, and let the general-purpose tools handle everything else.

In practice that split looks less dramatic than it sounds. A renewal follow-up workflow can still draft language, still chase a signature through Docusign, still update a pipeline stage, with the client's plan detail and health note held on the masked side of the boundary the whole time and only revealed to the person actually authorized to see it. The producer's day looks the same. The AI still does the drafting and the chasing. What changes is which side of the BAA boundary the raw health information ever crosses, and that difference is exactly the one Anthropic's own exclusion list is drawing, just moved to a place an agency controls instead of a place a connector's default settings decide.

What you get

Concretely, an agency that works through this gets a documented answer to a question almost nobody asks until a carrier audit or a breach forces it: which specific AI surfaces touch client health information, and which of those surfaces the vendor's own compliance documentation actually names as covered. It gets an architecture where the masking happens once, at the infrastructure layer, instead of depending on every new connector a team gets excited about. And it gets to keep using AI to save real hours on renewal follow-up, database work, and quoting, on a build the agency owns rather than a toggle inside someone else's small-business product.

When this isn't your problem

If your book is entirely life insurance, final expense, or property and casualty, with no Medicare, ACA, or group health business, the HIPAA mechanism in this article does not apply, because there is no protected health information for an AI connector to touch in the first place. Connecting Claude for Small Business or a similar tool to a life-only CRM is a data-security and contract question, not a HIPAA one, though the NAIC's Insurance Data Security Model Law's third-party due diligence duty may still apply depending on your state. If your agency writes Medicare, ACA, or group health business and has never connected an AI agent to a system holding client health details at all, this article describes a risk to check for before it becomes one, not a problem you already have.

Questions agents ask