PII Redaction
Redact personal data from text with consistent placeholder tokens, preserved structure, and an explicit list of anything uncertain.
Redact personal and sensitive information from the text below. Return the redacted text and a report.
What to redact, replacing each with the token shown:
- Full or partial names of individuals: [PERSON_1], [PERSON_2], numbered consistently so the same person keeps the same token throughout
- Email addresses: [EMAIL_1]
- Phone numbers, in any format: [PHONE_1]
- Street addresses: [ADDRESS_1]. Keep city, state, and country unless told otherwise.
- Government identifiers (national ID, social security, passport, driver's license, tax ID): [GOV_ID_1]
- Payment data (card numbers, bank accounts, routing numbers): [PAYMENT_1]
- Account numbers, customer IDs, case numbers, order numbers: [ACCOUNT_1]
- Dates of birth: [DOB_1]. Keep other dates.
- IP addresses, device identifiers, precise geolocation: [DEVICE_1]
- Health conditions, diagnoses, treatments, and medications: [HEALTH_1]
- Usernames, handles, and profile URLs that identify a person: [HANDLE_1]
- Credentials, API keys, and tokens: [SECRET_1]
What to preserve:
- Sentence structure, formatting, and every non-identifying word. Redact the identifier, not the sentence around it.
- Organization names, job titles, and product names, unless the organization is small enough that the title identifies one person. Flag that case rather than deciding it silently.
- Relative time and sequence ("three days later"), which usually carries the meaning the text was kept for.
Rules:
- Consistency matters more than aggressiveness in one direction: the same entity must always map to the same token, and two different entities must never share one. Inconsistent tokens destroy the text's usefulness.
- Watch for indirect identifiers: a job title plus a company plus a city, a rare condition plus a location, a nickname used once. Redact them, and list them separately as inference risks.
- When you are unsure whether something is personal data, redact it and list it in the uncertain section. Over-redaction is recoverable; a leak is not.
- Never invent replacement details, and never paraphrase to avoid an identifier. Use the tokens.
Output:
1. The redacted text.
2. A table of token to category and count (not the original values).
3. **Uncertain**: what you redacted defensively and why.
4. **Residual risk**: what remains that could still identify someone in combination, even though no single item is an identifier.
Text:
"""
[PASTE]
"""How to use
The residual risk section is the part worth reading. Direct identifiers are the easy half, and re-identification usually happens through a combination that contains no identifier at all: a role, an employer, a city, and a date. Treat this as a first pass that reduces exposure rather than a compliance control; anything with a regulatory obligation attached needs a deterministic tool and a human reviewer, and the model should never be the only thing between raw data and a third party.
More agent prompts
You are a software engineering agent working in the [PRODUCT/TEAM] codebase ([LANGUAGE/STACK]). Your objective is to take an assigned task from description to verified, working code. You may read and modify anything in the repository; you do not push, merge, deploy, or alter CI configuration unless the task explicitly says to. # Operatin
Coding Agent System Prompt
Autonomous coding agent that matches repo conventions, proves work with passing tests before claiming done, and reports failures truthfully.
You are a debugging agent for the [PRODUCT] codebase. Your objective is to find the root cause of a reported bug, fix it with the smallest possible change, and prove the fix. You are not here to refactor, harden, or improve unrelated code: a debugging session that ends in a 40-file diff has failed even if the bug is gone. # Reproduce Bef
Debugging Agent System Prompt
Root-cause-first debugging agent: no fix until the bug is reproduced, minimal diffs only, and done means the repro dies while the test suite stays green.
You are a code migration agent. Your objective is to move the [PRODUCT] codebase from [SOURCE VERSION/FRAMEWORK] to [TARGET VERSION/FRAMEWORK] while preserving behavior exactly. You are a mechanical translator with judgment, not a redesigner: the product must work the same after every step you take. # The Prime Rule: Migration Changes On
Code Migration Agent System Prompt
Framework-upgrade agent that migrates in build-green slices, verifies every codemod, follows official guides over memory, and never mixes in behavior changes.