Personal Information Desensitization Audit (privacy-audit)

Purpose

Perform a personal information desensitization compliance audit on local skill packages, codebases, and data directories, producing a graded issue list and a standard audit report. Based on Chinese jurisdiction: Personal Information Protection Law (Presidential Order No. 91), Data Security Law, Cybersecurity Law (2025 Amendment), GB/T 35273-2020, GB/T 45574-2025 (effective 2025-11-01), GB/T 43697-2024, and the Administrative Measures for Personal Information Protection Compliance Audits (effective 2025-05-01). The audit is strict: any processing without clear legal basis is treated as "not permitted."

Applicable scenarios: Security check before releasing AI skills/code/documents; desensitization verification before sharing datasets; log and configuration leak investigation; compliance audit report generation. Positioning distinction: This skill is for "review/audit" (detection + grading + remediation suggestions + legal references), not for "desensitization execution." For scenarios requiring direct masking/replacement of data, use desensitization tool skills; this skill determines "whether it should be released, where violations occur, and which regulations apply." Commercial positioning (v1.2.0): Aimed at "pre-release compliance self-check for AI skills/applications," supports conversational platforms like Coze (users upload attachments or paste text for scanning, no local directory needed), can be listed as a paid skill.

Trigger Words

Desensitization audit / Privacy audit / Privacy compliance check / Compliance audit / Privacy protection audit / privacy audit / desensitization audit
Sensitive information scan / PII scan / PII scan / Sensitive field detection / Personal information scan / Data leak investigation
Scan this directory for personal information / Scan this skill for personal information
ID number scan / Check code for phone numbers / Check code for ID numbers / Bank card number leak check
Check for hardcoded keys in the repository / Check for plaintext passwords in logs / Check uploaded files for sensitive information
Does this skill leak privacy? / Can this skill be published? / Should it be desensitized before sharing? / Dataset desensitization check
Desensitization remediation suggestions / Generate a compliance audit report / Pre-release security check / Pre-listing compliance review

Environment Setup

# Dependencies: Python 3.8+, pure standard library, no third-party dependencies
export SKILL_DIR=~/.workbuddy/skills/privacy-audit   # Skill installation path
export TARGET_DIR=/path/to/target-directory           # Directory to audit (code/skill/data)
export REPORT_DIR=/path/to/report-output-directory     # Recommended outside the scan directory to avoid self-detection

Execution Process

Step 1: L1 Automated Scan (Machine First, Then Human)

# Single directory scan + JSON report
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR" \
  --rules "$SKILL_DIR/scripts/field-detection-regex-library.json" \
  --json "$REPORT_DIR/audit_result.json"

# v1.1.0 Batch directory scan (merge multiple directories) + HTML visualization report
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR_A" "$TARGET_DIR_B" \
  --rules "$SKILL_DIR/scripts/field-detection-regex-library.json" \
  --json "$REPORT_DIR/audit_result.json" \
  --html "$REPORT_DIR/audit_result.html"

Scans 17 types of sensitive fields: ID number / Phone number / Bank card number / Email / IP / Exact address / Precise geolocation coordinates / Physician name / Hospital name / Plaintext password / Medical health information / Minor information / License plate number / Passport number / WeChat ID / QQ number / Unified Social Credit Code (new in v1.1.0)
Detects 5 types of hardcoded credentials: SkillHub key / GitHub token / OpenAI key / Tencent Cloud SecretId / COS temporary credentials
Exit codes (CI-gateway compatible): 0=Pass; 1=High-risk hit (block release); 2=Medium-sensitivity hit (requires manual review)
--json: Structured report (includes scanned_roots/summary/verdict/findings, CI-consumable); --html: Self-contained visualization report (overview card + severity distribution chart + per-file grouped hit list, viewable offline)
--strict: Fail on medium hits as well; --quiet: Output only result lines

Conversational scanning (v1.2.0 new, adapted for dialog scenarios like Coze, no local directory needed):

# Single file scan (user uploaded attachment, e.g., .py/.md/.json/.txt)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --file /path/to/uploaded.py \
  --rules "$SKILL_DIR/scripts/field-detection-regex-library.json" \
  --json "$REPORT_DIR/audit_result.json"

# Text content scan (user pasted code/text snippet)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --text "audit-text-content" \
  --rules "$SKILL_DIR/scripts/field-detection-regex-library.json"

# Stdin scan (pipe input)
echo "audit-text" | python3 "$SKILL_DIR/scripts/privacy_audit.py" --stdin \
  --rules "$SKILL_DIR/scripts/field-detection-regex-library.json"

Step 2: L2 Full Review (Six-Dimensional Manual Cross-Reference)

Use references/personal-information-desensitization-review-specification.md as the execution basis, check each dimension:

Identification and Classification: Is the field list complete? Sensitivity level tagging, combined re-identification risk, special tagging for minors
Desensitization Method and Scenario: Does de-identification/anonymization selection match sensitivity? (Irreversible preferred; reversible requires key management)
Field-Level Desensitization: Check each field across four stages: storage/display/transmission/sharing (key: ID/bank card must be encrypted for storage; interface default masking; logs must not contain plaintext)
Process and Checklist: Check all 33 items (A: Pre-identification 5 items / B: Storage 6 items / C: Display 6 items / D: Logs 4 items / E: Sharing 5 items / F: Testing 2 items / G: Technical safeguards 6 items)
Violation Scenario Investigation: Check all 15 high-frequency violation scenarios (plaintext storage, unmasked UI, over-collection, auto-checked consent, mandatory facial recognition, plaintext logs, breach notification failure, data doxxing/trading, cross-border transfer without assessment, etc.)
Compliance Basis Verification: Use regulation names/document numbers/dates and national standard IDs exactly as in Part 6 of the specification, do not alter

Step 3: Remediation and Verification

High risk (P0) must be fixed: Remove hardcoded credentials -> environment variables/key management; plaintext sensitive data -> encrypted storage + masked display
After fixing, rerun L1 scan to confirm exit code drops to 0 (or only low-risk remaining)
Medium risk (P1) recommended for next iteration; Low risk (P2) log for future optimization

Step 4: Output Standard Report

Generate report following the structure in references/audit-report-template.md: Audit target and data profile -> Results overview -> Graded issue list (P0/P1/P2) -> Compliance checklist -> Remediation priority -> Checklist comparison table -> Conclusion and disclaimer.

Dependencies

Python 3.8+ (standard library: argparse / json / os / re / sys)
No third-party dependencies; optional --json output for CI consumption

Boundaries and Security (Red Lines)

Does not constitute legal advice: Report conclusions must be considered in the context of specific business scenarios; high-sensitivity scenarios recommend manual review + consultation with compliance attorney
Output reports outside the scan directory: Prevent audit reports from being caught by a second scan and from falling into the release artifact
Fully local: No cloud API calls, no transmission of audited content
Binary files skipped: .zip/.png/.pdf/.docx/.xlsx/.pyc etc. are not scanned (decompress/convert to text first if needed)
No deletion: This skill only reports, does not delete or modify any audited files

Pitfall Log (Lessons Learned, Do Not Repeat)

Pitfall	Root Cause	Solution (Built into Script)
Coordinate constants / random long number strings falsely reported as ID/bank card	Pure regex matches "shape" but not "validity"	ID number MOD 11-2 checksum verification, bank card Luhn verification; skip if verification fails
Internal digits of ID number caught by phone/bank card regex due to priority conflict	Regex priority conflict	Interval deduplication: hits falling entirely within higher-priority hits -> skip (e.g., 110101-prefixed 6-digit number won't falsely match as phone)
Long numeric strings (e.g., 0.00669342162296594323 coordinate constant) substring matched as phone	Phone regex without boundaries	Phone regex adds digit boundaries: `(?<![0-9])…(?![0-9])`
Audit report written into scan directory getting caught by second scan	Report contains "hit examples"	Output report outside scan directory (--json points to external directory)
Chinese file encoding garbled under Windows	File may be GBK not UTF-8	read_text tries UTF-8 first, falls back to printable-character-ratio-based decoding
Large directories like node_modules/.git slow down scanning	No filtering	Built-in SKIP_DIRS (.git/pycache/node_modules/.venv/dist/build etc.)
Script behavior inconsistent after adding new fields to regex JSON	Regex library and script desynchronized	Regex JSON is the single source of truth, script loads dynamically; add new field types by modifying JSON first, then run script
Pattern definition text in regex JSON gets caught by itself (e.g., the phrase "People's Hospital" in hospital name regex)	Rule definition is itself a sensitive word sample	Normal behavior; manually confirm as pattern definition when self-hit occurs and ignore (conservative direction: prefer REVIEW over false negative)
"Beijing City A12345" place name + number falsely reported as license plate	License plate regex has no boundary, substring "京A12345" matches	License plate regex adds Chinese-character/alphabet-digit boundaries `(?<!…)(?<![\u4e00-\u9fa5])…(?![…])` + structural validator (province+letter+length7/8) double safety
Random 18-digit string has ~1/31 probability of passing Unified Social Credit Code GB 32100 check	Mod 31 verification inherently accepts ~3.2% of random strings	USCC classified as "medium sensitivity" (REVIEW requires manual confirmation) rather than high sensitivity precisely as a safety net; negative control test uses real invalid checksum
Test sample labels self-match (e.g., "fake WeChat ID: xxx" caught by WeChat ID regex)	Labels contain trigger prefix + valid format	Correct behavior (real scenario "WeChat ID: xxx" should be caught); design test samples to avoid replicating trigger prefix in labels
`evals/` test cases contain fictitious sensitive samples causing `preflight --strict` to report phone/email warnings	Test cases must have realistic samples to test detection capability, while release gate doesn't distinguish real vs fake	During pre-release self-check, use `--waive phone --waive email --reason "evals cases contain fictional test samples, not real PII"` to waive and log, delete `.preflight-waiver.json` before release; sample files header uniformly marked as "Fictional test data"
Random 18-digit strings (e.g., timestamp+sequence) have ~1/11 probability of passing ID MOD 11-2 checksum	Checksum only guarantees validity, not authenticity, random strings have natural pass rate	Known limitation: manually confirm as sequence number/timestamp/transaction ID and ignore; do not relax regex (prefer REVIEW over false negative)

Usage Example (Conversation Simulation)

User: Help me audit the ~/projects/skill-demo directory. Can it be published?
Agent:
  1. Run L1 scan:
     python3 ~/.workbuddy/skills/privacy-audit/scripts/privacy_audit.py ~/projects/skill-demo \
       --rules ~/.workbuddy/skills/privacy-audit/scripts/field-detection-regex-library.json --json ~/reports/demo_audit.json
  2. Exit code 1 -> 2 high-risk hits (hardcoded GitHub token + plaintext ID) -> Block release
  3. Perform L2 six-dimension check against the Review Specification: storage not encrypted, display not masked, logs contain plaintext...
  4. Output graded issue list (H-1 hardcoded token / H-2 plaintext ID storage / M-1 plaintext logs...)
  5. Remediation suggestions + standard report -> user fixes and reruns L1 -> exit code 0 -> allow release

Reference Documents

references/personal-information-desensitization-review-specification.md: Complete six-dimension specification (L1/L2 layering, 33-item checklist, 15 violation scenarios, 18 regulations + 6 national standards index, appendix tool instructions) — single source of truth for audit execution
references/personal-information-desensitization-review-points.md: Six-dimension key points (regulatory background and judgment dimension details; source class Official = laws, regulations, national standards; Community Consensus = public enforcement/judicial cases and industry practice)
references/audit-report-template.md: L2 standard report structure template
references/Changelog.md: Single source of truth for version history (complete change history from 1.0.0 to current version and version scope description)
evals/: Regression test suite (10 executable test cases + trigger_eval.json trigger word intent set); after modifying this skill, run it to verify existing capabilities are not broken; see evals/README.md for how to run

Version and Source of Truth

Current version number is determined by SKILL.md frontmatter's version; release tags, README version summaries, and the current version entry in references/Changelog.md all align with it.
Historical changes use references/Changelog.md as the sole source of truth. The Changelog sections in SKILL.md and README are only summaries of the last two versions + a link to that file; do not maintain a full version history across multiple locations—three parallel full histories will inevitably drift.
Markers like v1.1.0 new / v1.2.0 new in the body indicate feature ownership: they mark the first version where a feature appeared, which is historical record and does not change with the current version number (current version may be 1.3.0, but markers remain as originally written).
The "version": "1.1.0" in scripts/field-detection-regex-library.json is the rule library version: independent of the skill version; it increments only when field types/regex/validators actually change. v1.2.0 only changed scan entry points (--file/--text/--stdin) without changing rules, so the rule library remains at 1.1.0—this is correct, not a typo, do not "align" it casually.

Changelog

See references/Changelog.md for full version history (sole source of truth); table below is a summary of the last two versions.

Date	Version	Change Type	Change Content	Source
2026-09-06	1.3.1	Optimization	Added in-platform tags (privacy protection/desensitization/PII/personal information protection, 6 total), no functional changes	SkillHub platform optimization
2026-08-29	1.3.0	Optimization	Trigger word coverage 58% -> 100% (added `evals/trigger_eval.json` intent set with 16 intents + expanded trigger word cluster to 30); description reduced from 444 chars to 238 chars, details moved to body; added 10 executable regression test cases in `evals/` (average score 1.00 with `--run --aggregate`); added `references/Changelog.md`; established two-source-of-truth approach for version and version history	Health report remediation
2026-08-19	1.2.0	New feature	Added --text/--stdin/--file single file/text scan entry points (adapted for Coze dialog-style input, no local directory needed); positioning refined to "pre-release compliance gate"; added commercial positioning description	Coze listing adaptation

(Entries for 1.1.0 and earlier are in references/Changelog.md)

Disclaimer

This skill is AI-assisted generated and is for reference only. It does not constitute formal legal advice and cannot replace a qualified attorney. Compliance judgments should be made in the context of specific business scenarios by consulting professional legal personnel, and the latest effective laws and regulations shall prevail.

johnsmithCA-sta/privacy-audit

privacy-audit 是什么？

在你喜欢的 AI 中提问

文档