As of v0.5.0, DataSentry's rule set covers secrets only: tokens, keys, and
credentials in the categories credentials, cloud, devops, saas, ai,
database, auth, and web3 — 40 rules. Regulated-data detection (PII, financial,
healthcare, government identifiers, network topology) is out of scope for the free
tier. This document is the canonical statement of that boundary and the reasoning.
DataSentry stops you leaking your secrets. DataSentry Enterprise stops your organization leaking everyone else's data.
1. Regex-only regulated-data detection creates false confidence. Secret tokens have
vendor-published, stable formats (ghp_…, sk-ant-…, AKIA…) — regex detects them with
high precision, which is why secrets-only tools like gitleaks and trufflehog work. Card
numbers need Luhn validation or noise drowns the signal; medical record numbers vary per
institution; IBAN and tax IDs are per-jurisdiction matrices. A bare healthcare regex
invites "am I HIPAA compliant now?" — the answer is no, and a tool that implies otherwise
is doing harm.
2. The beneficiary differs. A leaked GitHub token hurts you, the developer — the free tier protects you, completely and forever, under GPL. A leaked customer SSN hurts a third party and creates organizational legal exposure (HIPAA, PCI-DSS, GDPR). The entity that needs regulated-data protection is the entity with the compliance budget.
3. Compliance rules need infrastructure this plugin doesn't have. Checksum validation, context scoring, tenant allowlists, and a signed audit trail — the things that make a PII rule trustworthy and its output usable as evidence — live in the DataSentry Enterprise proxy. Redaction without an evidence trail isn't compliance tooling.
id |
Name | Category |
|---|---|---|
ssn |
US Social Security Number | pii |
canadian-sin |
Canadian Social Insurance Number | pii |
email-assignment |
Email address assignment | pii |
phone-assignment |
Phone number assignment | pii |
dob-assignment |
Date of birth assignment | pii |
passport-or-license |
Passport / driver's license assignment | pii |
email-any |
Any email address | pii |
credit-card |
Payment card number | financial |
iban |
IBAN | financial |
bank-account-routing |
Bank account / routing number assignment | financial |
swift-bic |
SWIFT/BIC code assignment | financial |
tax-id |
Tax ID / EIN assignment | financial |
medical-record-number |
Medical record / patient ID assignment | healthcare |
insurance-member-id |
Insurance/member ID assignment | healthcare |
security-clearance |
Security clearance level assignment | government |
license-key |
License/product key assignment | enterprise |
private-ipv4 |
Private IPv4 address | network |
ipv4-any |
Any IPv4 address | network |
mac-address |
MAC address | network |
These rules now live in DataSentry Enterprise, where each gains the validation layer the bare pattern lacks (Luhn for cards, mod-97 for IBAN, structural checks for SSNs, tenant allowlists for network patterns) plus a signed audit record per redaction.
With the medium-severity rules gone, the old strict level would have differed from
standard by a single rule, so 0.5.0 collapses the ladder to four levels:
| Level | Rules | Scope |
|---|---|---|
off |
0 | — |
essential |
27 | critical only |
standard (default) |
37 | + high |
paranoid |
40 | + medium/low and noisy-flagged rules |
If your config says "level": "strict": nothing breaks. The engine falls back to
standard; versus the old strict you lose exactly one low-severity rule
(session-id) — set paranoid if you want it back.
They're GPL and they're in the history: every removed rule is in
rules/rules.json at the v0.4.0 tag.
Copy any of them into custom_rules in ~/.claude/datasentry/config.json and they run
exactly as before — with the same false-positive caveats that motivated the removal.