Laravel Model Shield Laravel Package

Product Decisions This Supports

• Build vs. buy on field-level authorization. ModelShield provides a trait-based layer for gating model attributes/operations behind permission checks. If your roadmap includes "different users see different subsets of a record" (e.g. support agents vs. account owners vs. admins), this is a candidate to buy/adopt rather than hand-roll policy logic into every controller and transformer.
• Scope sizing for RBAC/ABAC features. The package's trait-based ergonomics mean the marginal cost of adding a new shielded model is small — useful when estimating "add permissions to module X" stories, and when deciding whether to gate this at the model layer versus the API resource layer.
• Legacy-stack compatibility decisions. The v1.1 release adds a Sentry adapter (ShieldSentry), meaning the package will plug into Cartalyst\Sentry's Eloquent user model. This is a signal for products still running Sentry-based auth: integration cost is now a trait import, not a custom bridge. It also flags a strategic question — is the roadmap committed to Sentry (effectively unmaintained) or migrating to native Laravel gates/policies?
• Migration sequencing. If a Sentry→Laravel-auth migration is planned, adopting ShieldSentry creates a small, well-isolated piece of technical debt (one trait, one base-class change) that can be swapped later. That makes it reasonable to adopt now and migrate deliberately rather than block the feature.
• Feature-level risk register. Third-party authorization code is a security-sensitive dependency; the existence of a formal Sentry adapter is evidence of maintained surface area, but not of a security review.

When to Consider This Package

Adopt when:

• You need per-field or per-attribute visibility on Eloquent models and want it enforced centrally rather than re-implemented in each controller, form request, or API resource.
• Your authorization rules are permission-driven and you already have a role/permission source (Sentry, or a Laravel gate/policy layer).
• You are on (or deliberately staying on) Cartalyst Sentry and want an off-the-shelf integration rather than a bespoke bridge — v1.1's use ShieldSentry; on a Sentry Eloquent user is a one-line adoption path.
• You want the permission mapping to live next to the model as declarative configuration, which keeps diffs small and makes the rules reviewable by non-authors.

Look elsewhere when:

• You are on native Laravel auth. Laravel policies, gates, and API resources already cover most attribute-level needs; adding a model trait may duplicate or conflict with AuthorizesRequests conventions.
• You need row-level/query scoping (e.g. tenant isolation) — that's a global scope / policy concern, not an attribute shield.
• Your security posture requires a maintained, audited dependency. Sentry-derived stacks and small single-maintainer packages warrant a threat-model review before they sit on the authorization path; if the team cannot absorb that review, prefer first-party policies.
• You need column-level redaction at rest (encryption, PII masking in the database). This is a read-time presentation control, not a storage control — don't let it be sold internally as a compliance feature.
• Your models are heavily serialized to JSON and you need guaranteed output shaping. Verify integration with your resource/serializer layer before committing; trait-based shielding can be bypassed by raw toArray()/query-builder paths.

How to Pitch It (Stakeholders)

For executives (one paragraph). We evaluated ModelShield, a small Laravel package that lets a model declare which attributes a given user is allowed to see or touch, enforced in one place instead of scattered across controllers. The new v1.1 release adds a first-class adapter for Cartalyst Sentry, the permission system used by our legacy user model, which reduces integration to a single trait on our User class. The upside is a smaller, more auditable authorization surface and cheaper "who can see what" features. The caveat is dependency risk: this sits on the security path, and Sentry itself is not actively maintained, so adoption should be paired with a documented review and a plan to migrate to native Laravel policies.

For engineering. v1.1 ships Vinicius73\ModelShield\Traits\ShieldSentry, applied to a Sentry Eloquent user model. This tells us the package is designed to compose with an existing permission provider rather than own one — good separation, low coupling. Practical guidance: (1) confirm the trait's rules resolve through our Sentry permission checks as expected and cannot be short-circuited by direct query-builder access or raw toArray(); (2) pin the version and add it to the dependency-review list given it sits on the auth path; (3) keep the shielded rules declarative and reviewed in PRs so they read like a policy file; (4) treat the Sentry coupling as transitional — the trait is a thin seam, so a later swap to native policies is a contained change. If we adopt, timebox a spike against one representative model before rolling out broadly.