When a developer pastes a deployment script into ChatGPT, they usually know what they’re asking about. What they don’t know is what else hitched a ride: a database connection string three lines above, an internal API key from a comment block, a staging URL that resolves only inside their VPN. The AI interface transmits the full text, sensitive data included, directly to a third-party server.
Hosted AI tools are not the only option. Local models like Ollama can keep data entirely on your own machine, and some enterprise deployments offer strict no-retention guarantees.1 But for the vast majority of cloud-based AI services, every character you paste is sent to a provider’s infrastructure and processed there. For anyone handling customer data, internal systems, or regulated workloads, that’s a risk worth mitigating. And the fix doesn’t require switching providers or running your own model.
CapyToolkit’s browser-based security tools that run entirely on your device without cloud processing include a PII Scrubber because the fix is simple in concept but easy to skip in practice: find the sensitive data before the AI does, replace it with a harmless token, and swap it back after the response lands. The entire process runs in your browser with no account required. The scrubbing itself generates no network traffic, though the page must be loaded from a server first. The following walkthrough covers how the tool works, what it catches, and how to fold it into your daily workflow without slowing down.
The Problem: Every AI Prompt Can Expose Sensitive Data
Every time you paste a prompt into ChatGPT, the text goes to OpenAI’s provider infrastructure.2 Claude sends prompts through Anthropic’s API infrastructure.3 Gemini sends prompts through Google Cloud’s AI infrastructure.4 For a focused workflow on scrubbing PII and sensitive tokens from prompts before sending them to ChatGPT, the step-by-step process takes under a minute. That transmission includes the hidden sensitive data you did not mean to send: internal IP addresses buried in server configs, API keys tucked inside code snippets, customer emails in support templates, AWS credentials in deployment scripts, and internal domain names from architecture docs.
A developer pasting a deployment script into ChatGPT might not realize they have also included the database connection string sitting three lines above the command they actually wanted help with. Scrubbing code snippets before sending them to any AI tool catches the API keys, connection strings, and credentials that are easy to overlook when you are focused on the logic problem, not the surrounding context. A support agent copying a ticket template could inadvertently send a spreadsheet of customer emails along with their question. The leak is almost always accidental, and it happens because most AI interfaces present a single text box with no filtering or awareness of what is inside the content.
The OWASP Top 10, specifically its Cryptographic Failures category (formerly Sensitive Data Exposure), highlights the risks of processing and transmitting sensitive information through external systems.5 See the OWASP Top 10 risk classification covering sensitive data exposure and cryptographic failures for the full list of vectors. You cannot “unsee” data once it has been sent to an external AI provider’s infrastructure; even providers with strong privacy policies have breach surfaces and insider risk. A single leaked API key or customer email in a training pipeline can trigger regulatory exposure, reputational damage, or both. These are documented breach vectors with real regulatory consequences, not hypothetical scenarios.
The shift-left approach fixes this at the source: scrub before you send, not after. Treat prompt sanitization the same way you treat input validation for any other system boundary, because in practice, that is exactly what it is.
How CapyToolkit’s PII Scrubber Works Without an Internet Connection
Building on this shift-left philosophy, CapyToolkit’s PII Scrubber executes data protection directly at the source by operating as a 100% client-side JavaScript application. All detection types and the tokenization logic run entirely in your browser’s memory. No outbound network requests occur during scrubbing. Once the page is loaded, the tool works without any network activity; the only requests your browser makes are from the initial page load. You can verify this yourself by opening DevTools, switching to the Network tab, and watching for activity as you type.
The tokenization approach assigns an incrementing token number to each unique value it finds within a session. The same sensitive value always maps to the same token within a single scrub-restore cycle, which is what makes the two-way restore workflow possible. However, token numbering resets on each page load, and the same value in a different prompt order may receive a different token number.
This simple substitution means anyone with the scrubbed text and the mapping file can reconstruct the original data. Without the mapping, recovering the original values would require guessing or brute-forcing, which is harder for high-entropy data like API keys but easier for predictable formats like standard IP ranges.
Why Offline Scrubbing Matters for Sensitive Workflows
Cloud-based PII redaction tools still transmit your data to their servers for processing, which defeats the purpose for truly sensitive information. You are trading one exposure for another.
Working in air-gapped or restricted corporate environments makes this even more important. External API calls are often blocked or audited in those settings, and sending raw PII to any cloud service, even a redaction one, can violate internal policy.
Compliance frameworks add another layer. GDPR Article 25 includes data minimization requirements that encourage keeping certain data types off third-party servers when a local alternative exists.6 HIPAA’s minimum necessary standard similarly limits protected health information to what is needed for the intended purpose.7 NIST Special Publication 800-122 guidance on protecting sensitive information from unnecessary exposure reinforces this principle. Running the entire detection pipeline in your browser helps satisfy that principle, though full compliance depends on your broader organizational policies and data handling practices. While several open-source community projects have experimented with browser-based redaction, CapyToolkit’s PII Scrubber that detects 22+ sensitive data types and replaces them with tokens entirely in your browser goes further by requiring no installation, no accounts, and no cloud processing of user data.
The Two-Mode Architecture: Scrub Tab and Restore Tab
The tool splits cleanly into a Scrub tab and a Restore tab. The Scrub tab handles detection, tokenization, and downloading the variables mapping file. The Restore tab re-injects original values into AI responses using that same file.
This two-pass design separates CapyToolkit from single-direction “find and replace” redaction tools. Most alternatives stop at masking. CapyToolkit lets you get the real data back after the AI finishes, which makes it usable in production workflows rather than just security demos.
The 22+ Sensitive Data Types the Scrubber Detects
The tool covers 22+ practical detection types that span the most common categories of accidental data exposure in developer and operations workflows. It is not exhaustive: it does not detect names, street addresses, free-form passwords, or proprietary business logic. What it does cover, it covers well: infrastructure identifiers (IPs, internal domains), structured credentials (API keys, AWS keys, GitHub tokens, Slack tokens, Stripe keys, private keys, and more), personal identifiers (email addresses, phone numbers, SSNs, and IBAN bank account numbers), and financial data.8 Each detection type uses targeted regex patterns with incrementing token numbering to guarantee uniqueness.
The 22+ Detection Types: What the Scrubber Catches
| Detection Type | Token Format | Example Input | Real-World Use Case |
|---|---|---|---|
| IPv4 addresses | [IP_1], [IP_2] | 192.168.1.1 | Internal server addresses in deployment notes |
| IPv6 addresses | [IP6_1] | 2001:db8::ff00:42 | Modern cloud infrastructure configs |
| Email addresses | [EMAIL_1] | [email protected] | Customer contacts in support prompts |
| Slack tokens | [SLACK_1] | xoxb-abc-123… | Bot and user OAuth tokens in CI configs9 |
| Stripe keys | [STRIPE_1] | sk_live_abc… | Payment API credentials in backend configs10 |
| API keys | [API_1] | sk-abc123… | OpenAI and similar generic service keys |
| AWS keys | [AWS_1] | AKIAIO4F5…MPLE | AWS credentials in deployment scripts11 |
| GitHub tokens | [GH_1] | ghp_16charact…Here | Personal access tokens in CI/CD configs12 |
| GitLab tokens | [GLPAT_1] | glpat-abc… | GitLab PATs in pipeline configurations |
| Google API keys | [GKEY_1] | AIzaSyAbc… | Google Cloud credentials in app configs13 |
| SendGrid keys | [SENDGRID_1] | SG.abc…xyz… | Email delivery API credentials |
| Twilio SIDs | [TWILIO_1] | ACabc123… | SMS API credentials in messaging configs14 |
| NPM tokens | [NPM_1] | npm_abc… | Package registry auth tokens in CI |
| JWT tokens | [JWT_1] | eyJhbGci… | Auth tokens appearing in API docs and logs15 |
| Database URLs | [DBURL_1] | postgres://user:pass@host | Connection strings in config files |
| Private keys | [KEY_1] | -----BEGIN RSA PRIVATE KEY----- | SSH keys and PEM files in docs16 |
| Credit card numbers | [CC_1] | 4111 1111 1111 1111 | Test payment data in documentation |
| Internal domains | [DOMAIN_1] | admin.corp.internal | Staging and internal service URLs |
| Social Security Numbers | [SSN_1] | 123-45-6789 | SSNs in HR documents and payroll data |
| Phone numbers | [PHONE_1] | +1 (555) 123-4567 | Contact numbers in customer records |
| IBAN bank account numbers | [IBAN_1] | GB29NWBK60161331926819 | Bank accounts in financial documents17 |
What Makes These Detection Types Practical
The list targets real scenarios where data leaks through AI prompts. During routine debugging, internal IPs frequently show up in infrastructure runbooks. Because developers often copy config files wholesale, API keys easily slip into prompts. Credit card numbers land in documentation examples, where they persist long after the test transaction clears. Each type maps to a documented breach vector. For a complete classification of sensitive data categories, see the NIST guidance cited above.
The detection logic is regex-based and runs locally. No data leaves the browser for pattern matching, and no cloud service needs to classify your text. The regex patterns are designed to catch common formats, though regex-based detection has inherent limitations. It can produce false positives (e.g., numbers that match credit card patterns) and false negatives (e.g., obfuscated keys or unusual formats). Review each detection before relying on it.
Step-by-Step: Scrubbing a Prompt Before Sending It to an LLM
The core workflow breaks down into five steps: paste, review, download, copy, and send. No account is required at any stage.
Pasting and Detecting Sensitive Data
Paste your original prompt or code into the Scrub tab’s input box. Detection happens in real time; watch the Variables section populate as the tool identifies sensitive patterns. Each unique value gets its own numbered token, so two different IP addresses in the same prompt become [IP_1] and [IP_2] respectively.
Review each detection in the JSON mapping to verify accuracy before proceeding. If the tool flags something that is not actually sensitive, make a note of the false positive. The regex patterns are conservative and occasionally catch formatted strings that look like sensitive data but are not.
Downloading Variables and Sending the Scrubbed Prompt
Click “Download .json” or “Download .csv” to save the mapping file locally. This file is the only thing that lets you restore the original values later, so treat it with the same care you would give the original sensitive data.
Copy the scrubbed output from the Scrubbed Output textarea and paste the clean version into your AI tool of choice, whether that is ChatGPT, Claude, Gemini, or a custom API endpoint. The AI sees only the tokens, provided the scrubber caught all sensitive data in the first place. If any PII slips through undetected, it will still be present in the text the AI receives.
Restoring Original Values After Receiving the AI Response
Paste the AI’s response, which contains tokens like [IP_1], into the Restore tab. Upload or paste your previously saved variables file, then click Restore. The tool automatically swaps every token back to its original value, giving you a fully restored response ready for use in your actual workflow.
The Two-Way Restore Workflow: Getting Your Real Data Back After the AI Responds
The restore workflow is what makes this tool genuinely useful rather than just a redaction curiosity. Without it, you would need to manually reconstruct every sensitive value by cross-referencing your memory or notes against a wall of tokenized text. Imagine pasting a 2,000-word AI response back into your project and having to search for every [IP_1] and [EMAIL_3] placeholder by hand. That is not a realistic workflow.
Upload your JSON or CSV variables file, the same one you downloaded during the scrub phase, and paste the AI response into the Restore tab. Restoration is deterministic: each token maps back to exactly one original value with no ambiguity. The tool does not guess, does not prompt for confirmation, and does not skip duplicates. Every instance of [IP_1] becomes the same IP address it originally represented.
A critical security note deserves emphasis here. Anyone who possesses both the scrubbed text and your variables file can reconstruct your original data. Protect the variables file with the same level of security you would apply to the original sensitive data itself. If the file is compromised, the scrubbing provides zero protection.
Integrating Offline PII Scrubbing Into Your Daily AI Workflow
Bookmark the PII Scrubber page for one-click access before every AI session. If you use the tool regularly, the “Install App” feature adds it to your home screen for app-like access without needing a browser tab.
For teams, establish a standard workflow where all prompts pass through the scrubber before reaching shared AI tools. This is especially relevant in organizations with compliance requirements around customer data or proprietary code. CapyToolkit’s full suite of privacy tools runs entirely in the browser with no uploads and no cloud processing of user data.
Load the page once and disconnect from the internet to verify zero-network behavior. This is a useful exercise for demonstrating the security model to skeptical colleagues who assume every web tool phones home.
Pairing With Other CapyToolkit Privacy Tools
Run the Browser Fingerprint and Privacy Leak Inspector to understand what metadata your browser leaks independently of AI workflows. The inspector exposes canvas hashes, WebGL renderers, audio fingerprints, and 30 other signals that trackers exploit.
Use the EXIF and Image Metadata Scrubber to clean image attachments before describing them to an AI. Photos from phones and cameras embed GPS coordinates, device identifiers, and timestamps that AI services will ingest and potentially store.18
Verify the file integrity of your variables JSON with the File Hash Verifier before archiving it. And check URLs in prompts with the URL Parser to ensure no embedded credentials hide in query parameters before you scrub and send.
When to Use the PII Scrubber vs. Other Approaches
Choose offline scrubbing when handling proprietary code, internal infrastructure details, customer PII, or regulated data. Cloud-based redaction services are acceptable for low-sensitivity content but they defeat the purpose for genuinely confidential data.
The PII Scrubber is deterministic and local. There are no API keys to manage, no accounts to provision, no rate limits to hit, and no vendor dependency to worry about. For teams that need a consistent privacy baseline across different AI providers, this removes an entire category of supply-chain risk.
Security Considerations and Best Practices for Variable File Storage
Treat downloaded variable mapping files with the same security level as the original sensitive data they contain. A variables file is, functionally, a decryption key for your scrubbed text.
Rather than leaving mapping files exposed in your Downloads folder where background processes or unauthorized users might access them, temporarily store them in an encrypted vault and delete them immediately upon completing your restore workflow.
Be aware that the tokenization is one-way by design. If you lose the variables file, the original values cannot be recovered from the tokens alone. That is a feature, not a bug, but it means you need to manage the file lifecycle deliberately.
For highly sensitive workflows, consider running the entire scrub-restore cycle on an air-gapped machine. CapyToolkit’s scrubbing logic requires no internet connection, so once the page is loaded, an air-gapped environment eliminates any possibility of network-based data exfiltration during the scrub-restore cycle. For broader guidance on protecting sensitive data across your applications, the OWASP Top 10 covers common categories of sensitive data exposure worth understanding.
- 1.
Ollama, “FAQ,” github.com, accessed June 2026. https://github.com/ollama/ollama/blob/main/docs/faq.mdx
- 2.
OpenAI, “Business data privacy, security, and compliance,” openai.com, accessed June 2026. https://openai.com/business-data/
- 3.
Anthropic, “API and data retention,” platform.claude.com, accessed June 2026. https://platform.claude.com/docs/en/manage-claude/api-and-data-retention
- 4.
Google Cloud Documentation, “How Gemini for Google Cloud uses your data,” docs.cloud.google.com, June 2026. https://docs.cloud.google.com/gemini/docs/discover/data-governance
- 5.
OWASP Foundation, “A02:2021 Cryptographic Failures,” owasp.org, accessed June 2026. https://owasp.org/Top10/2021/A02_2021-Cryptographic_Failures/
- 6.
Regulation (EU) 2016/679, “Article 25: Data protection by design and by default,” legislation.gov.uk, accessed June 2026. https://legislation.gov.uk/eur/2016/679/article/25/adopted?view=plain
- 7.
U.S. Department of Health and Human Services, “Minimum Necessary,” hhs.gov, accessed June 2026. https://hhs.gov/hipaa/for-professionals/faq/minimum-necessary/index.html
- 8.
OWASP Foundation, “NHI2:2025 Secret Leakage,” owasp.org, accessed June 2026. https://owasp.org/www-project-non-human-identities-top-10/2025/2-secret-leakage/
- 9.
Slack Developer Docs, “Tokens,” docs.slack.dev, accessed June 2026. https://docs.slack.dev/authentication/tokens
- 10.
Stripe, “API keys,” docs.stripe.com, accessed June 2026. https://docs.stripe.com/keys
- 11.
AWS Identity and Access Management, “AWS security credentials,” docs.aws.amazon.com, accessed June 2026. https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds.html
- 12.
GitHub, “Authentication token format updates are generally available,” github.blog, March 2021. https://github.blog/changelog/2021-03-31-authentication-token-format-updates-are-generally-available/
- 13.
Google Cloud Documentation, “Manage API keys,” docs.cloud.google.com, accessed June 2026. https://docs.cloud.google.com/docs/authentication/api-keys
- 14.
Twilio, “What is a String Identifier (SID)?,” twilio.com, accessed June 2026. https://twilio.com/docs/glossary/what-is-a-sid
- 15.
M. Jones, J. Bradley, and N. Sakimura, “JSON Web Token (JWT),”
RFC 7519, IETF, May 2015. https://rfc-editor.org/rfc/rfc7519 - 16.
S. Josefsson and S. Leonard, “Textual Encodings of PKIX, PKCS, and CMS Structures,”
RFC 7468, IETF, April 2015. https://rfc-editor.org/rfc/rfc7468 - 17.
European Payments Council, “The schemes rely on global open standards,” europeanpaymentscouncil.eu, accessed June 2026. https://europeanpaymentscouncil.eu/what-we-do/epc-payment-scheme-management/schemes-rely-global-open-standards
- 18.
Adobe, “What are EXIF files and how to open them?,” adobe.com, accessed June 2026. https://adobe.com/creativecloud/file-types/image/raster/exif-file.html
