Si escribiste PHP el tiempo suficiente, hay una cicatriz que llevas contigo: el día que entendiste lo que hace unserialize() cuando el atacante controla la cadena. Cadenas POP, trucos con phar, blobs de sesión que se convertían en shells: pasamos años aprendiendo que un valor almacenado sigue siendo entrada del usuario, sin importar por cuántas capas haya pasado de camino al disco. Saco esto a colación porque el ecosistema de agentes de IA está ahora mismo repitiendo ese examen, pregunta por pregunta, y fallando en su mayoría en las mismas respuestas que fallamos nosotros. Esa es mi tesis: la historia de seguridad en torno a los frameworks de agentes en 2026 no es una disciplina nueva. Es la nuestra de siempre, y los desarrolladores de PHP están inusualmente bien equipados para aplicarla.

La ocasión es Black Hat 2026. Yarden Porat y Shahar Tal, de Check Point Research, pasaron un año atacando los frameworks sobre los que todo el mundo construye agentes —LangChain, LangGraph, CrewAI, AutoGen, el Agent Framework de Microsoft, el ADK de Google— y salieron con once vulnerabilidades; The Register lo recogió esta semana. El análisis atribuido a Tal merece citarse con precisión: debes asumir que los agentes van a leer contenido hostil, y el fallo real ocurre cuando ese contenido acaba dirigiendo la maquinaria de confianza: orquestación, memoria, instrucciones de sistema. Añadió que un agente ni siquiera necesita tener herramientas peligrosas habilitadas para volverse en tu contra; ingerir el documento equivocado puede bastar. Fíjate en lo que hace ese argumento: saca el bug del modelo y lo mete en el código del framework. Que es donde vivimos nosotros.

Toma el hallazgo del Agent Framework de Microsoft. Los agentes persisten checkpoints: instantáneas de su estado para que una tarea pueda reanudarse tras un fallo. Check Point demostró que un payload podía viajar dentro de un mensaje, quedar congelado en ese checkpoint y luego ejecutarse cuando otro usuario reanudara la sesión más tarde, porque el framework trataba su propio estado almacenado como intrínsecamente limpio. Resultado: acceso remoto al servidor, una recompensa de 10.000 dólares, un parche y ningún CVE, porque el framework aún no estaba en disponibilidad general. Ahora haz un buscar-y-reemplazar: llama al checkpoint blob de sesión serializado y esto es un hallazgo que cualquier revisión de seguridad de PHP habría marcado en rojo antes de que se enfriara el café. Tenemos literalmente folclore de charlas de conferencia sobre exactamente este fallo.

La entrada del ADK de Google en la lista es otro clásico distinto. El kit incluye un asistente de código integrado para el equipo de desarrollo… y en un despliegue estándar responde a internet abierto sin autenticación alguna. Desde ahí, un atacante podía hacerle escribir un archivo que se ejecuta automáticamente, ejecutarlo y pivotar hacia las credenciales del entorno y la cuenta de servicio que la máquina usa para hablar con el resto de Google Cloud. Google al principio se negó a tratarlo como bug, luego pagó 3.133,70 dólares y publicó un parche parcial. Todos los equipos de PHP que conozco tienen un punto en su checklist de despliegue que existe únicamente porque alguien dejó una vez una debug toolbar, un .env expuesto o un puerto de Xdebug abierto de par en par en un host de producción. La lección no era específica de PHP. Por lo visto, tampoco se aprendió fuera de nuestra casa.

Y la tanda de Black Hat no es un caso aislado. En junio, el mismo equipo de Check Point publicó una cadena contra LangGraph —una librería con aproximadamente 46,5 millones de descargas mensuales— que empieza con inyección SQL en get_state_history() y termina en ejecución remota de código. Inyección SQL. En 2026. El bug que las sentencias preparadas y una década de evangelización de PDO se suponía que iban a extinguir. En mayo, la propia Microsoft documentó dos agujeros críticos en Semantic Kernel donde un solo prompt bastaba para abrir calc.exe en la máquina anfitriona. En el mundo MCP, una cadena de tres vulnerabilidades críticas en el mcp-server-git oficial de Anthropic permitía ejecución remota de código, y los escaneos de servidores MCP públicos siguen sacando a la luz path traversal y tool poisoning: descripciones de herramientas manipuladas para que el modelo se comporte de forma distinta a la que su operador pretendía.

Déjame conceder la objeción más fuerte, porque es real: los LLM sí añaden algo genuinamente nuevo. No existe un htmlspecialchars() para el lenguaje natural. No puedes parametrizar un prompt como parametrizas una consulta, y puede que la inyección de prompts sea sencillamente irresoluble en la capa del modelo. Concedido. Pero mira dónde aterrizó realmente el daño en cada uno de los casos de arriba: una consulta ensamblada por concatenación de cadenas, un blob almacenado ejecutado por pura confianza, un endpoint que nadie se molestó en autenticar, un proceso corriendo con credenciales que nunca necesitó. El modelo fue el mensajero; el daño lo hizo código determinista. Y el código determinista es territorio donde sabemos ganar. No puedes sanear la prosa de un atacante, pero desde luego puedes negarte a hacer exec() de algo solo porque una cadena resucitada lo pida con educación.

Esto nos importa de forma concreta, porque los agentes están aterrizando en los equipos de PHP ahora mismo: servidores MCP escritos en PHP, workers de colas de Laravel llamando a APIs de agentes, backends de Symfony persistiendo estado de conversación junto a datos de clientes. Así que aplica los reflejos que ya poseemos. Todo lo que un agente almacena y luego relee es $_POST con retardo: valida a la salida del almacenamiento, no solo a la entrada. Ejecuta cada herramienta que el agente pueda invocar con el mínimo privilegio que le darías a un cron que no escribiste tú. Autentica los endpoints incluso cuando sean 'solo para el equipo'. Y si usas Psalm, su análisis de taint se construyó exactamente para esta forma de problema: rastrear entrada no confiable hasta un sink peligroso a través de código que en medio parece inocente.

Dos investigadores, doce meses, once vulnerabilidades en los frameworks de agentes más populares del planeta: esa proporción te dice cuán poco escrutinio ha tenido esta capa y cuánta fruta madura queda al alcance de la mano. La comunidad PHP pasó por su propia década de endurecimiento y salió con instintos que merece la pena exportar; este es un momento para ser los adultos en la sala, no los escépticos del rincón. Así que esto es lo que de verdad quiero saber de ti: ¿dónde trazas la frontera de confianza en tus propias integraciones con agentes? Cuando una salida o un estado vuelve de un agente que desplegaste tú, ¿lo validas como el formulario enviado por un desconocido… o, siendo honesto, todavía lo tratas como interno?