Laravel Sql Agent Laravel Package

Product Decisions This Supports

• Scope of an "ask your data" / text-to-SQL feature. The package appears to give a Laravel app a governed path from natural-language questions to SQL execution, including table-level allow/restrict lists. This directly informs whether you can ship self-serve data access to internal users (support, ops, CS, analysts) instead of hand-building a semantic layer plus prompt/schema plumbing.
• Build vs. buy for the guardrail layer. The interesting decision isn't "LLM writes SQL" — it's the policy surface around it: which tables are visible, what schema context is sent to the model, read-only enforcement, and result shaping. If those primitives map to your needs, adopting the package converts a multi-sprint security-sensitive build into an integration task; if they don't, you're buying a dependency you'll fork.
• Where data-access boundaries actually live. Release 0.9.1 fixes restricted tables leaking through references on permitted ones — i.e., a permitted table's foreign-key/relationship metadata could reveal a table you had explicitly excluded. That is a real product-level lesson: if you've been treating table allowlists as a security boundary rather than a UX convenience, that boundary was incomplete until this patch. This should drive decisions about which schemas the agent is pointed at (dedicated reporting views / read replica vs. primary schema), not just which version you pin.
• Roadmap sequencing for AI data features. Pre-1.0 with active security fixes on the permission model implies more edge cases ahead (column-level filtering, multi-tenant scoping, view/relationship traversal). Plan a phased rollout — internal-only pilot, then wider internal, then external — rather than committing to a GA date on a 0.9.x dependency.
• Risk acceptance for the permission model. The fix is a positive signal (maintainer is actively hardening and disclosing in changelogs), but it also confirms the allowlist wasn't airtight at 0.9.0. Product decision: require a security review of the guardrails before any user-facing exposure, and don't let a marketing claim of "restricted tables" substitute for testing with your own schema.

When to Consider This Package

Consider it when:

• The use case is read-only, internal-facing question answering over a schema you control and can curate (a reporting replica, curated views, or a purpose-built analytics schema rather than the primary OLTP database).
• You are on modern Laravel/PHP and want the schema-introspection, policy, and execution concerns handled in-framework rather than assembling them from scratch.
• Your access-control requirements are coarse — table-level allow/restrict is roughly the granularity you need, and you can additionally constrain exposure via database users/grants and a read replica rather than relying on the package alone as the boundary.
• You can absorb pre-1.0 churn: pin an exact version, read changelogs, and expect breaking changes between minor releases.
• You have engineering capacity for a security review and adversarial testing of the guardrails against your own schema (especially relationships, views, and any table that references sensitive data).

Look elsewhere — or wait — when:

• You need row-level or tenant-level isolation enforced inside the agent, column-level masking, or auditable per-user access decisions. Those are the requirements most likely to outgrow a 0.9.x permission model.
• The agent must write to the database, or run in a regulated environment (PHI/PCI/customer PII in scope) where an incomplete allowlist is a reportable incident rather than a bug.
• You need a stable public API with support commitments and a 1.0+ compatibility policy.
• Your schema is messy, denormalized, or full of similarly named tables — schema-context agents degrade quickly, and you'd be better served by a curated semantic layer regardless of package choice.
• Your stack isn't Laravel or you need the agent to span multiple data stores.

How to Pitch It (Stakeholders)

For executives: This is a Laravel package that lets us add natural-language data querying — "ask a question, get an answer from our database" — without building the schema-introspection, permissioning, and query-execution plumbing ourselves. The product value is speed: it turns a months-long, security-sensitive capability into an integration effort, and it's directly reusable across internal tools. The caveat is maturity: it's pre-1.0, and the latest release (0.9.1) is a security fix — restricted tables could previously be inferred through relationships on permitted tables. That's a good sign (the maintainer is actively hardening and documenting it) but it means we should not expose this to customers or point it at production data yet. Recommendation: approve a scoped internal pilot on a read-only reporting replica, with a security review of the access controls as a gate before any wider rollout, and treat the dependency as pinned-and-monitored rather than a stable platform commitment.

For engineering: The package covers the parts we'd otherwise build badly under time pressure: schema introspection for model context, table-level allow/restrict lists, and SQL execution. Adopt it pinned to an exact version, on a read-only replica or curated views, with a database user whose grants are the real backstop — do not treat the package's allowlist as the sole boundary, especially given 0.9.1's fix for restricted tables leaking via references on permitted ones. Before rollout we need: adversarial tests against our actual schema (relationship traversal, views, any table with FKs into sensitive data), a review of exactly what schema metadata gets sent to the model provider, and a documented upgrade path since minor bumps may break us pre-1.0. If those hold, this is a reasonable build-vs-buy win; if row-level or tenant-level isolation turns out to be a hard requirement, we should reassess before committing further.