Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for audit logging. The package supplies a tamper-evident, append-only ledger plus the operator-facing surface (verify, export, report, erase) that would otherwise be months of in-house work. 1.5.0 strengthens the case for buying: the vendor is investing in the security envelope around the ledger, not just the ledger itself.
• Compliance commitments as a feature, not a side-effect. The action set maps directly to obligations product teams get asked to satisfy: integrity verification (verifyEntry / verifySegment / verifyChain / verifyAnchor / verifyAllAnchors), evidentiary export (exportLedger / verifyExport / downloadLatestExport), reporting (complianceReport / downloadLatestReport), and GDPR right-to-erasure (eraseSubject).
• Roadmap sequencing for "audit-ready" milestones. Verification granularity (entry → segment → chain → anchor) is a natural maturity ladder. PMs can sequence customer-facing or auditor-facing milestones against it rather than treating "audit trail" as one undifferentiated checkbox.
• Security posture as a release-gating criterion. 1.5.0 closes a defense-in-depth gap: panel actions were gated only at render time (->visible()), so a crafted direct invocation could still trigger verify/export/report handlers. Execution-time authorization is now re-checked on every gated action, using the same gate as visibility, so the two can never disagree. Note the vendor's own calibrated severity — there was no ledger mutation path, no synchronous decrypted data exposure (exports run through a queued job), and the one write path (GDPR erasure) already enforced execution-time authorization. This is hardening, not breach remediation; it should not be escalated as an incident.
• Durability of the guarantee. The release adds ExecutionTimeGuardTest, which bypasses visibility exactly as a crafted request would and asserts denial (notification sent, no work performed) for every gated action, plus a structural tripwire pinning the exact set of registered actions. That converts "we fixed it" into "this class of gap cannot silently reappear" — a meaningfully stronger commitment to put in front of a security reviewer or auditor.
• Risk-adjusted upgrade decision. No API or configuration changes, identical behaviour for authorized callers, single composer update. Low cost, low risk, real (if modest) risk reduction — an easy yes, but not a reason to interrupt a release freeze.

When to Consider This Package

Consider adoption when:

• You are on Laravel + Filament and need an audit trail inside the admin panel rather than a bolt-on logging service.
• You have, or expect to have, compliance obligations requiring tamper-evident records, integrity verification, or auditable evidence of erasure (SOC 2, ISO 27001, GDPR DSAR/erasure workflows, regulated-industry audits).
• You need GDPR erasure with a verifiable proof trail — the erase path plus ledger integrity is precisely the hard part teams underestimate.
• Your auditors or enterprise buyers ask "can you prove this record was not altered?" and you currently answer with application logs.
• You need exports and compliance reports as a supported, queue-based workflow rather than scripted ad hoc.

Look elsewhere when:

• You are not on Filament — the value here is substantially the panel action layer; the underlying ledger may be available separately.
• You need independent external attestation (third-party timestamping, WORM storage, notarization) — this is application-level integrity, not a legal-grade custody chain.
• Your threat model includes a compromised application server or DBA. An in-app ledger does not defend against that; you need append-only storage or off-host anchoring.
• Very high write volume — append-only ledgers with per-entry verification have cost characteristics worth benchmarking before committing.
• You want a hosted observability/audit SaaS with cross-system correlation; this is scoped to one application's ledger.

On 1.5.0 specifically: adopters with custom actions registered against the resource must add their own execution-time denial tests — the tripwire now expects each gated action to refuse at execution. That is the one piece of follow-up work the upgrade creates.

How to Pitch It (Stakeholders)

For executives: This release is a security hardening update to our audit-ledger plugin, and it is deliberately framed as low-urgency. The gap it closes was narrow: admin panel buttons were hidden from unauthorized users but the underlying handlers did not re-check permission when called directly. The vendor is explicit that no ledger entry could be altered, deleted, or reordered, no decrypted data was returned to an unauthorized caller, and the highest-risk action (GDPR erasure, the only write path) already had the check. We should take the update for the hardening, but it does not warrant an incident review or a release-freeze exception. The upgrade is a one-line dependency bump with no API or config changes, and authorized users see no difference. Strategically, the more valuable signal is that the vendor now ships an automated test that fails if any future action is added without an execution-time permission check — that is a durable control we can point to in security questionnaires and audits, and it materially reduces the chance of this class of regression recurring.

For engineering: composer update laravel-chronicle/filament, no migrations or config changes. Every gated action now re-checks its gate at execution using the same gate as its ->visible(), removing the render-time/execution-time divergence. New ExecutionTimeGuardTest reaches real handlers with the gate forced off and asserts denial plus no side effects; a structural tripwire pins the registered action set and fails with guidance when a new action appears. Action required: if we have custom actions registered against the resource, add denial tests for them or the enforcement test will fail. Recommend scheduling in the next routine dependency window rather than as a hotfix.