La habilidad de auditoría de seguridad de Cloudflare convierte la revisión de código con IA en un flujo de trabajo adversarial
Cloudflare ha lanzado un flujo de trabajo de auditoría de código con IA de seis fases, pero la habilidad de auditoría de seguridad de Cloudflare no es otro prompt que pide a un modelo encontrar errores. Asigna agentes independientes para mapear el código, buscar vulnerabilidades, cuestionar los hallazgos y verificar las evidencias que se sostienen.
Esta distinción importa porque los informes de seguridad generados por IA a menudo contienen afirmaciones plausibles sin una vía de ataque válida. El diseño de Cloudflare trata cada vulnerabilidad propuesta como una alegación que otro agente debe intentar refutar. También registra qué cubrió la auditoría, lo que hace más visible el análisis ausente.
El lanzamiento de código abierto reúne ideas que Cloudflare desarrolló mientras construía una infraestructura interna de vulnerabilidades mucho mayor. La habilidad pública se dirige a un repositorio y una ejecución de auditoría. El sistema interno de Cloudflare, en cambio, conserva resultados entre repositorios, rastrea dependencias y gestiona miles de hallazgos.
Esto genera la tensión central del lanzamiento. Una habilidad reutilizable reduce la barrera para una revisión estructurada de código con IA, pero no puede reproducir por sí sola la infraestructura interna de Cloudflare. Los desarrolladores obtienen un punto de partida más sólido, no un reemplazo autónomo para los ingenieros de seguridad.
Lo que realmente cambia la habilidad de auditoría de seguridad de Cloudflare
Cloudflare está transformando la revisión de seguridad con IA de una conversación en un proceso que genera evidencias, con cobertura explícita y puertas de verificación.
El repositorio de la habilidad de auditoría pública describe un flujo de trabajo diseñado para agentes de programación compatibles con herramientas y subagentes aislados. Tiene licencia MIT y puede instalarse mediante la interfaz de línea de comandos Skills.
La habilidad de auditoría de seguridad de Cloudflare divide una auditoría en seis fases. El reconocimiento mapea la arquitectura de software, los límites de confianza, las superficies de entrada y las evidencias disponibles. El proceso registra ese mapa en un documento de arquitectura y un registro de cobertura legible por máquina.
A continuación viene la búsqueda guiada por cobertura. El agente principal asigna buscadores aislados a áreas y clases de ataque definidas. Cada buscador registra lo que comprobó, en lugar de devolver solo una lista de problemas sospechosos.
Ese registro es importante porque un informe breve puede generar una falsa sensación de seguridad. Un agente podría inspeccionar el código de autenticación, no encontrar nada e insinuar que toda la aplicación parece segura. Un registro de cobertura puede mostrar que el análisis de parsing, la configuración de despliegue, el manejo de dependencias o el aislamiento entre inquilinos recibieron poca atención.
La validación de candidatos entrega cada pista diferenciada a un verificador nuevo. Ese verificador intenta descartar la vulnerabilidad propuesta comprobando sus supuestos, la ruta del código fuente, el principal afectado y el resultado de seguridad. El agente de búsqueda no aprueba su propio trabajo.
Los hallazgos que sobreviven pasan después a una salida estructurada. La habilidad separa los registros entre hallazgos confirmados, problemas que requieren validación y candidatos rechazados. Un esquema define los campos obligatorios, mientras que los validadores de JavaScript incluidos comprueban los archivos mecánicamente.
Las fases finales verifican de forma independiente las afirmaciones sobre el código fuente y generan informes independientes del objetivo. Los cambios sustanciales en un hallazgo desencadenan otra pasada de verificación. Este diseño intenta impedir que quien redacta el informe refuerce discretamente una afirmación débil durante el resumen.
El resultado difiere de una auditoría de seguridad de código con IA convencional en un aspecto crucial. El entregable incluye un registro de las superficies examinadas, las ideas rechazadas, los hechos sin resolver y los hallazgos comprobados de forma independiente. Un informe de apariencia limpia deja de ser el único artefacto.
Cloudflare también define un límite estricto de ejecución. Las compilaciones, pruebas, fuzzers, navegadores y fixtures controlados por el objetivo requieren un sandbox del sistema operativo sin acceso externo a la red. Sin esos controles, el flujo de trabajo debe conservar una pista como no verificada en lugar de ejecutar código no confiable.
Esta restricción hace que el lanzamiento sea menos cómodo que un prompt de auditoría de una sola línea. También refleja un problema de seguridad real. El código bajo revisión puede contener instrucciones o comportamientos de compilación que ataquen el propio entorno de auditoría.
Por qué Cloudflare creó una habilidad antes que una infraestructura para toda su flota
La habilidad pública es valiosa porque captura el método de auditoría de Cloudflare, al tiempo que revela por qué una sola sesión de agente alcanza un límite operativo.
Cloudflare afirma que el proyecto comenzó como una habilidad de seguridad de aproximadamente 450 líneas para un único repositorio. Los ingenieros refinaron sus prompts hasta que detectó errores útiles, y luego trasladaron sus escenarios y reglas de validación a un sistema más amplio.
La empresa detalló esa evolución en su publicación de ingeniería sobre la infraestructura de vulnerabilidades. La primera versión empleaba tres agentes de investigación para el reconocimiento, buscadores separados para clases de ataque, validadores adversariales, hallazgos estructurados y verificación independiente del código fuente.
Cloudflare identificó tres límites durante esas primeras ejecuciones. Las sesiones largas agotaban el contexto del modelo, las ejecuciones interrumpidas perdían el progreso y las revisiones de un solo repositorio pasaban por alto relaciones con servicios consumidores.
Esos fallos no eran simplemente problemas de calidad del modelo. Eran problemas de gestión del estado.
Un modelo puede razonar sobre el código presente en su contexto, pero una auditoría extensa produce muchas hipótesis paralelas. Cada hipótesis incluye archivos, límites de confianza, supuestos, experimentos, contraargumentos y cambios de estado. Comprimir ese historial en un resumen de conversación puede descartar detalles decisivos.
Cloudflare respondió externalizando el estado. Su infraestructura posterior trata los modelos de lenguaje como trabajadores sustituibles y conserva información de auditoría persistente fuera de sus ventanas de contexto. Una base de datos almacena la ejecución, el repositorio y la etapa de cada tarea.
La distinción explica por qué Cloudflare lanzó el punto de partida en lugar de presentarlo como el sistema interno terminado. Una habilidad puede codificar una secuencia rigurosa dentro de un entorno de programación. No puede proporcionar automáticamente inventario de flota, colas persistentes, grafos de dependencias o telemetría de producción.
Cloudflare informa que pasar de su primera habilidad a un sistema que abarca 128 repositorios tomó unas seis semanas. Ese sistema interno funciona con Rust, Go, C, Lua, TypeScript, Python y formatos de configuración sin orquestación específica por lenguaje.
Su flujo de trabajo más amplio separa el descubrimiento de la validación. El Vulnerability Discovery Harness mapea y busca posibles debilidades. Un Vulnerability Validation System distinto elimina duplicados, comprueba la relevancia en producción y gestiona la corrección.
Cloudflare afirma que utiliza modelos diferentes para esas dos etapas. Esta elección reduce la dependencia de los patrones de razonamiento recurrentes de un único modelo. También permite a la empresa cambiar de proveedores sin rediseñar el proceso de seguridad alrededor de un modelo concreto.
Esta postura neutral respecto a los modelos presiona a los proveedores que presentan el rendimiento en benchmarks como la principal medida de un producto de seguridad con IA. El argumento de Cloudflare es que la orquestación, las evidencias y el rechazo independiente determinan si la salida del modelo se convierte en trabajo de ingeniería útil.
La empresa no afirma que la habilidad recree su canalización de producción. Su propia guía indica que los equipos deberían comenzar con reconocimiento, búsqueda y validación. El rastreo entre repositorios y la deduplicación dedicada solo resultan útiles después de que el volumen de auditorías genere esos problemas.
Esta secuenciación ofrece a los equipos pequeños un punto de entrada práctico. Pueden comprobar si los prompts y las reglas de evidencia funcionan en su código antes de construir una infraestructura costosa a su alrededor.
También evita que el lanzamiento público se convierta en una demostración de producto engañosa. El repositorio ofrece el método que originó el sistema de Cloudflare, no el sistema completo que ahora opera en toda su flota.
El verdadero adversario es la revisión de código con IA de una sola pasada
La infraestructura de vulnerabilidades de Cloudflare cuestiona la suposición de que un modelo capaz puede inspeccionar un repositorio, identificar fallos reales y calificar de forma fiable sus propias conclusiones.
Una revisión de una sola pasada suele seguir un patrón conocido. El desarrollador da a un agente de programación acceso a un repositorio y le pide encontrar vulnerabilidades de seguridad. El agente lee archivos seleccionados, identifica patrones sospechosos y redacta un informe pulido.
Ese proceso puede producir pistas útiles. También puede ocultar tres fallos distintos.
Primero, el modelo decide qué inspeccionar sin conservar un registro persistente de lo que omitió. Segundo, el mismo proceso de razonamiento genera y evalúa cada afirmación. Tercero, un lenguaje persuasivo puede hacer que evidencias incompletas parezcan definitivas.
El flujo de trabajo de Cloudflare ataca cada fallo por separado. El registro de cobertura documenta la superficie de auditoría prevista. Los buscadores independientes examinan unidades delimitadas. Los validadores nuevos intentan refutar los candidatos en vez de mejorar su presentación.
Esta división adversarial es más importante que simplemente añadir más agentes. Diez agentes que comparten los mismos supuestos pueden generar diez versiones del mismo falso positivo. Cloudflare asigna roles distintos y da a los validadores autoridad para rechazar la teoría de un buscador.
La habilidad también exige un fallo de límite concreto. Un problema confirmado necesita un principal, recurso o resultado de seguridad afectado. Incumplir una práctica recomendada no se convierte automáticamente en una vulnerabilidad.
Esta distinción filtra hallazgos como comportamientos sin restricciones disponibles únicamente para un administrador ya confiable. También rechaza informes que describen una defensa ausente sin mostrar cómo un atacante cruza un límite real.
El proceso interno de Cloudflare utiliza requisitos de prueba más estrictos. Un hallazgo confirmado debe incluir una prueba reproducible contra la base de código original. La prueba no puede depender de cambios en el código fuente introducidos por el agente de búsqueda.
Esta regla aborda un modo de fallo especialmente peligroso. Un agente puede modificar código mientras experimenta y luego demostrar un exploit contra la versión modificada. Sin controles sobre el estado del código fuente, el informe resultante podría atribuir a la aplicación un fallo creado por el agente.
La validación mecánica añade otra capa. Las comprobaciones de código convencionales verifican si los archivos, rutas, parches y pruebas citados existen o se analizan correctamente. El modelo de lenguaje no decide si su propia salida satisface estos requisitos estructurales básicos.
Cloudflare afirma que una sola ejecución de la habilidad encontró aproximadamente la mitad de las vulnerabilidades que las ejecuciones repetidas terminaron descubriendo. Se trata de una observación comunicada por la empresa, no de una tasa de detección medida de forma independiente.
Aun así, el resultado respalda la decisión central de diseño del lanzamiento. Una ejecución completada no establece una cobertura completa, incluso cuando todos los hallazgos comunicados son válidos.
Por lo tanto, una auditoría rigurosa de seguridad de código con IA necesita dos afirmaciones de confianza distintas. Una se refiere a la validez de cada hallazgo. La otra se refiere a cuán exhaustivamente la auditoría buscó hallazgos.
La habilidad de auditoría de seguridad de Cloudflare expone ambas preguntas. Sus veredictos confirmados, no resueltos y rechazados describen la confianza probatoria. Su registro de cobertura describe el proceso de búsqueda.
El análisis estático tradicional sigue siendo relevante dentro de este modelo. Los escáneres deterministas destacan en patrones conocidos, reglas de flujo de datos y comprobaciones repetibles. Un agente puede explorar supuestos de confianza específicos de la aplicación o combinar debilidades a través de lógica desconocida.
La experiencia interna de Cloudflare también ofrece una advertencia sobre las preferencias asumidas de herramientas. La empresa afirma que sus buscadores no invocaron una ruta integrada de Semgrep durante un mes de ejecuciones. Prefirieron leer y ejecutar código, mientras solicitaban con frecuencia entornos o fixtures faltantes.
Esa observación no demuestra que el análisis estático carezca de valor. Demuestra que instalar una herramienta no garantiza que un agente la utilice de forma efectiva. Los equipos deben medir el comportamiento real de las herramientas dentro de su flujo de trabajo.
Por tanto, la competencia no es IA frente a escáneres convencionales. Es la salida no estructurada de un modelo frente a un proceso de auditoría que combina comprobaciones deterministas, exploración especializada y verificación adversarial.
Los hallazgos estructurados reducen el ruido, pero no prueban la seguridad
La parte más sólida del lanzamiento es su negativa a tratar una salida de modelo plausible como evidencia confirmada, aunque esa disciplina no puede medir vulnerabilidades no descubiertas.
Cloudflare informa que su arnés interno de descubrimiento generó 20.799 candidatos en bruto. Cerca de 12.057 superaron la fase inicial de validación antes de entrar en un grupo de validación más amplio.
Después de que los hallazgos de otro arnés se incorporaran al sistema, el grupo central contenía 13.841 registros. La deduplicación eliminó 5.442, mientras que 1.154 se desviaron por corresponder al repositorio equivocado o a casos de bajo riesgo. Cloudflare afirma que quedaron 7.245 hallazgos accionables para los equipos de ingeniería.
Estas cifras son útiles porque muestran cuánto filtrado existe entre la generación y la corrección. No deberían interpretarse como una referencia independiente de la precisión de detección.
Cloudflare selecciona sus propios repositorios, modelos, prompts, clases de ataque y definiciones. Las cifras publicadas describen su canalización operativa. No establecen cómo funciona la habilidad pública en una base de código no relacionada.
La empresa evita explícitamente afirmar una tasa de falsos negativos. Un repositorio real no cuenta con un conjunto completo de etiquetas que contenga todas las vulnerabilidades, por lo que la cobertura no puede calcularse directamente. Las ejecuciones repetidas que siguen encontrando errores muestran una cobertura incompleta, pero no el tamaño de la brecha restante.
Esa incertidumbre debe ocupar el centro de cualquier evaluación. Un informe verificado puede establecer que varios hallazgos son reales. No puede establecer que el código auditado sea seguro.
La habilidad pública intenta comunicar esta diferencia mediante tres veredictos.
Un hallazgo confirmado cuenta con un rastreo completo de la fuente y un resultado observado delimitado. Un registro de necesita validación conserva una pregunta exacta sin resolver sin asignar una gravedad no respaldada. Un registro rechazado documenta por qué un candidato no prosperó.
Conservar candidatos rechazados tiene valor práctico. Las ejecuciones futuras pueden distinguir una ruta genuinamente nueva de una idea refutada anteriormente. Los revisores también pueden examinar si el rechazo dependía de hechos que cambiaron después.
Sin embargo, la salida estructurada puede crear su propia ilusión de certeza. Un registro JSON válido no es necesariamente una conclusión de seguridad válida. La validación de esquemas puede confirmar campos obligatorios y valores aceptados, pero no puede demostrar que un exploit atraviese un límite real.
Cloudflare aborda esa limitación mediante una nueva verificación de la fuente. El verificador revisa de forma independiente la afirmación sobre el código, y una sustitución sustancial recibe otra comprobación. Sin embargo, la calidad sigue dependiendo del comportamiento del modelo, el contexto disponible y la corrección del modelo de amenazas.
El aislamiento mediante sandbox presenta otro desafío de adopción. La habilidad requiere controles del sistema operativo alrededor de compilaciones y experimentos controlados por el objetivo. Muchos entornos cotidianos de agentes de programación no proporcionan ese aislamiento con límites claros de recursos y red.
Los equipos que ignoren este requisito corren el riesgo de ejecutar dependencias maliciosas, scripts de compilación o fixtures de prueba. Los equipos que lo respeten deberán mantener algunas pistas prometedoras como no resueltas hasta que haya disponible un entorno seguro.
La inyección de prompts plantea una preocupación relacionada. Los archivos fuente, la documentación, el texto de incidencias y los artefactos generados pueden contener instrucciones dirigidas al agente. El flujo de trabajo comercial posterior de Cloudflare afirma que trata el código, los registros y los metadatos como evidencia, no como instrucciones.
Ese mismo límite debe existir en el uso local. Un agente de seguridad nunca debería interpretar el contenido de un repositorio como autorización para exponer credenciales, ampliar el acceso a la red o modificar sistemas no relacionados.
El marco de software seguro de NIST ofrece un punto de referencia útil. Trata el desarrollo seguro como un conjunto de prácticas organizativas que abarcan preparación, protección, producción y respuesta ante vulnerabilidades.
Una habilidad de auditoría con IA cubre solo una parte de ese ciclo de vida. Puede ayudar a investigar el código fuente y documentar posibles debilidades. No establece un diseño seguro, gobernanza de acceso, procedencia de dependencias, controles de despliegue ni preparación ante incidentes.
La revisión humana sigue siendo esencial por la misma razón. Los ingenieros entienden el comportamiento previsto, la arquitectura de producción, el impacto empresarial y los controles compensatorios que quizá no aparezcan en un repositorio.
Por tanto, el lanzamiento debería cambiar la forma de la revisión, no eliminar a los revisores. Los equipos de seguridad pueden dedicar menos tiempo a clasificar afirmaciones sin respaldo y más a probar evidencia, priorizar la exposición y aprobar correcciones.
Cloudflare está conectando los hallazgos de código con el contexto de producción
La estrategia más amplia de Cloudflare consiste en combinar hallazgos de código fuente con telemetría de tráfico y defensiva, algo que la habilidad independiente no puede hacer por sí sola.
Un escáner de código fuente puede identificar un controlador inseguro sin saber si se ejecuta en producción. Puede no saber qué ruta llega al código, con qué frecuencia los clientes la utilizan o si los controles activos bloquean las solicitudes relevantes.
El servicio por invitación Vulnerability Discovery and Remediation de Cloudflare intenta cerrar esa brecha. La empresa anunció el servicio el 3 de septiembre de 2026 como parte de Cloudflare Managed Defense.
Según su anuncio sobre remediación con contexto, el servicio conecta el análisis autorizado de código con Web Assets, datos de Web Application Firewall y observabilidad de Workers.
El servicio utiliza modelos OpenAI Daybreak, incluido GPT-5.6 Cyber, para reconocimiento, búsqueda y validación. Cloudflare afirma que los prompts pasan por AI Gateway hasta los servidores de OpenAI. La inferencia del modelo no se ejecuta en el edge de Cloudflare.
Esta implementación ilustra por qué la habilidad de código abierto y el servicio comercial cumplen funciones distintas. La habilidad organiza una investigación a nivel de repositorio. El servicio añade información sobre rutas desplegadas, volumen de solicitudes, eventos de seguridad y controles existentes.
El contexto de producción puede cambiar la prioridad sin alterar la validez técnica. Una vulnerabilidad real en una ruta de desarrollo inaccesible merece un tratamiento distinto que el mismo fallo en un endpoint público muy utilizado.
Cloudflare afirma que su proceso puede proponer un parche de código y una regla de WAF de alcance limitado cuando la evidencia respalda ambos. La regla de edge puede reducir la exposición mientras los ingenieros revisan el cambio permanente en el código.
El servicio no permite que el modelo despliegue su propia propuesta. Las llamadas a herramientas se registran y se evalúan frente a una política de acceso. Las comprobaciones externas prueban los parches y las reglas, mientras los clientes deciden si se implementan los cambios.
Este enfoque convierte el arnés de vulnerabilidades de Cloudflare en algo más que un motor de descubrimiento. Pasa a formar parte de un sistema de gestión de exposición que vincula evidencia de código fuente, contexto de ejecución, mitigación y corrección.
Esta estrategia también explica el énfasis de la empresa en informes neutrales respecto al objetivo. El mismo método de auditoría puede inspeccionar distintos lenguajes y tipos de aplicaciones, mientras que los sistemas específicos de producción aportan el contexto necesario para priorizar.
La mayoría de los equipos que utilicen la habilidad pública carecerán de una visibilidad de red equivalente. Aun así, pueden mejorar sus decisiones aportando manifiestos de despliegue, mapas de rutas, registros de propiedad y registros sanitizados como evidencia controlada.
Deben mantener clara la procedencia. Un hallazgo de código fuente, una afirmación de despliegue y una observación de tráfico son afirmaciones diferentes. Combinarlas dentro de un mismo párrafo no debería borrar el origen de cada hecho.
Aquí es donde importa una gestión disciplinada del conocimiento. Los equipos de ingeniería necesitan un registro consultable que conecte las decisiones de arquitectura, la evidencia de auditoría, las hipótesis rechazadas y las correcciones posteriores. Una base de conocimiento técnica mantenida puede conservar esos registros más allá de una sesión de agente.
La habilidad pública ya avanza en esa dirección mediante artefactos persistentes. Las notas de arquitectura, los registros de cobertura, los hallazgos legibles por máquinas y los informes humanos ofrecen a los futuros revisores algo más duradero que una transcripción de chat.
Aun así, un repositorio sigue siendo una imagen incompleta. La política de infraestructura, la gestión de secretos, la configuración de autorización, las dependencias de servicios y el comportamiento de los usuarios pueden determinar si una debilidad a nivel de código fuente se vuelve explotable.
Los equipos con más probabilidades de beneficiarse tratarán la habilidad como un generador de evidencia dentro de un programa de seguridad más amplio. Los equipos con más probabilidades de tener dificultades esperarán que un escaneo de repositorio responda a preguntas sobre riesgo de producción que el repositorio no contiene.
Tres señales mostrarán si el lanzamiento importa
La próxima prueba es si los desarrolladores pueden reproducir la disciplina de Cloudflare sin la infraestructura privada, los datos y el personal de seguridad de Cloudflare.
La primera señal es la calidad de los artefactos públicos de auditoría. Una adopción útil producirá informes con límites de confianza precisos, evidencia reproducible, candidatos rechazados significativos y preguntas no resueltas planteadas con honestidad.
Un aumento en el número de instalaciones mostraría interés, pero no eficacia. La mejor medida es si equipos independientes publican auditorías cuyos hallazgos confirmados resisten la revisión de los mantenedores.
El diseño actual del lanzamiento respalda esa evaluación. Sus esquemas de cobertura y hallazgos crean artefactos comparables, mientras que los validadores pueden detectar registros malformados antes de que comience la revisión humana.
La segunda señal es cómo evoluciona el repositorio tras el uso real. El arnés interno de Cloudflare aprendió de ejecuciones repetidas, entornos ausentes, cobertura superficial y hallazgos rechazados. La habilidad pública se enfrentará a una variedad más amplia de lenguajes, sistemas de compilación y plataformas de agentes.
Hay que observar cambios en las guías de clases de ataque, los requisitos de sandbox, el modelado de cobertura y el tratamiento de falsos positivos. Esas actualizaciones revelarán qué partes del proceso de Cloudflare se transfieren con facilidad y cuáles dependen de sistemas internos.
La distinción entre hallazgos confirmados y aquellos que necesitan validación merece especial atención. Si los usuarios externos convierten regularmente pistas no resueltas en informes seguros de sí mismos, las salvaguardas del flujo de trabajo existirán solo sobre el papel.
La tercera señal es si otras plataformas de seguridad adoptan una verificación igualmente independiente. Las herramientas de código con IA ya compiten en velocidad, cantidad de incidencias y asistencia para la corrección. Cloudflare está desplazando la atención hacia la trazabilidad de la evidencia, las tasas de rechazo y la contabilidad de cobertura.
Ese cambio reforzaría el impacto más amplio de la habilidad de auditoría de seguridad de Cloudflare, incluso si los desarrolladores nunca instalan este paquete específico. Un mercado que pregunta quién verificó un hallazgo es más saludable que uno que recompensa el mayor número de alertas.
Los resultados internos de Cloudflare sugieren por qué esto importa. Miles de candidatos en bruto desaparecieron durante la validación, la deduplicación y el juicio contextual. Generar más candidatos no era la capacidad escasa. Convertirlos en trabajo fiable sí lo era.
También hay señales prácticas dentro de las organizaciones individuales. Los responsables de seguridad deberían hacer seguimiento de cuántos hallazgos sobreviven a una revisión independiente, cuánto crece la cobertura a lo largo de ejecuciones repetidas y cuántos parches superan las pruebas de regresión.
También deberían registrar el coste y el tiempo transcurrido de las auditorías. Cloudflare afirma que sus escaneos internos completos pueden tardar horas, y que su ejecución más larga superó las 14 horas. La habilidad pública puede consumir un tiempo de modelo considerable mientras los cazadores y verificadores examinan áreas separadas.
Ese gasto puede justificarse en repositorios sensibles o revisiones profundas periódicas. Puede que no sea adecuado para cada pull request. Las comprobaciones más pequeñas, las reglas deterministas y las revisiones de amenazas específicas siguen siendo opciones más adecuadas para obtener comentarios rápidos.
La decisión importante no es si sustituir los escáneres existentes por una skill de agente. Es determinar dónde una auditoría de agente basada en evidencias aporta información que los controles actuales pasan por alto.
Los desarrolladores pueden comenzar con un repositorio acotado y un límite de confianza claramente definido. Deben revisar el registro de cobertura antes de leer el informe final y, después, contrastar cada problema confirmado con el código fuente sin modificar.
Deben conservar los registros no resueltos en lugar de forzar un veredicto. Deben ejecutar las pruebas únicamente dentro de un sandbox adecuado y mantener las decisiones de remediación bajo control humano.
Si ese proceso genera hallazgos reproducibles que los responsables de mantenimiento aceptan, Cloudflare habrá publicado un método de seguridad significativo. Si los usuarios lo reducen a otro prompt genérico, sus seis fases añadirán complejidad sin generar confianza.
La skill de auditoría de seguridad de Cloudflare plantea, por tanto, un desafío concreto para los proveedores de seguridad de IA y los equipos de ingeniería: dejen de medir el éxito por la cantidad de vulnerabilidades que un modelo puede describir. Midan qué afirmaciones resisten una revisión adversarial, qué áreas se examinaron realmente y qué hechos siguen siendo desconocidos.
