HIPAA’s 2026 update turns AI authorization into a compliance test

At a glance

What this is: OCR’s expected HIPAA Security Rule update makes AI systems that touch ePHI part of a continuous authorization and audit problem, not a side issue.

Why it matters: IAM teams have to govern AI, NHI, and human access in one control model because HIPAA will expect proof of runtime decisions, not just identity setup.

By the numbers:

• The comment period closed in March 2025 with nearly 5,000 submissions.

👉 Read EnforceAuth’s analysis of HIPAA’s 2026 AI authorization requirements

Context

HIPAA’s pending Security Rule update is not really about adding an AI section. It is about forcing healthcare organisations to prove that every identity touching ePHI is governed at runtime, including AI systems, service identities, and the human workflows around them. The primary issue is authorization, because provisioning-time access models do not match how AI actually operates.

The compliance pressure comes from a familiar gap in modern IAM: authentication still answers who or what an identity is, but not what it may do with sensitive data under changing context. In healthcare, that gap becomes visible the moment an ambient scribe, prior authorization agent, or triage bot can read, write, or summarise ePHI without a continuously enforced policy layer.

That is why this update matters to both NHI governance and human IAM programmes. The rule is effectively asking regulated entities to show that identity, purpose, logging, and risk reassessment all line up in one defensible control chain, which is a very different expectation from legacy access review and role assignment models.

Key questions

Q: What breaks when healthcare teams rely on provisioning-time access for AI systems touching ePHI?

A: Provisioning-time access breaks because it assumes the requester, purpose, and risk context stay stable long enough for quarterly review to matter. AI systems can change context within a session, so a static role or entitlement does not prove what was allowed at the moment of use. That creates a compliance gap for ePHI because the organisation cannot show runtime authorization, only original assignment.

Q: Why do AI systems complicate HIPAA access governance for ePHI?

A: AI systems complicate HIPAA access governance because they blur the line between identity and action. A model may read data, summarise it, write back to the record, and trigger downstream workflows without a human making each request. That makes Minimum Necessary enforcement and continuous reassessment much harder than in a human-only access model.

Q: How do security teams know whether AI authorization for ePHI is actually working?

A: Teams know it is working when they can reconstruct every AI access decision from request to outcome, including the policy version and contextual inputs used. If the evidence is split across spreadsheets, EHR logs, and gateway logs, the control is not working as a governance system. Real assurance means a decision record exists for every approval and denial.

Q: Who is accountable when an AI system accesses ePHI outside its intended purpose?

A: The covered entity remains accountable, and business associates may share that accountability depending on the service relationship and contract terms. HIPAA does not transfer the burden to the model or the tool. If AI access is not continuously governed and logged, the organisation that deployed it still has to answer for the exposure.

Technical breakdown

Why provisioning-time access breaks for AI systems touching ePHI

Traditional IAM was built around stable identities and durable access grants. AI systems do not behave that way. An ambient documentation tool, a prior authorization agent, or a triage chatbot can shift context from one call to the next, while downstream use of its output can expand the effective access path beyond what was intended at provisioning. That makes role assignment alone insufficient. The security problem is not simply who can log in, but which data, purpose, and action are permitted at the moment of use. In healthcare, that distinction matters because ePHI access must remain constrained to the minimum necessary purpose, even when the identity is non-human.

Practical implication: replace static access assumptions with runtime policy decisions for every AI identity that can reach ePHI.

Continuous risk reassessment is now part of authorization

The NPRM ties risk analysis to changes in models, training data, prompts, and system behaviour. That moves authorization away from a one-time onboarding event and into a continuous control loop. In practice, this means the identity layer has to react when a model drifts, when a prompt injection is detected, or when a new vulnerability affects the AI component in use. The important technical point is that authorization and risk are no longer separate stages. Risk signals now influence whether access remains valid at the moment of the request. That is a major architectural shift for healthcare environments that still treat access governance as quarterly review plus logging.

Practical implication: wire AI risk signals into the authorization path so access can narrow or stop when conditions change.

Decision-level audit logging is different from access logging

OCR will not be satisfied by a record that says an AI system accessed a file or an API. The regulated entity has to show the decision itself: what was requested, which policy evaluated it, what contextual inputs were present, and why the outcome was approved or denied. That is decision-level logging, not session logging. It also means logs must correlate the AI system, the service identity, the policy version, and the access context in a way auditors can reconstruct later. In an ePHI environment, fragmented logs across the EHR, gateway, and model layer create a proof gap even if each tool is individually configured correctly.

Practical implication: build immutable decision logs that connect the request, policy version, context, and outcome for every AI access attempt.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The Authorization Gap is now a healthcare governance problem, not just an IAM gap. The NPRM does not need an AI-specific section to create an AI-specific obligation. Once the rule removes addressable escape hatches and requires continuous reassessment, the real failure mode becomes obvious: existing access governance cannot prove runtime control over identities that change context faster than review cycles can observe. Practitioners should treat this as a governance redesign problem, not a policy tweak.

Minimum Necessary was designed for human-paced access decisions. That assumption fails when the actor is an AI system that can request, transform, and output ePHI across multiple tasks in a single session. The implication is not simply that more controls are needed, but that the old premise of stable intent no longer holds. Healthcare programmes must rethink how purpose limitation is enforced when the requester is non-human and the context is transient.

Decision-level authorization is the named concept this rule forces into view. The industry has often treated authentication, role assignment, and logging as separate layers, but OCR is collapsing them into one evidentiary requirement. If a regulated entity cannot show why a specific AI request for ePHI was approved or denied, it has not governed the identity properly. Practitioners should assume that proof, not just permission, is now the standard.

Human-first IAM models will remain necessary, but they are no longer sufficient. Healthcare environments will still need federation, MFA, and access review for people, yet those controls do not answer the runtime question for AI identities. The field is moving toward dual governance, where human access and non-human authorization share the same compliance objective but require different enforcement mechanics. Teams should expect their architecture to split accordingly.

The healthcare sector is being pushed toward policy-as-code because narrative policy cannot survive audit. PDFs describe intent, but OCR will ask for versioned, testable, reproducible authorization behaviour. That shifts the centre of gravity from governance documentation to enforceable control logic. Practitioners should interpret this as a demand for evidence-grade policy, not a request for more paperwork.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For the healthcare angle, see the Ultimate Guide to NHIs , Regulatory and Audit Perspectives for how audit and compliance controls translate across NHI programmes.

What this signals

The healthcare impact is broader than HIPAA alone. As organisations move from human-centric access reviews to continuous authorization for AI systems, the control plane has to understand purpose, context, and output handling in real time, not just role assignment at onboarding. Decision-grade authorization: the control model now has to prove why an AI request was allowed, not just that the identity existed.

That shift also changes programme planning. With 44% of developers reported to follow security best practices for secrets management, according to The State of Secrets in AppSec, the wider environment already shows how weak operational discipline can undermine sensitive access controls. Healthcare teams should expect AI governance to fail in the same way if policy, logging, and identity ownership are split across teams.

For practitioners

• Inventory every AI identity touching ePHI Build a live inventory of models, agents, API keys, service accounts, and workflows that can read, write, train on, or summarise ePHI. Include model version, data source, and the business purpose each system serves.
• Convert AI access rules into policy-as-code Write Minimum Necessary, permitted-purpose, and sensitivity rules as versioned policy so you can prove what was enforced on a specific date. Store the policy in source control and test it before deployment.
• Correlate decision logs across every control layer Link the EHR, gateway, and authorization decision trail so each AI request can be reconstructed end to end. A usable audit record should show the request, the policy version, the context, and the outcome.
• Tie AI risk signals to access enforcement When a model vulnerability, drift event, or prompt injection alert appears, narrow scope or block access in the authorization layer rather than waiting for a manual change ticket.

Key takeaways

• The pending HIPAA update turns AI access to ePHI into a runtime authorization and proof problem, not just an authentication or logging problem.
• The evidence gap is operational, because most organisations cannot yet produce a clean decision trail that ties AI access to policy, context, and outcome.
• Healthcare teams that want audit-ready control need live inventory, policy-as-code, and decision-level logging before the final rule lands.

Key terms

• Authorization Gap: The mismatch between what an identity is allowed to do on paper and what it can actually do in production. In this context, it describes the gap between legacy IAM controls and the runtime authorization healthcare AI needs to touch ePHI safely.
• Decision-level Audit Logging: A logging model that records not just that access happened, but why a specific access request was approved or denied. For healthcare AI, it must capture the request, policy version, context, and outcome so auditors can reconstruct the control decision later.
• Policy-as-Code: Authorization rules written as testable, version-controlled code rather than only as documents or process notes. This makes access policy reproducible, reviewable, and enforceable at runtime, which is essential when AI systems need continuous decisions rather than one-time provisioning.

Deepen your knowledge

HIPAA AI authorization, runtime access governance, and ePHI control design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a healthcare identity programme from a similar starting point, it is worth exploring.

This post draws on content published by EnforceAuth: HIPAA Security Rule update and the authorization gap in healthcare AI. Read the original.