The Agent Will See You Now: Why Healthcare's AI Agent Boom Needs Visibility and Control

Healthcare, as an industry vertical, is moving faster on agentic AI than it has in past technology evolutions. Some reports say it is outpacing other regulated industries. Ambient scribes are documenting patient visits in real time. Prior-authorization and revenue-cycle agents are handling payer workflows that used to require staff to log into multiple systems manually. Agents connected to the electronic health record (EHR) systems are reading and writing clinical data as part of larger automated workflows. Each of these delivers real, measurable value: time returned to clinicians, faster reimbursement, fewer administrative errors.

Getting the full value of that shift, at scale, depends on something most healthcare organizations haven't built yet: the ability to see what an AI agent actually has access to, and the ability to stop it from doing what it was never intended to do, rather than just reviewing what it already did. Visibility answers what’s happening. Control and context decide what's allowed to happen next. Together, they’re the mechanism that decides whether a promising pilot becomes an enterprise-wide capability, or stays stuck at one department, one use case, one cautious rollout at a time.

Two vertical-specific technical terms come up throughout this piece, so it's worth defining them before going further.

FHIR, Fast Healthcare Interoperability Resources, pronounced “fire”, is the standard that lets healthcare software systems exchange data with each other. Maintained by the standards organization Health Level Seven International (HL7), it’s an application programming interface (API): a defined, structured way for one system to request and receive health data, like a patient's medications or lab results, from another. Before FHIR, getting one healthcare system to share data with another often meant custom, one-off engineering. FHIR gives everyone the same rules to build against.

MCP, Model Context Protocol, is a standard that defines how an AI agent connects to tools and data sources. Anthropic introduced it in November 2024 to solve a different problem than FHIR does: a capable model is only as useful as the systems it can reach, and building a custom connection for every model-to-system pairing does not scale. MCP gives an AI agent a standard way to discover and call a set of tools, such as “look up this patient” or “check this lab result,” without bespoke integration work for each one.

The two increasingly work together in healthcare. An MCP server can act as a translator that exposes a system's existing FHIR API as a set of tools an agent calls directly. FHIR is the data and the access point; MCP is the layer that makes that access point usable by an agent, autonomously, at machine speed.

Where FHIR-Based Integration Is Already Required, Not Optional

FHIR is not a niche technical choice. It is the backbone of several federal interoperability mandates that already govern how EHRs and health plans exchange data, which is a large part of why it has become the default way AI agents connect to healthcare systems.

EHR vendors like Oracle Health and Epic, publish FHIR-based endpoints, which let any FHIR-compliant application connect to a health system to exchange patient data. The Centers for Medicare & Medicaid Services (CMS) 2020 Interoperability and Patient Access final rule (CMS-9115-F) already requires Medicare Advantage plans, Medicaid and CHIP programs, and marketplace insurers to expose patient claims and clinical data through a FHIR-based Patient Access API. More recently, CMS's Interoperability and Prior Authorization final rule (CMS-0057-F) requires those same payers to stand up a FHIR-based Prior Authorization API by January 1, 2027, so authorization requests and decisions can move electronically instead of by fax or portal. That rule is a direct reason prior-authorization agents are becoming viable at scale: the data connection they depend on is being built as a regulatory requirement, not negotiated case by case.

None of this was written with autonomous agents in mind. It was written to move data deterministically. What moves through that pipe today is increasingly an AI agent acting on that data, and the mandates are silent on what that agent is allowed to do once it's connected.

The Gap the Rules Miss

Two other regulatory tracks are relevant for anyone deploying agents in healthcare right now, and both point in the same direction: organizations are largely on their own to define good practice for agent-specific risk in the near term.

The U.S. Department of Health and Human Services (HHS) proposed update to the HIPAA Security Rule, which would add requirements like mandatory multi-factor authentication, micro-segmentation, and a comprehensive technology asset inventory, drew nearly 5,000 public comments and has moved to a long-term rulemaking agenda, with final action now expected in July 2027, a delay from HHS's earlier target.

The U.S. Food and Drug Administration (FDA), separately, issued guidance in January 2026 that gives AI-enabled clinical decision support tools more room to operate without triggering full device classification, as long as a clinician can independently review the basis for a recommendation. That guidance is explicit that autonomous, opaque, or time-critical systems fall outside this exception and still warrant closer scrutiny. That’s a reasonable distinction, but one that many agentic tools in production today don't clearly satisfy, because they are designated as workflow software rather than clinical decision support.

Put plainly, the compliance frameworks that will eventually govern agentic AI in healthcare are still years from final. That leaves a gap between what an agent is technically permitted to touch, by virtue of its FHIR and MCP connections, and what anyone is verifying it does with that access. Organizations that close that gap themselves, now, aren't just managing risk in the interim. They're building the operational maturity that will make it far easier to meet whatever the eventual requirements turn out to be, and the visibility and the runtime controls to expand agent use with confidence instead of hesitation.

Three Categories of Agent, One Common Risk Pattern

Ambient scribes listen during a clinical encounter and generate structured documentation, such as history, assessment, and plan, for the clinician to review and sign. The value is well established. The risk worth understanding sits in what happens after capture: where the audio and transcript are stored, which vendor and subprocessors touch that data, how model updates are validated before reaching a live clinical workflow, and how a hallucinated detail that reads as fluently as anything else in the note gets caught before it becomes part of the permanent record rather than after. The American Bar Association's health law section has flagged consent tracking and vendor data flows as open questions for organizations deploying these tools today.

Prior-authorization and revenue-cycle agents check payer rules, assemble supporting documentation, and submit or track authorization and billing workflows across systems that used to require a person logging into each one separately, work that CMS's FHIR-based Prior Authorization API is specifically designed to make possible at scale.⁵ That connectivity is also the shape of the risk. An agent authorized to interact with both a payer's FHIR API and a healthcare system’s own billing systems is, functionally, holding credentials to two organizations at once. Provisioning that access is easy. Continuously verifying what the agent actually does with it is the harder and more consequential problem, and it's the one most organizations haven't solved.

FHIR and EHR-connected agents read and write structured clinical data, such as, clinical problem lists, labs, and medications, directly through FHIR APIs, often via MCP servers that expose those APIs as callable tools rather than requiring a custom build against each EHR vendor's implementation.³ This is infrastructure. Once an organization builds a connection layer like this, every agent built on top of it inherits whatever access and oversight that layer provides, for better or worse. Security researchers evaluating these integrations have pointed to two concrete risks worth designing for: minimal request-level logging of what an agent actually retrieved, and the possibility that content an agent ingests, a clinical note, a referral letter, gets treated as an instruction to follow rather than data to read.⁹ That second risk is a variant of prompt injection, and it is precisely the kind of behavior that traditional network and endpoint security tools were never built to see, because the agent is the new endpoint, and the attack surface is what the agent is trusted to act on, not just where it runs.

Across all three categories, the pattern repeats. The limiting factor is rarely whether the model is capable enough. It's whether the organization can answer, with evidence rather than assumption, what a given agent has access to, what it has actually done with that access, and whether it can be stopped from taking an action it was never intended to take, before that action completes, not just flagged for review after the fact.

Visibility and Control Are What Let Agents Scale

None of this is an argument for slowing down. FHIR and MCP adoption in healthcare is genuinely valuable, and the agents built on top of them are already returning real time information to clinicians, real dollars to revenue cycles, and have the potential to improve patient safety and experience.

The argument is narrower and, I'd argue, more useful: detection after a record has already moved, or after an authorization has already been submitted, is not security. Intent is not control, either. An agent that was only ever supposed to check a lab result but technically can write to a medication list is a governance gap whether or not it has ever misused that path, and visibility alone only tells you the gap exists. Posture management, the continuous, agent-centric accounting of what an agent can reach and what it has actually done, is what turns “we think this is fine” into “we can show you the evidence.” Runtime controls, the hard boundaries that stop an agent from taking that unintended action in the first place rather than merely logging it, are what turn “we can show you this is fine” into “this cannot go wrong, whether or not anyone is watching.” That distinction, seeing and stopping, is what compliance and clinical leadership are actually asking for when they hesitate to approve the next tranche of AI use cases.

Healthcare doesn't need to choose between adopting agentic AI and controlling it. The organizations that build agent-level visibility and runtime controls now, rather than waiting for HIPAA's next revision or the FDA's next guidance document, are the ones that will keep expanding into more sensitive workflows without having to pause and rebuild trust after something goes wrong.

Download our Definitive Guide to AI Security for Healthcare to learn more about how AI security is structured in healthcare.