Shadow AI breaks SOC 2 and HIPAA controls in regulated firms

At a glance

What this is: This is an analysis of how unsanctioned AI use creates compliance and data-handling gaps for SOC 2 and HIPAA programmes.

Why it matters: It matters because security, IAM, and compliance teams need to govern AI access as a policy and identity problem, not just a user-behaviour issue.

By the numbers:

• 74% of organizations have already experienced data leakage through unsanctioned AI use, yet most lack visibility into when or how it happens.
• 74% of organizations have already experienced data leakage through unsanctioned AI use, yet most lack visibility into when or how it happens.

👉 Read Pomerium's analysis of shadow AI risks for SOC 2 and HIPAA

Context

Shadow AI is the use of AI tools without approval, oversight, or control from security and compliance teams. In regulated environments, that is not just an adoption problem. It becomes an identity and access problem because the tool is outside the approved route, the user is outside sanctioned policy, and the data path is outside audit.

SOC 2 and HIPAA both depend on structured controls that can be enforced, logged, and reviewed. When employees send data to consumer AI services through unmanaged accounts and unapproved workflows, those controls stop working at the point of use, which is why the issue belongs in IAM, IGA, and compliance governance as much as in security operations.

Key questions

Q: How should security teams govern shadow AI use in regulated environments?

A: They should treat shadow AI as an identity and policy enforcement problem. The practical model is to mediate AI access through managed identities, device trust, and request-layer controls so that unapproved use is blocked before data leaves approved systems. Logging must also capture the request context, because compliance depends on evidence, not intent.

Q: Why does shadow AI create compliance risk for SOC 2 and HIPAA?

A: Because both frameworks assume that access, data handling, and third-party use are controlled and observable. Shadow AI bypasses those controls by moving regulated data into consumer services that are outside sanctioned identity, logging, and vendor review processes. That breaks the ability to demonstrate safeguards and investigate incidents after the fact.

Q: What do organisations get wrong about managing unsanctioned AI use?

A: They often focus on banning tools instead of governing the request path. The real failure is not that employees try AI, but that the organisation has no enforced control point for identity, context, and data movement. Without that boundary, policy becomes advisory and auditability disappears.

Q: Who is accountable when shadow AI exposes regulated data?

A: Accountability sits with the organisation that allowed the data path to exist without control. Compliance, IAM, security, and business owners all share responsibility, because unmanaged AI use is a governance failure rather than a single-user mistake. The organisation must be able to prove who approved access and how it was monitored.

Technical breakdown

Why unsanctioned AI use breaks access control

Shadow AI tools are typically reached through consumer accounts rather than enterprise identities, which means the organisation loses group membership, device trust, and policy binding at the front door. That matters because access control is no longer based on managed identity context. Once the request leaves sanctioned systems, the organisation cannot reliably distinguish approved from prohibited use, even when the user is the same person. In practice, the control gap is not the model itself. It is the absence of enterprise-enforced routing, identity, and policy mediation around the model.

Practical implication: route AI access through enterprise controls that can bind identity to policy before data leaves managed systems.

How visibility and auditability disappear

SOC 2 and HIPAA both rely on evidence. Shadow AI activity usually bypasses the systems that generate that evidence, so teams lose logs, request context, and data-transfer records. Without those artefacts, compliance teams cannot reconstruct who used which service, when it happened, or what data was exposed. That is why unmanaged AI use creates a governance gap even when the business impact seems minor. The issue is not only exfiltration. It is the inability to prove that controls existed and worked.

Practical implication: require queryable logs for every AI request that touches regulated data or internal systems.

Why policy enforcement must sit at the request layer

Policy at the endpoint or network edge is often too coarse for shadow AI because the risk is not all AI use, but unapproved AI use in unapproved contexts. Request-layer enforcement lets teams evaluate user identity, device posture, destination, and action type before the prompt or upload is allowed through. That aligns well with regulated workflows, where the question is whether a specific transaction should happen at all. For IAM and compliance teams, the architectural lesson is simple: the control point must sit where the data is about to move.

Practical implication: enforce per-request policy at the routing layer for approved AI access paths.

NHI Mgmt Group analysis

Shadow AI is a governance problem before it is a technology problem. Unapproved AI use bypasses the organisational identity layer, which means security teams lose the ability to bind access, logging, and policy to a managed subject. In regulated environments, that turns routine productivity behaviour into a control failure. The practitioner conclusion is that AI access needs to be governed as part of the identity estate, not treated as an exception outside it.

SOC 2 and HIPAA fail where control evidence disappears. These frameworks depend on demonstrable safeguards, but consumer AI usage typically produces no organisational logs, no enforceable route, and no usable audit trail. That is the failure mode: the organisation cannot prove what happened, which makes both assessment and response weaker. The practitioner conclusion is that evidence generation must be designed into the AI access path.

Per-route enforcement is the named concept that matters here: policy must decide the request, not just the user. When AI access is mediated at the routing layer, teams can apply identity, device, and context checks before sensitive data leaves managed systems. That approach fits regulated use cases better than post-hoc monitoring because it preserves both productivity and control. The practitioner conclusion is to treat request mediation as a control boundary, not a convenience feature.

Shadow AI also exposes the limits of traditional third-party review. Consumer AI services can enter through bottom-up adoption long before procurement or risk teams evaluate them, which means vendor review processes are already too late if they operate only at purchase time. The practitioner conclusion is that third-party oversight must extend to usage detection and access governance, not just contract review.

The compliance boundary is now identity-shaped. Once employees can move data into AI tools using personal accounts, the real boundary is no longer the corporate network. It is whether the organisation can recognise, authorise, and record the transaction in time. The practitioner conclusion is that IAM, compliance, and security operations need one shared control model for AI access.

From our research:

• 79% of organizations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Ultimate Guide to NHIs also shows that 97% of NHIs carry excessive privileges, which helps explain why unsanctioned access paths compound quickly.

What this signals

Shadow AI will force IAM teams to own the data path, not just the login path. If the organisation cannot mediate where a prompt or upload goes, it does not really control the identity interaction. The next maturity step is to treat AI access as a routed, policy-checked transaction that sits inside the same governance model as other high-risk non-human access.

The operational signal is that audit teams will increasingly ask for proof of AI request logging, not just acceptable-use training. Programmes that can show route-level enforcement, identity binding, and evidence capture will be better positioned to satisfy SOC 2 and HIPAA expectations without resorting to blanket bans.

Policy-based AI mediation is becoming a boundary concept for regulated access. It describes the shift from static allowlists to request-time enforcement across identity, device, and destination. For practitioners, that means the control discussion moves from awareness campaigns to architecture, which is where it belongs.

For practitioners

• Map approved AI use paths Identify every sanctioned AI service, then bind each one to enterprise identity, device trust, and policy enforcement before data can be entered or uploaded.
• Block consumer AI pathways for regulated data Prevent uploads, copy-paste workflows, and browser access to unsanctioned AI services from systems that handle PHI or audit-scoped data.
• Require audit-ready logs for AI activity Log who accessed which service, when the access occurred, what data was transferred, and which policy decision allowed or denied the request.
• Review third-party AI use as a live exposure Treat bottom-up adoption as an ongoing discovery problem and feed findings into IAM, risk, and compliance review cycles.
• Separate productivity from policy exception Allow AI use only where the request can be mediated in real time, instead of relying on training or acceptable-use language alone.

Key takeaways

• Shadow AI turns everyday productivity choices into governance failures when AI access is outside identity and policy control.
• The key evidence problem is loss of logs, route context, and third-party oversight, which undermines SOC 2 and HIPAA accountability.
• Teams need request-layer enforcement for approved AI use paths, because identity-aware mediation is the only reliable control boundary.

Key terms

• Shadow AI: Shadow AI is the use of AI tools without approval, visibility, or control from the organisation’s security and compliance functions. It becomes an identity governance issue when users access external models through consumer accounts or unmanaged workflows that bypass logging, policy enforcement, and third-party review.
• Request-layer enforcement: Request-layer enforcement means evaluating a transaction at the moment a user tries to send data, call a service, or access a route. In regulated AI use, it is the control point that can apply identity, device, destination, and content rules before sensitive information leaves approved systems.
• Audit evidence: Audit evidence is the record that proves a control existed and operated as intended. For shadow AI, that includes who accessed a service, when the access occurred, what data moved, and which policy allowed or denied the request. Without that record, compliance becomes difficult to defend.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: How Shadow AI Impacts SOC 2 and HIPAA, and What to Do About It. Read the original.