Filament Guardian Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side RBAC: This package is the authorization layer for Filament admin panels backed by Spatie permissions. It replaces weeks of custom role/permission UI, policy scaffolding, and navigation gating with a configurable, community-maintained package — a straightforward "buy" unless your authorization model is genuinely unusual.
• Security posture and compliance decisions: The v1.14.0 fix closes a real privilege-escalation path (any user with Attach:Role could self-assign the super-admin role and inherit a full Gate bypass; Detach:Role could strip every super admin). This is a decision input for upgrade prioritization, not just a feature toggle — treat it as a security patch on your roadmap and schedule it with the same urgency as a CVE.
• Roadmap sequencing for admin/back-office features: If role management is a dependency for upcoming admin work (user provisioning, multi-tenant admin roles, delegated administration), this package unblocks that work now rather than after a custom build.
• Delegated administration model: The release clarifies a product boundary — super-admin membership is now a super-admin-only action, hard-enforced regardless of what your RolePolicy returns. That constrains "who can grant god-mode" to a small, auditable group, which is the right default for most orgs and a defensible answer in security reviews.
• Use cases it enables: internal admin panels, ops back-offices, SaaS tenant administration, customer-support tooling with tiered staff permissions — anywhere a non-engineer needs to grant/revoke access without a deploy.

When to Consider This Package

Consider it when:

• You're on Laravel + Filament and using (or planning to use) Spatie Laravel Permission. The package assumes both; it is not a general-purpose RBAC library.
• You need an in-panel UI for roles and permissions — i.e., admins managing access is itself a product requirement, not a one-off seeder.
• You want a super-admin escape hatch (a role that bypasses Gate) as an intentional, documented part of your access model, with the guarantee that only super admins can add or remove super admins.
• You have multiple roles with overlapping permissions and need policy-driven visibility rather than hardcoded checks.
• You can commit to tracking releases: the v1.14.0 issue is the kind that sits quietly in production until someone abuses it.

Look elsewhere when:

• You're not using Filament (or are API-only / headless) — the value is largely the panel integration; use Spatie directly.
• Your authorization is simple and static (two or three fixed roles set in code). A package plus its upgrade treadmill is overhead you don't need.
• You have heavily custom policy logic that the package's resource/policy conventions would fight rather than support.
• You need field-level or row-level authorization, attribute-based access control, or approval workflows — out of scope here.
• You cannot upgrade promptly. Staying on a pre-1.14.0 version means shipping a known privilege-escalation path in an admin panel; if you can't patch, don't adopt.

Upgrade-specific criteria: this is a behavior change, not purely additive. Non-super-admin users who previously managed super-admin membership from the Users tab lose that ability. Before upgrading, identify any workflow, runbook, or support process that relies on a delegate granting or revoking super-admin — those must move to a super-admin actor or be redesigned.

How to Pitch It (Stakeholders)

For executives: This is a mature, low-cost authorization package for our Laravel admin tooling — it's the difference between building and maintaining a role-management system ourselves and adopting one that's already hardened by a community. The latest release fixes a genuine security flaw: previously, a user with modest role-assignment rights could promote themselves to super admin and bypass every permission check in the application. That's now closed. The trade-off is one deliberate restriction — only super admins can grant or revoke super-admin — which is the behavior security reviewers expect. Recommendation: adopt, and treat the upgrade to v1.14.0 as a priority patch rather than a routine dependency bump.

For engineering: Security patch plus a scoped behavior change. Super-admin add/remove is now gated on being a super admin, enforced in the UI independent of RolePolicy; all other roles continue to honor your policy unchanged. Two action items: (1) upgrade and confirm the version is pinned forward, (2) grep your seeders, tests, and any admin runbooks for flows where a non-super-admin attaches or detaches the super-admin role — those break by design. Worth a line in the changelog we surface to internal admins, since a few people will find a button missing and should know why. Credit to the reporter; the fix is narrow and doesn't add migration or config surface.