Laravel Boost 2.6 mejora la seguridad del MCP y las pruebasLaravel Boost 2.6 mejora la seguridad del MCP y las pruebas

El problema no era solo bloquear palabras

Cuando un agente consulta la base de datos mediante MCP, confiar en que una herramienta detecte palabras como UPDATE o DELETE no es suficiente. SQL tiene variantes, extensiones y construcciones que hacen difícil garantizar la seguridad con filtros de texto. Laravel Boost 2.6.0 mantiene esa validación inicial, pero deja de tratarla como la última barrera.

El cambio importante está en la herramienta DatabaseQuery. Las consultas se ejecutan dentro de una transacción marcada como de solo lectura por el propio motor de base de datos. Al terminar, Boost revierte siempre la transacción, incluso si la consulta falla.

Eso cambia bastante el modelo de confianza. El agente puede equivocarse al formar una consulta, o intentar una forma de SQL que el filtrado previo no haya previsto, pero el motor tiene otra oportunidad para rechazar una escritura. No es una promesa basada solo en instrucciones para el modelo ni en una expresión regular.

La protección depende del motor que estés usando

Boost aplica una estrategia distinta según la conexión configurada. En MySQL y MariaDB establece la transacción como de solo lectura antes de iniciarla. En PostgreSQL activa esa condición después de abrir la transacción, mientras que SQLite utiliza PRAGMA query_only.

El detalle importa porque no todos los motores manejan las transacciones del mismo modo. La implementación consulta el driver de Laravel y aplica la instrucción correspondiente antes de ejecutar el select. No hay una opción nueva que activar en config/boost.php: llega con la actualización del paquete.

Para actualizar recursos generados de Boost después de actualizar dependencias, la documentación oficial indica este comando:

composer update laravel/boost
php artisan boost:update

Si acabas de añadir paquetes al proyecto y quieres que Boost detecte recursos adicionales, existe la opción --discover. No la usaría a ciegas en un repositorio compartido: revisa los cambios que genere antes de aceptarlos. Las instrucciones de agentes, igual que cualquier configuración de desarrollo, también forman parte de la superficie de mantenimiento.

php artisan boost:update --discover

Una única guía para decidir qué probar

La otra novedad relevante es la skill testing-best-practices. Antes había guías separadas y parcialmente solapadas para Pest, PHPUnit y otras decisiones de testing. El resultado podía variar según el agente que trabajase en el proyecto o según la combinación de instrucciones que cargase.

La nueva skill no pretende decidir que todo cambio merece más pruebas. Su enfoque es comprobar comportamiento observable y contratos de la aplicación, cubrir decisiones modificadas y evitar pruebas que solo verifican el funcionamiento interno del framework. También pide empezar por tests de feature cuando el comportamiento usa Laravel, reservando los unitarios para lógica que no depende del framework.

Me parece especialmente útil que dé prioridad a las convenciones ya presentes en el repositorio. Un proyecto puede usar Pest con it() o con test(), tener una forma concreta de autenticar usuarios en pruebas o construir factories de una manera determinada. El agente debe leer los tests cercanos antes de imponer una preferencia genérica.

La skill se adapta a si el proyecto usa Pest o PHPUnit. Cuando detecta el plugin de navegador de Pest, contempla pruebas de navegador; si no está disponible, no empuja al agente a añadir dependencias por iniciativa propia. Esa limitación es razonable: una herramienta de asistencia debería trabajar con el stack instalado, no ampliar el proyecto porque sí.

La letra pequeña

Una transacción de solo lectura para DatabaseQuery no convierte todo el servidor MCP en una zona segura. Protege las consultas realizadas mediante esa herramienta concreta, no los permisos de la cuenta de base de datos ni otras vías que pueda tener un proceso para modificar datos. La cuenta usada en desarrollo o staging debe seguir teniendo los privilegios mínimos que correspondan.

Tampoco sustituye revisar qué base de datos está configurada antes de conectar un agente. Si el MCP apunta a una conexión con datos sensibles, una consulta de lectura puede seguir exponer información que no debería salir del entorno. Solo lectura no significa acceso inocuo.

En testing, una skill mejora la consistencia de las propuestas del agente, pero no conoce automáticamente el valor de negocio de cada caso. Hay pruebas redundantes que conviene recortar y huecos que conviene cubrir, pero esa decisión sigue necesitando contexto del equipo. Mi consejo es tratar estas instrucciones como una base común y guardar las convenciones específicas de la aplicación en las reglas del proyecto.

Una actualización pequeña con consecuencias prácticas

Boost 2.6.0 no trae una API nueva para la aplicación ni obliga a cambiar tests existentes. Lo que hace es mejorar dos zonas donde los asistentes de código suelen ser frágiles: el acceso exploratorio a datos y la tendencia a generar pruebas inconsistentes o excesivas. Ambas mejoras reducen errores sin pedir al equipo que cambie su flujo diario.

Si usas Claude Code, Codex u otro cliente compatible con el MCP de Boost, actualizar tiene sentido especialmente en proyectos donde el agente consulta la base de datos. Después ejecutaría php artisan boost:update, comprobaría los archivos generados y revisaría una tarea real de testing. Es una forma sencilla de validar que las nuevas reglas encajan con el código que ya tienes.

• Fuente: Laravel News
• Documentación oficial: Laravel Boost v2.6.0