Lo que cambió no es solo otro conjunto de reglas, es un puente entre las preocupaciones de seguridad de la IA y los flujos de trabajo maduros de AppSec. CodeQL ahora rastrea valores no confiables que pueden moldear la indicación del sistema de un modelo, y señala cuando estos flujos alcanzan llamadas sensibles a SDK. Al ampliar los sinks para las API de los principales proveedores, la detección reconoce patrones del mundo real que los desarrolladores usan para ensamblar instrucciones del sistema, políticas de sesión y conexiones de herramientas. El resultado es un evento de seguridad familiar: un hallazgo de flujo de datos que puede ser clasificado, corregido y prevenido mediante políticas, en lugar de una anécdota ambigua de “mal comportamiento de IA” que rara vez se mapea a controles CI/CD.

Para los líderes de ingeniería, esto replantea la inyección de indicaciones como un problema de higiene de dependencias y validación de entradas. Cuando las indicaciones del sistema heredan cadenas controlables por el usuario — banderas de características, configuraciones de inquilinos o contenido CMS — los modelos pueden ser forzados a ignorar instrucciones, exponer herramientas o filtrar contexto. El enfoque de CodeQL lleva esos riesgos a SARIF, anotaciones de PR y métricas base, habilitando las mismas vías de escalamiento que las clases clásicas de inyección. Crucialmente, ayuda a los propietarios de producto a cuantificar el riesgo en términos que los auditores entienden: flujo de datos desde fuentes no confiables a sinks sensibles, respaldado por consultas reproducibles y políticas versionadas.

Adoptar esta capacidad es menos sobre reescribir indicaciones y más sobre codificar límites. Los equipos deberían fijar una versión actual de CodeQL, habilitar la nueva consulta de inyección de indicaciones del sistema para JS/TS y ejecutar líneas base a nivel organizacional. Comenzar con repositorios que construyen agentes, llamadas a herramientas o pipelines RAG; luego expandir a servicios donde las indicaciones se ensamblan desde configuración. La guía de clasificación debería categorizar flujos por explotabilidad: grado de control del usuario, presencia de salvaguardas de plantillas y poder de herramientas aguas abajo. Donde persistan brechas, escribir pequeños modelos personalizados para llamadas a SDK propietarios para asegurar paridad de cobertura con sus interfaces de producción reales.

Espere límites: el análisis estático no puede simular completamente gráficos dinámicos de herramientas, composición de indicaciones entre servicios o barreras en tiempo de ejecución como restricciones de llamadas a funciones. Pero lo mismo ocurría con SSRF o deserialización hasta que los ecosistemas normalizaron patrones y linters. La imagen más amplia es la convergencia: los riesgos de IA se están normalizando en las puertas del SDLC, creando un lenguaje común entre seguridad, plataforma y cumplimiento. Eso eleva el estándar para proveedores y plataformas internas por igual: lanzar funciones de IA sin cobertura de escaneo de código parecerá cada vez más como lanzar APIs sin pruebas de autenticación.