Redactor Laravel Package

Product Decisions This Supports

• Build vs. buy for redaction. The default answer for "we need to scrub PII/secrets" in a Laravel codebase is a homegrown regex utility that rots. This package makes "buy" credible: path rules, key policies, entropy detection, per-entity operators, and a Detector contract cover the 80% you'd otherwise rebuild badly, so the build decision narrows to "configure profiles + write a few custom detectors" rather than "own a detection engine."
• AI/LLM roadmap unblocking. Ai\RedactPrompt and Mcp\RedactsResponses let you ship prompt-based or tool-calling features while keeping the data-protection review short. This is a roadmap enabler, not just a hygiene tool — it changes whether an AI feature can go to a regulated customer segment this quarter.
• Observability strategy. The observability profile plus deterministic surrogate/hash operators make redacted logs still joinable — counts, traces, and support lookups survive. That's the decision that lets you ship logs to a third-party SIEM without a data-processing addendum fight.
• Compliance and audit artifacts. RedactionPerformed (counts, never values), SARIF/JUnit output, ruleset fingerprints, and baselines turn "we redact" into evidence you can attach to SOC 2 / GDPR / PCI reviews and gate in CI.
• Release and CI policy. --baseline/--update-baseline, --staged/--diff/--history, and the published pre-commit hook let you adopt incrementally: fail only on new findings, then ratchet down.
• Support and incident-response workflow. Line-level redactor:allow and git-history scanning give support engineers a sanctioned way to paste real payloads into fixtures, and give security a way to find secrets that were later "removed."
• Test strategy. Redactor::fake() with assertNeverEmitted() lets QA assert a secret never left the process rather than assert that a code path called a function — a meaningfully stronger test contract to standardize on.
• Data/analytics decisions. Reversible tokenize with a TTL makes "can we analyze this without storing the raw value?" answerable yes for dashboards and vendor tooling.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP, ideally a monolith or a small number of services, and redaction needs to happen in-process (request/response, logs, queue payloads, prompts) rather than at a network boundary.
• You have a named compliance or contractual driver (PII in logs, customer data in prompts, secrets in CI) — this package is strongest when there's an auditor or a customer security questionnaire on the other side.
• You want one policy surface (profiles, path rules, allow-lists, known secrets) shared by runtime redaction, CLI scanning, and CI, instead of three inconsistent mechanisms.
• You have a small platform team without appetite to operate Presidio, a DLP gateway, or a tokenization vault.
• You need incremental adoption — baselines and per-line suppression mean you don't need a big-bang cleanup.
• You're fine treating it as replaceable infrastructure behind your own interface.

Look elsewhere when:

• Your stack is polyglot or redaction belongs at the edge — a gateway/sidecar (Presidio, a DLP proxy) covers more surfaces with one policy.
• You need vendor-backed SLAs, indemnities, or 24/7 support. MIT + a single maintainer is not a procurement answer for a tier-1 regulated workload.
• You need format-preserving encryption or a real tokenization vault with key management, rotation, and DB-level guarantees; the tokenize operator is convenient, not a vault.
• You need massive throughput or very large binary/streaming workloads where a dedicated service or JVM/Go implementation is the right shape.
• Adoption signal matters to your risk committee. Three stars and zero dependents is a real maturity caveat — not disqualifying, but it means you are an early adopter and should budget for that.

Recommended posture: a time-boxed spike (1–2 sprints), pin to v1.0.x, wrap Redactor behind your own contract so swapping is a one-file change, and review the detection rules yourself — self-testing rules and redactor:validate help, but they validate the rules as written, not that the rules match your data.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed control that closes a specific, nameable risk — customer data and credentials leaking into logs, error trackers, CI, and AI prompts. It also removes a blocker on the AI roadmap: we can ship LLM-backed features to security-sensitive customers without a bespoke data-protection build. The cost is integration time, not license or infrastructure; there's no vendor lock-in and no service to operate.

To engineering: It's a normal Laravel package — middleware, event, facade, artisan commands, no sidecar required. Redaction and detection are separated (detection reports what and where; operators decide what happens), which means policy changes don't mean rewriting regexes. It ships Redactor::fake() so tests can assert a secret never left the process, redactor:validate to catch broken rules, and measured performance (roughly 21k redactions/sec on the default profile; 1 MB of free text in ~24 ms with flat memory via streaming). Integration is a config publish plus one middleware, and CI adoption is a baseline — we can fail on new findings only.

To security/ops: One policy drives runtime, CLI scanning, and CI. Scans are git-aware (--staged, --diff, --history) so we catch secrets in the diff and in history, output SARIF for GitHub code scanning, and record a ruleset fingerprint so a baseline made under different rules is flagged rather than silently trusted. The audit event carries counts and keys, never values.

The honest caveat to include in every version of this pitch: early-stage project, minimal public adoption, single maintainer. Recommend the spike, the interface wrapper, the version pin, and a standing review of shipped detection rules against our own data before we call it a control rather than a convenience.