HIPAA non-covered entities still need data controls for e-PHI

At a glance

What this is: Strac argues that organisations outside HIPAA coverage can still lose e-PHI through SaaS, cloud, AI and MCP-connected workflows if they rely on legal status instead of data controls.

Why it matters: For IAM and security teams, the key issue is that access, sharing and remediation controls still have to govern sensitive health data even when HIPAA does not directly apply.

Context

HIPAA coverage is a legal classification, not a data-loss control. An organisation can fall outside covered-entity obligations and still process electronic protected health information in modern systems, which means exposure risk is governed by where the data travels, who can access it and whether it can be discovered and remediated.

That matters for identity and data governance because e-PHI often moves through SaaS sharing, external collaboration, AI tools and connected workflows before anyone classifies it formally. In practice, the control gap is not whether the organisation is a covered entity. It is whether sensitive health data is visible, access-controlled and auditable wherever it is stored or exchanged.

Key questions

Q: How should organisations protect e-PHI if they are not a HIPAA covered entity?

A: They should treat HIPAA status as a legal classification, not a security boundary. If e-PHI exists in SaaS, cloud, endpoints, or AI workflows, organisations still need discovery, access control, redaction, logging, and revocation. The practical goal is to prevent unnecessary disclosure and preserve evidence for investigation, regardless of whether the entity is formally covered.

Q: Why does HIPAA status not eliminate health-data risk in SaaS and AI systems?

A: HIPAA status only tells you whether the organisation has direct regulatory obligations. It does not stop e-PHI from being stored, forwarded or exposed in collaboration tools, connected applications or AI prompts. Risk remains because the same data can be replicated across systems with different permission models, making governance a data-flow problem rather than a legal classification problem.

Q: What are the signs that e-PHI controls are failing outside HIPAA scope?

A: Common signs include publicly shared files, overbroad guest access, PHI appearing in tickets or chat logs, and AI tools receiving raw health data without redaction. These are indicators that discovery and permission controls are not aligned to how the information is actually used, which usually means exposure is happening faster than governance.

Q: What should security teams do when AI workflows can access health data?

A: Security teams should define which data the workflow may retrieve, what it may output, and what must be redacted before any tool call is made. They also need logging for prompts, connector activity and data exports so health-data movement can be audited. Without those controls, AI connectivity becomes an uncontrolled dissemination path for e-PHI.

Technical breakdown

Why legal HIPAA status does not stop e-PHI exposure

HIPAA determines regulatory obligation, not whether sensitive health data exists in the environment. Non-covered entities can still create, store or transmit e-PHI through customer apps, workflow tools, documents, tickets and collaboration platforms. The practical security issue is that data paths often span systems owned by different teams, so one classification label does not govern every copy, share or export. Once e-PHI enters SaaS, cloud storage or AI-assisted workflows, the organisation needs controls that follow the data rather than relying on the legal category of the business.

Practical implication: Treat HIPAA status as a compliance boundary, not a data-security boundary.

How discovery and redaction reduce health-data spillover

Discovery identifies where e-PHI exists, while redaction, masking and tokenization reduce the sensitivity of what users and downstream systems can actually see. In mixed SaaS and AI workflows, that distinction matters because health data is frequently copied into chats, tickets, documents and prompts. Without content-aware controls, sensitive fields can persist in places that are hard to inventory or remove later. The result is not just exposure at rest, but uncontrolled propagation across integrations and user-generated content.

Practical implication: Place discovery and automated redaction at the points where e-PHI enters collaboration and AI workflows.

MCP-connected AI workflows create a new data-governance edge

Model Context Protocol links AI agents to tools and data sources, which makes it easier for health data to move from business systems into model-driven workflows. That creates a governance problem even for non-covered entities, because the risk is not only model output. It is the handoff of e-PHI into connected services that may preserve, forward or surface it again. MCP-style integration therefore turns data lineage, permissions and logging into first-order controls for health information.

Practical implication: Map MCP-connected data paths and constrain what health data agents can retrieve or relay.

Threat narrative

Attacker objective: The objective is to expose or extract sensitive health information from modern collaboration and AI workflows before the organisation can contain or audit it.

1. Entry occurs when e-PHI is collected or exchanged through SaaS, cloud, endpoint or AI workflows outside a covered-entity model.
2. Credentialed access and collaboration paths then allow the same data to be copied into chats, documents, tickets or connected AI systems.
3. The impact is uncontrolled disclosure, audit gaps and broader exposure of sensitive health information across systems that were never designed to handle it as regulated health data.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Classification is not governance: HIPAA status answers who is regulated, not whether e-PHI is at risk. Once sensitive health data enters SaaS, cloud or AI workflows, the security problem becomes discovery, access scope and remediable visibility. The practitioner conclusion is simple: legal scope is not a substitute for data control.

e-PHI sprawl is the real failure mode: health data now moves across emails, tickets, documents, endpoints and AI prompts faster than most organisations can classify it. That creates a persistence problem where sensitive fields survive in secondary systems long after the original transaction is over. The practitioner conclusion is to govern the copies, not just the source.

MCP expands the governance surface for health data: connected AI workflows can pull e-PHI into agentic paths that traditional DLP and access review models do not see clearly. This is where NHI governance intersects with health-data protection, because tool access and data access become the same control problem. The practitioner conclusion is to treat AI connectivity as part of the e-PHI control plane.

Data controls must be content-aware, not label-aware: rules that only look at entity type, business unit or HIPAA status will miss the way health information actually moves. Automated discovery, redaction, audit trails and permission review are the operational baseline for any organisation handling e-PHI, covered or not. The practitioner conclusion is to build controls around data behaviour, not organisational assumptions.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Ultimate Guide to NHIs — Regulatory and Audit Perspectives

What this signals

e-PHI governance now starts at the content layer: organisations that are outside HIPAA coverage still need controls that inspect what data is moving, not just which business unit owns the workflow. That shifts the operating model toward discovery, redaction and permission review across SaaS, endpoint and AI paths.

MCP makes health-data lineage more important: once AI agents can reach business systems, the question is no longer only whether a user is authorised. The harder problem is whether an agent should be allowed to retrieve, transform or forward sensitive health data at all, and whether those actions are recorded well enough to investigate later.

Identity controls remain part of the answer: externally shared files, excessive permissions and ungoverned collaborator access are still the most direct ways e-PHI escapes its intended boundary. Teams should treat those access paths as part of their health-data protection programme, not as separate IT hygiene tasks.

For practitioners

• Deploy continuous e-PHI discovery across SaaS and cloud Scan collaboration tools, storage, tickets and endpoint content for health data so sensitive information is visible before it is shared or exported.
• Apply redaction and masking at workflow entry points Redact or tokenise PHI in emails, chats, documents and AI prompts before those systems can redistribute the data into downstream tools.
• Review external sharing and collaborator permissions Identify publicly shared files, guest access and excessive permissions that allow e-PHI to leave its intended control boundary.
• Log health-data movements across AI and MCP workflows Maintain audit trails for tool calls, prompts and file transfers so investigators can reconstruct how e-PHI reached each system.
• Map HIPAA scope separately from data scope Document which business processes are outside covered-entity obligations but still process regulated-like health information and therefore need security controls.

Key takeaways

• Non-covered entities can still create the same exposure problem that HIPAA is meant to constrain, because e-PHI moves through the systems and identities that actually handle the data.
• The main failure mode is data sprawl across SaaS, AI and connected workflows, where legal classification does not keep pace with operational sharing.
• Effective protection depends on discovery, redaction, permission review and audit trails that follow e-PHI across the full workflow chain.

Key terms

• Electronic Protected Health Information: Electronic protected health information is any PHI stored, processed, or transmitted in digital form. In practice, it includes records and related metadata that can identify a patient and must be protected through access control, logging, and breach response processes across human and non-human identities.
• Business Associate: A business associate is any external organisation that handles PHI on behalf of a covered entity. The term matters because liability and security obligations extend beyond the primary healthcare provider, making third-party access governance, contract terms, and technical controls part of the same compliance chain.
• Data Loss Prevention: Data loss prevention is the set of controls used to detect, block, and report sensitive data moving in ways the organisation does not allow. In practice, DLP must account for endpoints, email, cloud apps, APIs, and user behaviour, or it will miss the paths where real exposure happens.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management in the context of modern identity risk. It is designed for practitioners building controls that connect identity governance to broader security programmes.