Minimum Necessary Standard Applied to AI Agent Data Access

Minimum necessary is a specific legal requirement, not a general instinct toward caution, and most AI agents deployed against protected health information today do not satisfy it. The standard says you have to scope access to what a single task requires, but nearly every agent deployment in healthcare instead grants access at the session level. That gap between what the law requires and what the technology defaults to do is the subject of this piece.

Minimum necessary requirements at the operational level

The minimum necessary standard comes from the Privacy Rule, codified at 45 CFR §164.502(b), and it states that a covered entity or business associate must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request. It applies to every covered entity and business associate operating in the United States: an enforceable limit on what can be touched, by whom, and for what reason, each time PHI moves.

The standard operates differently depending on whether a disclosure is routine or not. Neither path allows a blanket grant of access followed by a retrospective check to see whether anything went wrong. The constraint has to be applied before the data moves, not audited after the fact.

HHS made its position on AI unambiguous when it published a proposed Security Rule update in the Federal Register in January 2025, the first major update to the rule in over a decade. The obligation on these systems already applies, not at some future date.

What all of this adds up to, at the operational level, is a judgment call that has to happen at the exact moment PHI is accessed: does this specific task need this specific data, and nothing more? The next section explains why an AI agent, by the way it is built, cannot.

Why AI agents cannot apply that judgment by design

The minimum necessary standard assumes a human being is making a task-level decision at the point of access, someone who understands the request, the patient relationship, and the regulatory stakes well enough to pull only what's needed and stop there.

The infrastructure built around HIPAA compliance over the past two decades assumes a person is doing the retrieving: someone who knows the task, knows the patient, and knows enough about the regulation to apply judgment in the moment. In neither case has anyone accessed something they weren't authorized to see. Both cases can still violate minimum necessary, because the violation is about scope, not permission.

Computer-use agents go further: they add a layer of exposure beyond data retrieval. The agent doesn't choose to look at the extra information. It simply can't avoid seeing it.

The architecture itself is the issue. Those frameworks work best against large context windows and comprehensive datasets, because more context generally produces better reasoning and fewer dropped requirements. That is precisely backward from what minimum necessary demands. The default behavior most agent frameworks are optimized for is structurally opposed to the scoping the Privacy Rule requires, and no amount of careful prompting changes the underlying design.

This produces a failure mode that doesn't look like the breaches HIPAA enforcement has historically targeted. A DLP system won't catch it. An access log review won't flag it, because the access itself was permitted. The violation lies in the scope of what was pulled, a distinction most monitoring tools aren't built to see.

How session-level credentials create systemic rather than point exposure

Most AI agent deployments run on shared service accounts or broad API key grants, credentials that hand an agent access to everything that account can reach for the duration of a session. A single workflow needs just three fields from one chart, but that need turns into an unrestricted retrieval surface covering every operation the agent might run during that session, whether the task calls for it or not.

Access scope has to be evaluated per operation, not per session. Session-level credentials collapse that distinction entirely: once the session is open, the agent can do anything the credential allows, for as long as the session lasts.

Two mechanisms repeatedly cause this problem: session-level credentials and persistent conversation context. The second is persistent conversation context, a memory system that holds onto PHI across multiple sessions long after the task that justified the first access has ended. So both patterns turn a narrow, justified access into a standing reservoir of exposed data that outlives its purpose.

Shared credentials compound the problem by erasing attribution. When the question is which agent accessed a given patient record and who authorized that access, a shared key has no answer to offer, and the audit trail requirement under §164.312(b) goes unmet as a result.

Organizations sometimes try to patch this with instructions baked into the system prompt: tell the agent not to touch certain categories of PHI. That doesn't count as a technical access control under the Security Rule, and for good reason. Only enforcement built into the data layer itself, something the agent cannot reason or be tricked its way around, qualifies as a control an auditor can defend.

The consequence of all this is that a single failure in an agentic system isn't a point incident the way a single misdirected fax or misfiled record might be. A common defense is that the agent only accesses what the workflow needs in practice, judged by watching what it actually retrieves. That defense misses the point the standard is making: the constraint has to be enforced at the data layer before access happens, not inferred afterward by observing behavior. What an agent happened to retrieve on a given run says nothing about what it was actually scoped to retrieve, and an auditor will ask what it was scoped to retrieve versus what it actually pulled.

Prior authorization and revenue cycle workflows: where the gap is most acute

Prior authorization shows this problem hardest, because the workflow forces agents to gather broad clinical context to satisfy payer requirements that are not standardized and cannot be predicted in advance. The CMS mandate requiring faster authorization decisions, with operational provisions taking effect January 1, 2026, has increased the pressure to automate this process, and that pressure produces faster automation without resolving the scoping problem that causes it.

Part of the difficulty is structural rather than technical: there is no agreed standard defining the data set that is both necessary and sufficient for an insurance company to accept a prior authorization request. Faced with that inconsistency, an agent has every incentive to over-collect, because under-collecting risks a denial or a resubmission, and the cost of guessing wrong falls on the patient and the provider, not on the payer.

For payers that still lack modern APIs, the problem gets worse. The agent takes in whatever it encounters along the way, because the phone call itself offers no way to filter what it hears or sees before processing it.

Revenue cycle teams face a structurally identical problem when they build AI-assisted retrieval systems to answer billing and coding questions. Every one of those deployments involves PHI, and none of them, as typically built, applies the minimum necessary standard in any way that would hold up under review.

None of this means scoped access is out of reach. A workflow built to analyze a patient's insurance card image, extract the relevant fields, and pair them with the patient's existing record to recommend the correct insurance plan shows that purpose-bounded design works in practice and that narrowing scope to what a task needs measurably reduces downstream errors. That example shows that compliance has to be designed in from the start.

2025 Security Rule amendment requirements for agent deployments

The 2025 HIPAA Security Rule amendments represent the most significant overhaul to the rule in years, and they close, in concrete terms, many of the gaps that AI deployments have been slipping through under the old, more flexible standard.

Where covered entities once had latitude to treat many safeguards as "addressable," meaning they could document a reason for not implementing them, the amendments convert a large share of those safeguards into mandatory requirements. Encryption is one of them. Business associate accountability expands under the same amendments. So if you built your compliance posture before you started deploying AI agents, you are, by definition, already behind the current requirement.

Unique user identification, required under §164.312(a)(2)(i), calls for each authorized user, whether a person or an entity, to have a distinct identifier so that system access and activity can be tracked back to that specific user. A shared service account or API key used across multiple agents or workflows fails this requirement outright, because there is no way to isolate which user, human or machine, performed a given access.

Audit Controls, required under §164.312(b), call for mechanisms that record and examine activity in any system that contains or uses electronic PHI. For an AI agent, satisfying that standard means the audit record has to capture the specific operation performed, the data accessed, the identity of the agent, the human who authorized the action, and the timestamp. Standard API call logs and the inference logs most large language model platforms produce can't meet that bar, because they record events at too coarse a level of detail.

The business associate chain under these amendments extends past the primary AI vendor to every subprocessor involved: cloud infrastructure providers, third-party compute, and separate inference APIs run by a different company than the one a covered entity contracted with directly. If any of those touch PHI, each one needs its own business associate agreement. An organization that signs one BAA with its primary vendor and assumes that coverage extends automatically to every service that vendor relies on is carrying risk it has not documented and cannot defend.

The controls that bridge operation-level scoping to agent architecture

Closing the distance between what minimum necessary requires and how agents are typically built comes down to three things: enforcing scope at the data layer before access occurs, giving each agent its own identity for audit purposes, and building operation-level policy checks directly into the agent's retrieval path.

Everything downstream of an agent's access depends on how PHI was classified before that agent ever queried it. What determines a deployment's HIPAA exposure is whether PHI was classified, scoped, and logged before an agent could reach it, not which data catalog or classification tool an organization purchased.

Access scope needs to be evaluated at the level of the individual operation, not the session. Each time an agent makes a retrieval call, that call should be checked against a policy asking what this specific operation requires, not what the session's credentials happen to allow. This is the architectural equivalent of the judgment a human once applied by instinct: a rule, encoded at the point of retrieval, standing in for the instinct that no longer exists in the loop.

Every interaction an agent has with PHI is a potential audit record, and the Audit Controls standard requires a mechanism that records and allows examination of activity at that granularity, the operation performed, the data touched, the agent's identity, the authorizer, and the timestamp, not simply a note that a session took place.

BAA coverage has to extend to every subprocessor in the chain. A primary vendor's agreement does not automatically cover the cloud infrastructure, inference APIs, or downstream compute that vendor relies on. Each of those needs its own coverage before PHI reaches it.

Retrieval itself needs to be designed around purpose. It does not need the patient's full medical history to complete that task, and building it so that it retrieves only the fields a given operation calls for is the encoded version of a principle that has sat at the center of HIPAA for decades.

But computer-use agents working inside EHR or payer portal screens need a separate layer of control, because their visual context window takes in everything rendered on the screen in front of them, whether it's relevant or not.

Some organizations will object that operation-level scoping of this kind is too complex to build quickly. The counter to that is sequencing: start with per-agent identity and operation-level logging, then narrow retrieval scope workflow by workflow as the architecture matures. The risk of waiting outweighs the complexity of building incrementally, because a single agent run against a broad credential is already a live exposure across every record that credential can reach, whether or not anything has gone wrong yet.

Defensible compliance before an agent goes live

A compliance posture that will hold up under scrutiny is demonstrated by the ability to show, for any single PHI access event, which agent performed it, which operation authorized it, what scope that operation was granted, and why that scope matched what the task genuinely required.

So you need to enforce access controls technically, at the data layer, with agent-level identifiers already in place and retrieval scope already restricted per operation before the agent's first run. Skipping any one of those steps doesn't create a theoretical compliance gap to clean up later. It creates a live violation from the moment the agent starts operating.

The governance work you do before deployment pays off again later, when your workflows inevitably change. If an agent's retrieval scope lives at the data layer, you can narrow or widen that scope through a policy update alone. An agent built on session-level credentials and system-prompt instructions needs a full re-deployment to make the same adjustment, every time circumstances shift.

The workflow definition itself becomes the operational expression of minimum necessary, something that can be audited, versioned, and adjusted on its own terms, without ever having to touch the underlying systems it governs.