Claude Security está en beta pública: qué afirma “Scan to Fix” y qué no

El producto de seguridad de Anthropic ya está en beta pública para Claude Enterprise, y su propuesta en una sola frase es una secuencia más que un adjetivo: del escaneo a la corrección, hecho sin fricción. La mecánica que subyace a esa frase se expone con claridad en la página del producto: Claude escanea tu base de código con Claude Mythos, valida los hallazgos y sugiere parches que puedes revisar y aprobar. Tres verbos, un nombre de modelo y un límite de alcance que es fácil pasar por alto: esto es una beta, y está pensada para clientes de Enterprise, no para cualquiera que tenga un repositorio.

La pregunta interesante nunca fue si un modelo de lenguaje puede encontrar una vulnerabilidad. Los modelos llevan haciendo eso desde hace un tiempo, a veces lo suficientemente bien como para avergonzar a los humanos que escribieron el código. La pregunta interesante es qué ocurre entre el momento en que aparece un hallazgo y el momento en que se cierra, porque en esa brecha es donde viven los atrasos de seguridad: una cola de problemas plausibles, ordenada por nadie, asignada a todos, cerrada por casualidad. La respuesta de Anthropic es una canalización con cuatro etapas, y cada etapa hace una afirmación que puede examinarse por sí sola.

Qué significa “beta pública para Claude Enterprise”

La frase sobre la disponibilidad es inusualmente directa, y vale la pena citarla en lugar de parafrasearla: disponible en beta pública para Claude Enterprise. Debajo hay dos botones: contactar con ventas y leer el tutorial. Ninguno es un formulario de registro. En la práctica, eso significa que el comprador es una empresa que ya tiene un acuerdo Enterprise y un equipo de seguridad con suficiente peso como para pedir un nuevo escáner, en lugar de un ingeniero individual que quiere dirigir algo a un proyecto paralelo.

Existe una segunda vía de entrada, más ligera. El plugin Claude Security para Claude Code está en beta. Es un software distinto, con un enfoque de despliegue diferente —escanear, validar y aplicar parches dentro de Claude Code mientras el código permanece en tu entorno—, y es la versión que le importa a un equipo cuyo obstáculo no es el presupuesto, sino una norma sobre dónde se permite que vaya el código fuente.

El escaneo no se detiene.

El primer comportamiento documentado es la exploración profunda inicial: Claude la ejecuta una vez sobre una base de código y luego sigue escaneando a medida que el código cambia. Es una frase pequeña con una gran consecuencia operativa. Un escaneo puntual es una fotografía. Las bases de código no son fotografías; son el clima. Un hallazgo que era correcto el día de la auditoría y que tres fusiones posteriores han corregido a medias es peor que no tener ningún hallazgo, porque consume la atención de las personas que tienen que volver a leerlo.

El escaneo continuo es también la parte del producto más difícil de falsificar. Requiere que el escáner entienda qué cambios importan, una habilidad distinta de encontrar una vulnerabilidad en un árbol estático. La página no describe cómo funciona esa priorización, y este artículo no intentará adivinarlo.

El único eje en el que la afirmación es específica

Anthropic afirma que Claude Security rastrea los flujos de datos entre archivos y repositorios para encontrar vulnerabilidades que los escáneres de coincidencia de patrones podrían no detectar. Esa es la afirmación más verificable de toda la descripción del producto, porque nombra un mecanismo en lugar de un resultado.

La coincidencia de patrones, como su nombre indica, busca una forma conocida como peligrosa: una llamada a función con un argumento contaminado, una cadena concatenada en una consulta, una API conocida como insegura. Es rápida, es barata, y es la razón por la que los escáneres tradicionales son famosos por dos cosas a la vez: detectar la misma clase de error en todas partes donde aparece y enterrar al equipo en hallazgos que resultan ser inalcanzables. La alternativa es seguir un valor desde donde entra en el sistema hasta donde se usa, atravesando los límites entre archivos y servicios. Ahí es donde se esconden los errores reales, y también donde el análisis se vuelve costoso, porque la herramienta tiene que mantener más contexto del que cabe en una sola función.

No obstante, fíjate en la matización de la frase. Podría no detectar. Esa es la palabra correcta que hay que usar cuando un proveedor no tiene ningún punto de referencia al que remitirse, y también es la razón por la que esta afirmación debería probarse con tu propio código base en lugar de aceptarse como una propiedad del producto.

Verificación adversarial y un modelo de amenazas que puedes editar

La segunda etapa es la que aborda el problema de los falsos positivos que todo equipo de seguridad conoce. Cada hallazgo pasa por una verificación adversarial antes de llegar al equipo. Algo intenta refutar el hallazgo antes de que lo vea una persona: demostrar que la entrada no puede llegar realmente al sink, o que la ruta está protegida aguas arriba, o que el código en cuestión está muerto.

La segunda mitad de esa misma frase es, sin llamar la atención, la decisión de diseño más interesante de la página. Un modelo de amenazas que tu equipo puede editar decide qué vale la pena señalar. En la práctica, eso pone la definición de relevancia en manos del cliente. Un escáner que decide la gravedad por su cuenta siempre está ligeramente equivocado, porque la gravedad es contextual: un endpoint no autenticado en una herramienta administrativa interna es un problema distinto del mismo endpoint en internet público, y ningún proveedor puede saber cuál de los dos está viendo. Permitir que se edite el modelo de amenazas es la admisión honesta de eso.

También genera trabajo. Un modelo de amenazas que nadie mantiene se convierte en un filtro que oculta las cosas que a nadie se le ocurrieron, que es justo lo contrario de para lo que sirve un escáner. Los equipos que obtengan valor de esto serán los que traten el modelo de amenazas como un documento vivo con un responsable, de la misma manera que tratan los runbooks.

Un parche es la unidad de salida.

Cada hallazgo incluye un parche recomendado para que el equipo lo revise y lo apruebe, y Claude marca el hallazgo como corregido una vez que la corrección se implementa. En esa frase hay dos afirmaciones y merecen separarse.

Lo primero es que la salida de un escaneo es un cambio, no un ticket. Esa es la diferencia entre decirle a un ingeniero que su código tiene un problema y decirle cómo se ve el código corregido. Comprime la parte menos agradable del trabajo de seguridad —entender el código de otra persona lo suficiente como para corregirlo sin romper lo que hace— y lo comprime para la persona que menos entiende el código. Ese es también el riesgo: un parche que parece correcto y pasa la revisión porque el revisor estaba cansado es un nuevo error con una marca de verificación verde.

La segunda afirmación trata sobre el cierre. Claude marca un hallazgo como corregido en cuanto se implementa la corrección, de modo que los hallazgos se cierran en lugar de acumularse. El backlog no es un fallo de detección. Es un fallo de registro: la misma vulnerabilidad se reporta siete veces a lo largo de siete escaneos, y la cola crece más rápido de lo que cualquiera puede vaciarla. Rastrear un hallazgo hasta el commit que lo resuelve es el mecanismo que hace que un escáner continuo sea soportable en lugar de desmoralizante.

Anthropic afirma explícitamente que la persona sigue en el circuito y que cada parche requiere revisión y aprobación. Cualquiera que despliegue esto debería considerar esa la frase que sostiene todo, y no el descargo de responsabilidad al final.

Dos lanzamientos, una dirección

Claude Security no llegó de forma aislada. Anthropic lanzó Code Review como disponibilidad general el 15 de octubre de 2026, y el escaneo continuo de Claude Security junto con el seguimiento de correcciones llegaron el 21 de octubre de 2026 en beta pública para Claude Enterprise. Leídos en conjunto, ambos dicen algo sobre la dirección: la revisión está pasando de ser una puerta por la que un cambio pasa al final a un proceso que se ejecuta junto con el cambio mientras se escribe. Los días entre esas dos fechas son lo bastante cortos como para que los productos se evalúen como una sola historia sobre hacia dónde va el trabajo de seguridad, no como dos lanzamientos no relacionados.

Lo que no se publica, y la cifra que lo resolvería

La lista de incógnitas aquí es más larga que la de afirmaciones, y eso es normal en una beta pública, no un escándalo. No se publica qué parte de una base de código cubre un escaneo. No se publica la duración del escaneo. No se publican las tasas de falsos positivos. No se publican los benchmarks de detección. No hay una evaluación independiente. No se publica el precio por asiento, ni tampoco la lista de idiomas compatibles.

De todos ellos, el benchmark de detección de lo que no se detecta es el que cambia una decisión de compra. Sin él, “detecta lo que los escáneres de coincidencia de patrones pasan por alto” es una afirmación direccional que no puede compararse con el escáner que ya está en el presupuesto. La lista de lenguajes compatibles es la segunda: un repositorio políglota es el caso normal en una empresa de cualquier tamaño, y un escáner que es excelente en tres lenguajes y está ausente en los otros cinco es un escáner que produce una imagen engañosa de la superficie de riesgo.

Nada de esto significa que el producto no funcione. Significa que la evaluación tiene que hacerla el comprador, con el código del propio comprador, y que una demo no bastará.

Cómo evaluarlo de todos modos

Si tu equipo va a probarlo, el experimento útil no es un repositorio nuevo con una debilidad plantada deliberadamente. Es un repositorio que ya tiene historia: un servicio que tuvo un incidente el año pasado, una biblioteca con una vulnerabilidad conocida que tardó dos semanas en cerrarse, un módulo al que todo el mundo le tiene un poco de miedo. Apunta el escaneo a eso y compara lo que encuentra con los hallazgos que tu equipo ya anotó. La recall sobre problemas conocidos es medible incluso cuando un proveedor no ha publicado un benchmark, porque la verdad fundamental está en tu propio registro de incidentes.

Segundo, observa el modelo de amenazas. Si lo primero que hace tu equipo es desactivar la mayoría de las categorías para reducir la cola, has aprendido que el modelo predeterminado no se corresponde con el riesgo que tu equipo realmente asume, y deberías corregir el modelo en lugar del filtro. Tercero, mide el paso que importa: cuánto tiempo pasa desde que aparece un hallazgo hasta que se fusiona un parche. Ese número es tuyo, es comparable entre herramientas y es el que el producto realmente afirma mover.

Dónde se ubica un router, y dónde no

Vale la pena dejar clara la frontera. Claude Security es una aplicación de Anthropic. No la alojamos, no la vendemos y no podemos decirle qué encontró o dejó de encontrar en su repositorio. El escáner se ejecuta en Claude Mythos, y no afirmamos alojar ese modelo.

Lo que hacemos es ejecutar modelos. Un endpoint compatible con OpenAI, una clave, más de 200 modelos detrás, el precio de lista del proveedor se transfiere sin agregar margen, y conmutación automática por fallo entre proveedores cuando uno de ellos titubea. Claude Opus 5.5 está en ese catálogo a $4.00 por millón de tokens de entrada y $20.00 por millón de tokens de salida, con un contexto de 1M de tokens y lecturas de caché a $0.20 por millón. Eso es un hecho sobre nuestro catálogo, no una afirmación sobre el escáner.

Donde cobra relevancia es en la parte de un programa de seguridad que no es un escáner: la herramienta interna que resume mil hallazgos en algo que una persona pueda clasificar, el agente que redacta el aviso, el paso de revisión que un equipo quiere construir en torno a sus propias reglas. Esas son llamadas ordinarias a modelos, y un enrutador es una forma razonable de hacerlas sin codificar rígidamente un proveedor. El DSL de enrutamiento importa cuando un paso quiere un modelo pequeño para volumen y el siguiente quiere uno cuidadoso para el juicio; la conmutación automática por error importa cuando la llamada está dentro de una canalización que se ejecuta a las tres de la mañana y nadie está mirando.

En qué te está pidiendo realmente la beta que confíes

Si dejamos a un lado el marco, el producto hace tres apuestas. Que un modelo que razona sobre código encuentra cosas que la coincidencia de patrones no. Que una segunda pasada adversarial basta para mantener el ruido a raya. Que un hallazgo solo está terminado cuando se publica un parche y la cola se cierra detrás de él. La tercera apuesta es la menos glamurosa y la más probable de acertar, porque es una afirmación sobre el proceso y no sobre la inteligencia.

La primera apuesta es la que hay que probar. Anthropic ha publicado el mecanismo —el rastreo del flujo de datos entre archivos y repositorios— y no ha publicado ninguna cifra que demuestre lo bien que funciona. Eso no es motivo para descartar el producto. Es motivo para ejecutarlo contra un repositorio cuya historia ya conozcas y juzgarlo por los hallazgos que puedas verificar, no por los que parecen impresionantes en una demostración.