The Short Answer
The biggest risk in healthcare AI is an agent reaching systems it never needed, not a wrong answer. Scoping each agent's tools to its job is the HIPAA access-control rule applied to software, and on ibl.ai you own all the code and the data, so those scopes run inside your own perimeter.
ibl.ai shipped per-agent and per-chat MCP connector switches in iblai/vibe v2.20.0 on November 3, 2026. The HIPAA Security Rule's access-control standard is 45 CFR 164.312(a)(1).
Why is access a bigger risk than accuracy for healthcare AI agents?
A wrong answer from a healthcare AI agent is visible: a clinician reads it and can reject it. Wrong access is invisible. A radiology agent that can also query billing, or a patient chatbot that can read a prescribing database, exposes data whether or not any answer is wrong.
The exposure also compounds. Every agent a health system adds, intake, coding, prior authorization, patient education, multiplies the systems an agent could touch if tool access is all or nothing.
The HIPAA Security Rule already covers the case. Section 164.312(a)(1) requires access to electronic PHI only by "those persons or software programs that have been granted access rights." An AI agent calling a tool is a software program.
What does HIPAA's minimum necessary standard mean for AI agents?
HIPAA's minimum necessary standard, at 45 CFR 164.502(b), asks covered entities to limit uses and disclosures of PHI to what the purpose requires, with role-based access policies under 164.514(d).
One correction to a common framing: the standard has exceptions. Disclosures to a provider for treatment are exempt, but a health system's own agents reading PHI are uses, and uses still fall under its role-based access policies.
That makes the access design more important, not less. A health system needs to say which agent serves which purpose, and give each one the systems that purpose requires. That is a configuration decision, made per agent.
| Agent | Connectors switched on | Connectors left off |
|---|---|---|
| Clinical support | Drug reference, clinical protocols | Billing, scheduling |
| Medical coding | ICD-10 and CPT references, encounter documentation | Prescribing, patient messaging |
| Patient education | Condition explainers, discharge templates | Prescribing databases, billing |
| Prior authorization | Payer coverage rules | Clinical notes beyond the request |
How do per-agent MCP connector switches scope a healthcare agent's tools?
The Model Context Protocol is the open standard agents use to call outside tools. On ibl.ai, each agent's MCP tab lists the available connectors, and every card carries one switch: on or off for this agent. (Existing ibl.ai capability.)
The clinical support agent gets the drug reference connector; the coding agent gets the coding references; neither sees the other's. Turning on the first connector gives an agent the mcp tool, and turning off the last one removes it.
A separate Connector Scope setting decides which agents may list a connector at all, all agents or one, so a billing connector can be confined to the one agent that needs it before any switch is touched.
Whose permissions does a healthcare AI agent use when it signs in?
This is the question that matters most for a health system, and most write-ups skip it. Each connector's Authentication Scope has three settings, per the November 4 update:
- User: each person signs in with their own account, from the chat.
- Agent: one shared account for everyone who chats with that agent.
- Organization: one shared account for every agent.
With User scope, the agent reaches a source system with that clinician's own permissions, so the role design already built in that system still applies. A shared service account is the pattern to avoid for PHI, and only an organization admin can change the scope.
When a service cannot register a sign-in app by itself, the organization enters its own OAuth client id and secret. That is a fallback: most services register automatically, with each organization getting its own client.
Can a clinician restrict an AI agent's access for one sensitive conversation?
Yes. The chat composer's + menu has an MCP row listing the agent's connectors, each with a switch that applies to that chat only, from the next message. A clinician can switch a connector off for one conversation without changing the agent.
The reverse control exists too. A connector saved with Allow Users to Turn Off disabled shows a lock, "Required by your organization", so a safety or documentation connector cannot be dropped by a user. Five settings in all decide whether a connector runs in a conversation.
That gives a health system three layers: which agents may list a connector, whether a given agent uses it, and whether a given chat uses it.
What do MCP connector switches not replace in a HIPAA program?
Switches decide which systems an agent can reach. They do not replace the audit controls required by 164.312(b), a documented risk analysis, a Business Associate Agreement with any vendor that handles PHI, or role design inside the EHR itself.
They also say nothing about where the platform runs. If the agents, the connectors and the logs sit in a vendor's cloud, the access design is only as private as that vendor. That is the case for running the stack inside the health system's own environment.
For the data side of the same problem, see why healthcare AI agents need a unified patient ontology, the governed layer each connector exposes.
How does a health system own its AI access controls on ibl.ai?
On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing, so you can deploy anywhere, from your own cloud to a fully air-gapped network.
The MCP tab ships as one SDK component a health system can mount in its own Next.js app.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. Book a 30-minute demo and we will scope connectors for one of your agents.
Sources: connector switches, authentication scopes, per-chat controls and the OAuth fallback from ibl.ai's November 4, 2026 update and the MCP docs; release date from iblai/vibe v2.20.0; HIPAA text from 45 CFR 164.312, 164.502 and 164.514. The brief described HIPAA minimum necessary as applying uniformly; treatment disclosures are exempt, though internal uses by agents are not. It also said organizations supply their own OAuth app for every connector and that audit trails stay in their perimeter; the first applies only where automatic registration fails, and the second depends on where the platform is deployed.