Data Masker Protocol

This skill prevents sensitive production data (PII, PHI, financial records) from leaking into lower environments (staging, development, testing). It analyzes schemas and generates idempotent masking scripts.

Core assumption: Developers need realistic data to fix bugs, but giving them real user emails, passwords, or credit card numbers violates GDPR/KVKK and Zero Trust principles.

0. Context Intake

Before designing, make sure you have the inputs below. Read the previous workflow step's artifact first if it exists. Ask only for what is missing, in a single message, and state any assumption you make instead of blocking.

• Engine and the tables in scope, or permission to scan the schema.
• Purpose of the copy (staging, analytics, vendor sharing) and applicable regulation (GDPR, KVKK, HIPAA).
• Columns that must stay joinable or realistic (deterministic masking).

1. PII Detection (Static vs Dynamic)

• Default (Static): Analyze based on provided .sql, schema files, or DDL text.
• Dynamic (On-Demand): Only connect to a live database to sample data or infer column contents if explicitly requested by the user.
• When given a table structure, automatically flag high-risk columns:
  • 📛 Direct Identifiers: email, ssn, tc_kimlik, phone, ip_address, mac_address.
  • 💳 Financial: credit_card, iban, balance, salary.
  • 🩺 Health/Personal: birth_date, blood_type, address, location_lat_lon.

2. Masking Strategy Selection

Do not just overwrite everything with 'REDACTED'. Choose the right mathematical mutation to keep the data realistic for QA testing:

Strategy 1: Deterministic Substitution (Fake Data)

• Best for: Names, Emails.
• Why: To make the UI look normal. john.doe@example.com becomes x8f9.mask@test.local.

Strategy 2: Partial Redaction

• Best for: Credit Cards, Phone Numbers.
• Why: +1 (555) 123-4567 becomes +1 (555) ***-**67. Devs can still test formatting validations.

Strategy 3: Variance / Shuffling (Jittering)

• Best for: Dates, Salaries.
• Why: salary: 105,000 -> add +/- 20% random variance -> 91,200. Keeps statistical distribution intact without revealing the exact amount.

Strategy 4: Hashing / Nullification

• Best for: Passwords, API Tokens.
• Why: Replace all passwords with a known development hash (e.g., password123) so devs can log in as any test user without knowing the real user's password.

3. Output Generation

Provide an executable SQL script that can be run on a cloned staging database.

Outputs. In file mode — the user wants artifacts, or this skill runs as a step of an ecosystem workflow — write both files below to docs/database-report/. In inline mode — a quick question — answer in the chat and end with the JSON below as a Handoff block instead of creating files.

1. Human-Readable Markdown (docs/database-report/data-masking-report.md)

### 🛡️ PII Discovery
- **Risk Level: HIGH** (Found emails, phones, and hashed passwords).

### 🛠️ Masking Execution Script (PostgreSQL)
```sql
-- Disable triggers temporarily to speed up the masking
ALTER TABLE users DISABLE TRIGGER ALL;

-- Masking `users` table
UPDATE users SET
  -- Strategy: Deterministic Substitution
  email = 'masked_' || id || '@sandbox.local',
  first_name = 'User_' || substring(md5(random()::text) from 1 for 6),
  last_name = 'Test',
  -- Strategy: Partial Redaction
  phone_number = concat(left(phone_number, 3), '***', right(phone_number, 2)),
  -- Strategy: Known Dev Value
  password_hash = '$2b$10$dev_password_hash_xyz';

-- Re-enable triggers
ALTER TABLE users ENABLE TRIGGER ALL;
```

2. Machine-Readable JSON (docs/database-report/data-masking-output.json)

{
  "skill": "data-masker",
  "pii_found": ["email", "phone_number", "password_hash"],
  "masking_strategies_applied": {
    "email": "Deterministic Substitution",
    "phone_number": "Partial Redaction"
  },
  "sql_script_generated": "UPDATE users SET email = ..."
}

When to Skip

• The dataset is already synthetic, or no copy of production data leaves the production boundary.

Guardrails

• Never Mask In Place: Run masking scripts only on a restored copy, never on the production database itself, and confirm the target connection with the user before executing (@checkpoint-guardian when installed).
• Performance: Bulk UPDATE on 10 million rows will overwhelm WAL logs. If the table is massive, suggest the CREATE TABLE AS SELECT (CTAS) strategy instead of UPDATE.
• Referential Integrity: If email is used as a Foreign Key (Anti-pattern, but it happens), masking it will break relationships. Detect FKs before masking.
• Irreversibility: Ensure the masking SQL uses one-way functions. Randomization seeds should not be deterministic.

🔗 Next Steps & Handoffs

Ecosystem: @ecosystem-database — Database Domain.

Workflows:

• Compliance & Lineage Flow (db-compliance, step 2 of 2): last step → once it passes, complete the workflow and report the outcome.

Direct handoffs:

• @seed-data-generator — Masked data should be replaced by synthetic fixtures.

Handoff contract: pass results to the next skill through docs/database-report/data-masking-output.json with the fields skill, workflow, created_at, inputs, summary, and next (the handoff contract of @ecosystem-database). If a next skill is not installed, continue with its step from the ecosystem map, or install it with npx skills add fatih-developer/fth-skills --skill <name> after the user agrees.