Laravel Agent Kit Laravel Package

Product Decisions This Supports

• Build vs buy for an AI/agent interface layer. If the roadmap includes exposing product data to LLM agents or MCP clients, this package is the "buy" option for the authorization and redaction layer — the part that is expensive to get right and cheap to get wrong. It lets the team spend engineering budget on tool semantics rather than on reinventing per-model access control.
• Shipping an MCP/agent surface without a security rewrite. The release's test suite encodes the properties a security review will ask about: model-level policies are mandatory (a model without a policy throws rather than defaulting open), field values never reach audit records, and a denied get is indistinguishable from a missing record. That is a go/no-go criterion for launching agent-facing endpoints, and it is now an assertion in CI rather than a promise in a doc.
• Scoping decisions for multi-tenant and per-user data. "Bob's ticket is not in Alice's list" and "a relation cannot reach a model nobody exposed" are product-level statements about tenant isolation and graph traversal. This supports a decision to let agents query relational data at all, instead of restricting them to pre-baked, hand-written endpoints.
• Data classification and redaction policy. internal_notes being absent from a payload is a concrete, testable expression of a data-classification decision. PMs can point at this as the mechanism that makes "internal fields stay internal" enforced by code rather than by reviewer diligence.
• Platform-version roadmap. Laravel 13 support (PHP 8.3+) widens rather than moves the constraint — Laravel 12 and PHP 8.2 remain supported. This supports a decision to schedule the Laravel 13 upgrade on the normal cadence without treating this dependency as a blocker, and it means the package does not force a PHP floor bump on the wider application.
• Audit and compliance posture for AI features. Value-free audit records (who called what, not what the data said) is the shape most privacy reviews prefer. This supports launching agent features in regulated or enterprise accounts where logging request payloads would be a findings item.
• Generated tool classes as a product surface. The release verifies generated tools load and serialise through laravel/mcp itself, not just that they look correct. That supports committing to generated tooling in the developer experience rather than maintaining hand-written tool definitions.

When to Consider This Package

Consider adoption when most of the following hold:

• You are building an MCP server or agent tool layer on Laravel and will expose Eloquent models, not just bespoke read-only endpoints.
• Multiple users or tenants hit the same endpoints, and correctness depends on per-request scoping rather than a single trusted caller.
• You need field-level redaction (internal columns, PII, cost/margin data) that is enforced centrally instead of relying on each tool author.
• A security or privacy review will ask for evidence of fail-closed behavior, non-enumerable denials, and payload-free audit logs.
• You are on Laravel 12 or 13 with PHP 8.2–8.4 and want a single dependency that spans the upgrade window.
• You want generated tool classes rather than maintaining them by hand.

Look elsewhere when:

• The exposure surface is small and fixed — a handful of hand-written, read-only tools may not justify the policy overhead.
• Your authorization model does not live in Laravel policies, or you need an external policy engine (OPA, custom ABAC) as the source of truth.
• You need write/mutation tools with approval workflows; this release's evidence is oriented toward read-path guarantees.
• You are pinned below Laravel 12 or PHP 8.2.
• You need guarantees the package does not test. The suite asserts specific read-path security properties; it is not a general-purpose sandbox or rate-limiter, and those concerns remain yours.

Caveat on the evidence. The release notes describe 58 tests and the properties they assert, but the assessment is based on release notes alone — no source review, no independent verification of coverage, and no data on maintenance cadence, issue responsiveness, or downstream adopter count. The security claims are strong and unusually well-specified, which is itself a positive signal about the maintainers' priorities, but "the tests assert X" is not the same as "X is guaranteed under all configurations." Before committing, ask engineering to confirm that the fail-closed behavior holds for the model types you actually plan to expose, and pin the version.

How to Pitch It (Stakeholders)

For executives: This release makes our AI-agent data access defensible. Rather than building a bespoke permission layer for every model we let an agent touch, we adopt one that refuses to expose anything without an explicit policy, keeps sensitive fields out of responses and out of logs, and does not let a caller distinguish "you're not allowed" from "it doesn't exist." Those three properties are what come up in security reviews and in enterprise procurement questionnaires, and they are now covered by automated tests. Release v0.5.0 adds Laravel 13 support without dropping Laravel 12 or PHP 8.2, so adopting it does not couple our AI roadmap to a platform upgrade.

For engineering: The authorization, redaction, audit, and relation-scoping layer is solved and tested; your effort goes into defining which models and fields are exposed and what the tools should do. Policies are mandatory — a model without one throws, so misuse fails loudly at development time rather than silently in production. Audit records carry no field values. Tool classes are generated and verified to load and serialise through laravel/mcp rather than only passing a shape check, so the generated output is real, not decorative.

For security and privacy: Denials are non-enumerable: a denied get is indistinguishable from a missing record, closing the enumeration channel that agent endpoints often open. Logs record the call, not the contents. The test suite asserts these behaviors directly instead of documenting them, which gives you a reviewable artifact. We should still run our own review against our specific data classifications.

Ask: Approve a time-boxed engineering spike to validate the fail-closed behavior against our two highest-sensitivity models, then decide on adoption. Pin the version either way.