AI Shadow / External AI Data Share

Marks the context of data being submitted to external / unapproved AI services (shadow AI destination domains) so existing PII/secret SITs can be re-scoped to it. Detection of the sensitive data itself is delegated to those SITs via the ai-threat-classifiers collection; this pattern supplies the external-AI destination context signal.

Type

regex

Confidence

low

Confidence justification

Low by design. This pattern only asserts an external-AI destination context, not the presence of sensitive data; the sensitive-data verdict is delegated to existing PII/secret SITs re-scoped via the collection. The domain allow-list will diverge per tenant (approved vendor AI tools and internal AI gateways are the named FP traps), so the context signal alone is necessary-not-sufficient.

Jurisdictions

global

Regulations

OWASP LLM Top 10 2025, NIST AI RMF GenAI Profile

Frameworks

ISO 27001

Data categories

emerging, security

Risk rating

7

Platform compatibility

Purview: Compatible, GCP DLP: Compatible, Macie: Compatible, Zscaler: Compatible, Palo Alto: Degraded, Netskope: Unsupported

Pattern

(?i)\b(?:chatgpt\.com|chat\.openai\.com|claude\.ai|gemini\.google\.com|perplexity\.ai|copilot\.microsoft\.com)\b

Corroborative evidence keywords

paste, upload, share, submit, [object Object], artificial intelligence, [object Object], large language model, Copilot, chatbot, assistant, agent, prompt, system prompt, tool call, completion, model

Proximity: 300 characters

Should match

• The browser history contains chatgpt.com. — Low-tier probe - consumer-AI destination without a transfer action
• Uploaded a draft to claude.ai for review. — Medium-tier probe - transfer action without a named sensitive asset
• Pasted the customer list into chatgpt.com to summarise it. — High-tier probe - transfer action plus a sensitive business asset

Should not match

• We use the internal AI gateway for all approved workloads. — Approved internal AI tool (FP trap)
• The approved vendor AI tool runs inside our tenant boundary. — Approved vendor AI tool, no external consumer-AI domain (FP trap)
• Our team reviewed the data on the corporate intranet portal. — Internal portal, no external AI destination domain
• A public article lists chatgpt.com and claude.ai as consumer AI websites. — Public directory prose without a transfer action
• Approved vendor workflow: uploaded a confidential contract to claude.ai inside our tenant boundary. — Explicitly approved tenant-bounded service
• Template example: pasted the customer list into chatgpt.com. — Explicit template contains otherwise high-tier evidence

Known false positives

• The external-AI destination domain allow-list diverges per tenant; approved vendor AI tools and sanctioned internal AI gateways are legitimate and should not be flagged when referenced in policy or onboarding documents. Mitigation: Maintain a tenant-specific allow-list and treat this domain match as context only; delegate the sensitive-data verdict to the existing PII/secret SITs re-scoped via the ai-threat-classifiers collection.
• Security awareness training, acceptable-use policies, and incident write-ups frequently mention consumer-AI domains (e.g. "do not paste data into chatgpt.com") as warnings rather than actual data egress. Mitigation: Require co-occurrence with a regulated-data SIT match plus an action marker (paste, upload, share, submit) within the proximity window before raising a verdict.

Collections

• AI Threat Classifiers