AI Prompt Risk Scanner: A Free Tool To Check What Your AI Prompts Actually Expose

77% of employees using unauthorized AI tools admit to pasting sensitive business data into the prompts (Cloud Radix). The data class distribution is rarely surveyed because the prompts themselves are invisible to most security tools. The AI Prompt Risk Scanner exists to make that distribution visible without requiring the organization to deploy production inspection infrastructure first. Paste a prompt, paste a batch, or upload a file. The scanner reports what an inline inspection layer would detect.

I want to walk through what the scanner inspects, how the detection rules work, what the output means, and how to use the results to size the inspection problem in your environment.

What the scanner inspects

The scanner applies the same detection rule families a production inspection layer would apply to prompt traffic. The families cover personally identifiable information, protected health information, payment data, secrets and credentials, source code with sensitive patterns, financial non-public information, and customer-identifying business data.

PII detection covers US Social Security Numbers, EU national identifiers, driver's license patterns by jurisdiction, passport patterns, dates of birth in combination with names, addresses in combination with names, phone numbers in combination with names, and email addresses in combination with corporate signals. The detection logic distinguishes a phone number in a signature block (low risk in most contexts) from a phone number in a list of patient or customer contacts (high risk).

PHI detection covers the 18 HIPAA identifiers plus diagnostic codes (ICD-10, CPT), medication names in combination with dosages, lab result patterns, and clinical narrative patterns that imply individual patient context. The detection is calibrated for clinical text where the same word can be a generic medical term or a specific patient reference depending on the surrounding context.

Payment data detection covers PAN (primary account number) patterns by issuer, expiration date in combination with PAN, CVV patterns, and bank account routing patterns. The detection includes the Luhn check for PAN validation.

Secrets detection covers API keys, cloud provider credentials, private keys, OAuth tokens, database connection strings, and the patterns major secret-scanning tools recognize. The detection includes high-entropy string heuristics for non-pattern-matched secrets.

Source code detection covers patterns that suggest the code itself contains secrets (hardcoded keys in code samples), proprietary algorithms (uncommonly-named identifiers in combination with novel code patterns), or trade-secret-class implementation detail (specific patterns associated with internal infrastructure).

Financial NPI detection covers patterns associated with pre-announcement earnings data, M&A material non-public information, and other regulated financial data classes. The detection is heuristic because the data class is contextual rather than pattern-based.

Customer-identifying business data detection covers patterns where customer names appear in combination with account references, contract values, internal notes about the customer relationship, or other context that would qualify as confidential business information under most enterprise data classifications.

How the rules work

The rules combine pattern detection (regular expressions and dictionary lookups), contextual analysis (the data class is identified by the surrounding context, not just the pattern), and entropy analysis (high-entropy strings flagged as likely secrets even when they do not match a known pattern).

False-positive management is the design challenge for production rule sets. A rule that fires on every email address would alert on every email containing a signature. A rule that requires email plus corporate signals plus a sensitive context (recipient list, customer reference) catches the actual exposure cases.

The scanner runs the standard rule set in inspection mode without applying any organization-specific policy. The output is "here is what was detected." A production inspection layer adds organization-specific policy on top: which data classes are prohibited, which are allowed under which destinations, which trigger redaction rather than block.

The detection rules are not bulletproof. New data classes appear (a novel customer-identifier format, a regulatory category that did not exist last year). Adversarial prompts can encode sensitive data in ways that evade pattern detection. The rule set covers the majority of real-world exposures observed in production deployments. Organizations should treat the scanner output as a baseline rather than a complete picture.

What the output means

The scanner returns a structured result for each prompt. The result includes the detected data classes, the locations within the prompt where each detection fired, the confidence level for each detection, and the regulatory exposure that the detected data class implies.

The regulatory exposure mapping connects the detected data class to the regulations that apply. PHI detection maps to HIPAA. PII detection maps to GDPR (for EU subjects), CCPA, and various state laws. Payment data maps to PCI DSS. NPI maps to MiFID II, Reg FD, and equivalents. The mapping is not a legal opinion; it is a starting point for the compliance team to evaluate further.

The policy outcome column shows what a standard production policy would do with the prompt. Common outcomes include allow (no detection), redact (substitute non-sensitive tokens for the detected content), block (the prompt cannot proceed), or escalate (the prompt requires human review before proceeding). The outcomes are the default policy responses. Organizations tune them based on use case.

The output also includes aggregate metrics across a batch. If you upload 100 prompts, the scanner reports how many contained each data class, how many would be blocked under standard policy, how many would be redacted, and the distribution of regulatory exposures. These aggregate metrics are usually more useful for sizing than the individual results.

How to use the results

Three common use cases for the scanner output have emerged from how teams have used it so far.

The first use case is sizing the inspection problem. A security team that suspects shadow AI risk but cannot quantify it can collect a sample of prompts from one team's AI usage (with appropriate consent) and run the sample through the scanner. The output tells the team what data classes are appearing, how often, and what regulatory exposure that implies. The number is usually larger than the team expected. The output becomes the business case for production inspection infrastructure.

The second use case is calibrating policy. A team that has already decided to deploy inline inspection can use the scanner output to set the policy thresholds. If 30% of legitimate engineering prompts contain source code, the team knows that a blanket block on source code will interrupt that team. The policy becomes "block source code with embedded secrets, allow source code without secrets." The output drives the policy design.

The third use case is the spot check after deployment. After the production inspection layer is operating, periodic spot checks with the scanner verify the production rules are catching what they should. A scanner detection that the production layer missed is a rule tuning input. A production block that the scanner agrees with is a positive control.

What the scanner does not do

The scanner is an inspection tool. It does not block, redact, or enforce anything. The prompts you submit are inspected and reported on. The scanner does not modify the prompts, route them to an AI provider, or take any action other than producing the inspection report.

The scanner does not retain submitted content. The prompts are inspected in memory and discarded after the report is produced. The aggregate metrics across submissions are retained for service operation; the prompt content is not.

The scanner is not a substitute for production inspection infrastructure. It runs on a sample at a moment in time. Production AI traffic is continuous, high-volume, and produces audit evidence that has to be retained for regulatory periods. The scanner is the diagnostic tool; the production layer is the operational control.

DeepInspect

This is exactly what DeepInspect does, at production scale. DeepInspect sits inline between authenticated users and any HTTP-based LLM endpoint. The same detection rule families the scanner applies run in DeepInspect's production inspection layer, augmented with organization-specific policy and tuned to the customer's data classes and false-positive tolerance.

Every request produces a per-decision audit record containing the verified identity, the timestamp, the data class detected, the policy version, the outcome, and a tamper-evident signature. The records support EU AI Act Article 12, HIPAA audit control, DORA evidence, and the broader audit obligations covered elsewhere in the engagement.

The scanner is the diagnostic step. DeepInspect is the operational control. For organizations whose scanner results suggest exposure that exceeds the current monitoring posture, the next step is a conversation about what production inspection at the AI request boundary looks like in your environment. Book a demo today.