AI Prompt Privacy Auditor
Scans prompts for Personally Identifiable Information (PII) such as emails, phone numbers, API keys, SSNs, and credit cards before sharing with AI services.
AI Prompt Privacy Auditor
Scan your prompts for PII, API keys, and sensitive data before sending them to LLM providers.
Privacy Standard: Enterprise LLM deployments often leak PII via "in-context" data. This auditor uses deterministic regex patterns to detect typical leaks like SSNs and API keys which form the base for GDPR Article 32 security controls.
Enter text or code on the left to start the privacy audit.
Why Pasting PII Into LLM Prompts Is a GDPR Article 32 Risk
GDPR Article 32 requires organisations to implement appropriate technical measures to ensure security of personal data processing. When a developer or analyst pastes a real customer record, support ticket, or internal document into an LLM interface, they are initiating a data transfer to a third-party processor — the LLM provider. Most enterprise LLM API agreements do not guarantee that prompt inputs are excluded from model training data unless a Data Processing Agreement with explicit training opt-out provisions is in place. Even with such agreements, prompt data transits the provider's infrastructure and is processed in their environment. If that data includes names, SSNs, credit card numbers, API keys, or email addresses, the transfer constitutes personal data processing under Article 4(2) GDPR. Failure to prevent unauthorised transmission of personal data to third parties is an Article 32 violation that carries fines up to 2 percent of global annual turnover under Article 83(4). This tool is designed to catch PII before it leaves your browser — not after.
How the Six Detection Patterns Work
The auditor runs six deterministic regex patterns against your prompt text, all executing locally in your browser with no network requests. Credit card detection uses a Luhn-adjacent grouping pattern matching 16-digit sequences in common dash, space, and continuous formats, returning 92 percent confidence to account for edge cases where numeric sequences are not financial data. SSN detection uses the full exclusion pattern defined by the US Social Security Administration — excluding 000, 666, and 900-series prefixes and 00 group numbers — achieving 99 percent confidence. API key and secret detection targets strings following common key-value assignment patterns with a minimum 20-character alphanumeric secret, covering AWS access keys, Bearer tokens, and generic API key assignments with 85 percent confidence due to variable formatting conventions. Email addresses are matched against RFC 5322 simplified pattern with 95 percent confidence. US phone numbers are matched across ITU-T E.164 and NANP formats including country code prefix, parenthetical area codes, and dot-separated styles at 88 percent confidence. IP addresses match all four IPv4 octets within valid range bounds (0–255) at 80 percent confidence, accounting for version numbers and port references that may resemble but are not IP addresses.
How the Risk Score Is Calculated
The tool assigns each detection category a severity tier based on regulatory exposure and identity theft potential. Critical tier (credit cards, SSNs, API keys) carries a 50-point weight per detection. High tier (email addresses, phone numbers) carries a 25-point weight per detection. Medium tier (IP addresses) carries a 10-point weight per detection. The final risk score is: minimum of 100 and the sum of (critical count × 50) plus (high count × 25) plus (medium count × 10). This formula reaches the maximum score of 100 with two critical detections alone, or one critical plus two high detections. A score below 25 is Low risk — the prompt contains at most one medium-severity detection. Scores of 25 to 49 indicate Medium risk — typically one or more high-severity detections requiring review. Scores of 50 to 74 indicate High risk — at least one critical detection or multiple high-tier items requiring immediate remediation before the prompt is shared. Scores of 75 and above are Critical — multiple high-severity items or any combination that creates compound identity or credential exposure risk.
Frequently Asked Questions
Commonly Asked Questions
- Does this tool send my prompt text to any external server?
- No. All six detection patterns run as JavaScript regex operations inside your browser's local runtime. No network request is made when you click Audit. Your prompt text never leaves your device. This is verifiable by opening your browser's network inspector before running the audit — you will see zero outbound requests triggered by the analysis.
- What does a Critical risk score mean under GDPR?
- A Critical score means your prompt contains at least two items classified as high-severity PII — typically combinations of SSNs, credit card numbers, or API credentials. Transmitting this prompt to any external LLM API without a valid Data Processing Agreement in place would constitute unauthorised personal data transfer under GDPR Article 28. If your organisation has a DPA with your LLM provider that includes training opt-out, transmission may be permissible but should still be logged as a data processing activity under Article 30.
- Why is SSN detection rated at 99% confidence but API key detection at 85%?
- SSN format is precisely defined by the US Social Security Administration with documented exclusion zones for invalid prefixes and group numbers. The regex implements all exclusions, leaving very little ambiguity. API key format has no universal standard — different providers use different prefix conventions, lengths, and character sets. The 85 percent confidence for API keys reflects cases where a long alphanumeric string follows a key-value assignment pattern but may be a hash, UUID, or non-credential identifier rather than a live credential.
- What PII does this tool not detect?
- The tool does not detect: names and surnames (too many false positives with common words), UK National Insurance numbers, EU national ID formats, IBAN or SWIFT codes, passport numbers, or unstructured address data. It also does not perform semantic analysis — it cannot detect PII disguised through substitution or identify a customer by a combination of non-PII attributes. For comprehensive data classification across structured datasets, a dedicated DLP solution with named-entity recognition is more appropriate.
- How should I use the CSV export for compliance documentation?
- The CSV export lists each detected item with its type, the matched value, severity tier, and confidence percentage. This file serves as evidence of a pre-transmission PII review. If your organisation maintains an Article 30 Record of Processing Activities, the CSV can be attached as documentation that a manual review step occurred before a specific prompt was submitted to an external processor. Store exports with the date, the LLM provider used, and the outcome (whether the prompt was modified, abandoned, or transmitted with DPA coverage).
- Does this tool replace a formal Data Protection Impact Assessment?
- No. A DPIA under GDPR Article 35 is a structured assessment of a processing activity covering necessity, proportionality, risk to data subjects, and mitigation measures. This tool addresses one narrow technical control — detecting PII in a specific text input before transmission. It is a preventive measure, not an assessment of the broader processing activity. If your organisation uses LLMs to process personal data at scale, a DPIA covering that activity is separately required regardless of whether individual prompts are screened.
- What should I do if I find PII in a prompt I have already submitted?
- First, check your LLM provider's data retention and training policy. OpenAI, Anthropic, Google, and Azure OpenAI each have different default retention periods and opt-out mechanisms. If the transmission constitutes a personal data breach under GDPR Article 4(12) — meaning it is likely to result in risk to the rights and freedoms of natural persons — your organisation may have a 72-hour notification obligation to your supervisory authority under Article 33. Consult your Data Protection Officer before determining whether notification is required.