TL;DR: Shopify does not sign a BAA, so any PHI placed in customer, order, or health-intake fields falls outside HIPAA coverage, and MCP-connected AI assistants can move that data into model context outside the regulated boundary, according to Strac. The operational issue is not whether Shopify can store sensitive data, but whether identity, access, and content controls keep PHI from flowing into unapproved systems.
At a glance
What this is: Strac argues that Shopify can hold PHI outside HIPAA scope when no BAA exists, and that MCP-connected AI assistants create an additional path for regulated data to leave the boundary.
Why it matters: IAM and data security teams need to treat AI-mediated data flow as a governance problem, because access paths and content controls now determine whether PHI stays inside a compliant boundary.
Context
Shopify is being used here as a boundary case for HIPAA, not as a healthcare system. The issue is whether regulated information enters a platform without the contractual and technical controls needed to keep it in scope, especially when AI tools can retrieve that data and transform it into model context.
MCP changes the governance question because it connects business systems to AI assistants through an explicit tool and data layer. When PHI can move from a commerce workflow into a model session, the relevant control surface expands from storage permissions to identity, content inspection, redaction, and approved data paths.
Key questions
Q: What breaks when Shopify data is sent to an AI assistant without a BAA?
A: The compliance boundary breaks because PHI can move from a store or intake workflow into a system that has no contractual permission to receive it. Once the assistant can read, summarise, or log that data, the organisation has created an unapproved disclosure path. The risk is boundary loss, not just storage risk.
Q: Why do regulated commerce workflows need content controls, not just access controls?
A: Access controls answer who may open a record, but content controls answer whether the record may contain data that must not cross into another system. In regulated workflows, a user can be authorised to work in the source application and still be prohibited from sending PHI to an assistant, clipboard, browser extension, or log. That distinction is now essential.
Q: What are the signs that PHI is escaping a regulated workflow through AI tools?
A: Common signs include health-related notes appearing in assistant prompts, model outputs repeating customer intake details, logs capturing sensitive order text, and staff using the same browser session to move between source systems and AI tools. If the organisation cannot prove where the data went, it cannot prove that the boundary held.
Q: Who is accountable when a non-BAA system is used in a PHI workflow?
A: Accountability usually sits with the data owner, security team, and privacy or compliance function together, because each controls part of the boundary. The vendor may provide features, but it is the organisation that decides whether the workflow is approved. HIPAA accountability follows the handling decision, not the convenience of the tool.
Technical breakdown
Why missing BAA coverage changes the data boundary
A Business Associate Agreement is the contractual control that makes a third-party service part of a HIPAA-covered workflow. If the service does not sign one, PHI cannot be treated as safely governed simply because it is stored there. The practical problem is that business teams often enter health-related content into ordinary commerce fields, then assume the platform's general security controls are enough. They are not. Once customer questionnaires, prescription details, or order notes contain PHI, the surrounding process must prove that the data stayed within approved handling and disclosure boundaries.
Practical implication: Treat BAA coverage as a prerequisite control, not a paperwork step, before any PHI is placed in the platform.
How MCP can move regulated data into model context
Model Context Protocol is a tool-connection layer that lets an AI assistant query external systems and receive data at inference time. That design is operationally useful, but it also creates a new data path: information that was acceptable in one system can be pulled into a model environment that has different contractual and governance terms. The risk is not only exfiltration in the classic sense. It is regulated-data reuse, where PHI is copied into prompts, context windows, logs, or downstream outputs outside the original compliance boundary.
Practical implication: Inspect every MCP integration for what data is returned to the assistant, then block or redact PHI before it enters model context.
Why content-aware controls matter more than storage controls alone
Traditional access control answers who can open a record. Content-aware control answers whether the record contains data that must not cross a particular boundary in the first place. That distinction matters in AI-connected workflows because a user may be authorised to access the source system while still being forbidden from sending PHI to a model, browser session, or endpoint clipboard. In other words, the governance decision has shifted from simple access allowance to data-flow permissioning across systems and identities.
Practical implication: Enforce redaction, masking, and blocking at the point of collection and at the AI handoff, not only inside the source application.
Threat narrative
Attacker objective: The objective is not necessarily theft by an external adversary, but uncontrolled movement of PHI into systems that are not contractually or technically in scope.
- Entry occurs when a covered entity places health-related content into Shopify customer, order, or intake fields without BAA-backed handling.
- Credentialed access to Shopify or an MCP-connected assistant then retrieves that information as ordinary workflow data.
- The assistant receives PHI in model context, creating an unregulated copy path through prompts, responses, or logs.
- Impact is the loss of HIPAA boundary integrity, because regulated data has been exposed to a system outside the BAA scope.
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
BAA absence is a boundary failure, not a platform feature gap: The central issue is that regulated data cannot be assumed safe simply because it sits in a familiar SaaS workflow. When a platform does not sign a BAA, the organisation has already lost the contractual condition that makes downstream PHI handling defensible. For IAM and GRC teams, the practical lesson is that data classification must be tied to vendor terms as well as access policy.
MCP turns data handling into an identity and delegation problem: Once an assistant can query Shopify over MCP, the security question becomes who is allowed to delegate what data to what system, under which conditions. That is a governance issue for both human identity and non-human workflow identity. The named concept here is regulated context leakage: PHI leaves the approved boundary when model context is treated as a safe intermediate zone. Practitioners should govern the handoff, not just the source system.
Content controls now sit alongside access controls as first-class HIPAA safeguards: Traditional permission models answer whether a user may reach a record, but they do not answer whether the record may be copied into prompts, model memory, or logs. That gap is increasingly visible in AI-enabled SaaS workflows. The control failure is assuming that authorised access is equivalent to authorised disclosure, which is no longer true once model-mediated reuse exists.
The commerce stack is becoming part of the regulated data plane: Order notes, health questionnaires, and support fields are no longer isolated operational records when they can be consumed by AI tools. This creates governance debt across Shopify, browser extensions, endpoints, and MCP-connected assistants. Practitioners should treat every tool that can read those fields as part of the HIPAA scope decision, not as a separate convenience layer.
Identity governance must follow the data, not the login: The login to Shopify is only one control point. The more important question is whether the same identity is also authorised to route PHI into another system that has no BAA and no reason to retain it. This is where NHI and agentic AI governance intersect with healthcare compliance. The operational conclusion is simple: control delegated data movement as tightly as privileged access.
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: MCP Security Guide
What this signals
Regulated context leakage: PHI does not need to be stolen to become a security problem. If AI assistants can retrieve health data from commerce systems, the organisation has to govern disclosure paths, redaction points, and approved context windows as part of HIPAA control design.
Identity and access governance now has to follow delegation chains across SaaS, browser, and AI layers. A user who can view a record is not automatically authorised to hand that record to an assistant, and that mismatch will become a recurring failure mode in mixed human and agent workflows.
For practitioners
- Define PHI handling boundaries for every commerce workflow Map which Shopify fields can contain PHI, then classify each field against HIPAA handling rules and approved disclosures. If a field can hold health intake, prescription, or condition data, treat it as regulated by default.
- Block PHI at the point of entry Use browser and endpoint controls to stop staff from typing or pasting PHI into customer, order, or support fields when those fields are not covered by the required agreement and workflow.
- Inspect MCP integrations for regulated data return paths Review every assistant connected through MCP to see exactly which Shopify objects it can read, return, or log. Redact or suppress any PHI before it reaches the assistant context window.
- Separate BAA-covered systems from AI-assisted workflows Move health intake and other regulated collection into systems with the correct contractual coverage, then keep AI assistants on sanitised extracts rather than source records.
- Keep an audit trail for disclosure decisions Record what PHI was detected, redacted, blocked, or forwarded, and by which user or workflow. That evidence is what makes the boundary decision defensible during review.
Key takeaways
- The core risk is boundary failure, because PHI can move from Shopify into AI-assisted workflows that are outside the BAA scope.
- MCP makes the problem operational, since assistants can pull regulated data into model context and reuse it beyond the original system.
- The most effective control point is not only storage permissions but content inspection, redaction, and disclosure governance at the handoff stage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | MCP-style data retrieval can expose regulated data through unsafe downstream consumption paths. |
| Recommendation — Review API and tool consumption paths for unsafe handling of regulated data before model ingestion. | ||
| NIST CSF 2.0 | PR.DS-10 — Confidential Data in Transit Is Protected | PHI moving from Shopify to an assistant is a data-in-transit protection problem. |
| Recommendation — Protect regulated data in transit between SaaS and AI tools with redaction and approved routing. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article hinges on limiting who can move PHI into non-BAA systems. |
| Recommendation — Limit who can delegate or forward PHI into external assistant workflows under least privilege. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Access control must govern both source records and onward disclosure into AI systems. |
| Recommendation — Apply access control policies to data-sharing paths, not only to source application logins. | ||
| GDPR | Art. 32 — Security of Processing | The article is about protecting sensitive personal data as it moves between systems. |
| Recommendation — Secure processing by controlling redaction, disclosure, and logging across every data handoff. | ||
Key terms
- 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.
- Protected Health Information: Protected Health Information is any health-related data that can identify a person and is covered by HIPAA protections. In practice, PHI can flow through applications, integrations, service accounts, and cloud systems, which is why identity governance matters as much as data governance.
- 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.
- Regulated Context Leakage: Regulated context leakage is the uncontrolled movement of regulated data into a system or session that is not approved to receive it. The risk is especially acute with AI assistants, because data copied into prompts or context windows can be reused, logged, or summarised outside the original compliance boundary.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in the industry's only accredited NHI security programme. It gives security and identity practitioners a clearer way to govern delegated access across modern workflows.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org