Intercept Pii Redactor Laravel Package

Product Decisions This Supports

• Build vs. buy for a compliance requirement. PII redaction is a checkbox item on nearly every privacy roadmap (GDPR/CCPA/DPA obligations, SOC 2 evidence, HIPAA-adjacent workloads). A drop-in Laravel package turns a multi-sprint "we should scrub PII from logs" backlog item into an afternoon integration — that is a favourable trade against building regex/detector plumbing in-house.
• Roadmap sequencing for privacy-by-design. Decide whether redaction ships before you expand data collection (new logging, new analytics, new LLM/AI prompt pipelines) or after. The package's existence lowers the cost of doing it first, which is the materially better ordering from a risk standpoint.
• Feature scope: redaction vs. encryption vs. tokenization. This package redacts (irreversible masking). It does not replace field-level encryption at rest (Laravel encrypted casts / CipherSweet) or reversible tokenization with re-identification. Use this to settle internal debates where "we already redact" is wrongly treated as covering storage-layer obligations.
• Vendor/architecture risk review. It is a read-only subtree split of promptphp/intercept, versioned independently of the parent. That is a real dependency-modelling input: you are adopting a distribution artifact, not a standalone project. Roadmap implication — decide up front whether you consume the split (just PII redaction) or the parent suite, because migrating later costs more than choosing correctly now.
• Buy-signal on the v1.1.1 release itself. This release contains no functional change — it is a source-pointer bump (intercept-source: 73ed9bb…). Treat it as a maintenance signal only: the split tracks the parent's commit, nothing more. Do not schedule work against it; do use it as a prompt to pin exact versions so the split and parent cannot drift silently.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel and need PII (emails, phone numbers, national IDs, card numbers) stripped before data reaches logs, exception trackers, observability backends, queues, or third-party LLM/API calls.
• You want the redaction to happen at an interception point in the request/lifecycle rather than requiring every developer to remember a helper — this is the main reason to prefer a package over a hand-rolled middleware.
• Your detection needs are pattern-shaped (structured identifiers) rather than semantic ("a person's name in free text"). Regex/rule-based redaction is cheap, deterministic, auditable, and explainable to a DPO — all genuine advantages.
• You want a small, single-purpose surface area, and you accept the split-repo model.
• Compliance needs are reasonable-effort and you can show the mapping from rule → data category in an audit.

Look elsewhere when:

• You need ML/NER-grade detection of unstructured PII in free text (names, addresses in prose). Rule-based redactors under-detect here, and under-detection is the failure mode that creates liability.
• You need reversible tokenization, format-preserving encryption, or a vault with re-identification for authorised users.
• You need centralised, cross-service policy enforcement rather than per-Laravel-app configuration.
• You need a vendor with an SLA, security questionnaire responses, and a CVE process. A subtree split with terse commit-pointer release notes gives you no changelog signal — for a security-sensitive component handling PII, weak release hygiene is a legitimate objection, not a nitpick.
• You would be better served by the parent promptphp/intercept — if you want the broader interception suite, adopting the split now means a later migration.

How to Pitch It (Stakeholders)

To executives: We have an obligation to stop personal data leaking into systems we do not fully control — logs, error trackers, analytics, AI vendors. This is a small, focused Laravel component that strips that data at the point it leaves our application. It converts an open compliance finding into a bounded, one-off integration instead of a recurring engineering tax. Cost is low and reversible; the downside risk of not doing it (breach notification, regulator inquiry, DPA breach) is asymmetric. Caveat to state plainly: it handles structured identifiers well, it is not a complete privacy programme, and it does not replace encryption at rest.

To engineering: It is a drop-in Laravel package that redacts PII at an interception point, so correctness does not depend on every developer remembering to call a helper. Two things to internalise before we merge it:

1. Treat it as a subtree split. It is read-only and mirrors promptphp/intercept. Pin exact versions, do not patch it in place, and track the parent repo for actual changes — the release notes we have here are only a commit pointer, so our dependency-update process has to supply the changelog that the package does not.
2. Know the failure mode. Rule-based redaction under-detects free-text PII. Scope it to structured fields and log payloads, add tests with real-world sample data, and do not let it be cited as coverage for unstructured text.

Recommendation: adopt for structured PII in logs and outbound third-party calls, behind a short spike that measures false negatives on representative payloads. Reassess if requirements shift toward semantic detection or reversible tokenization.