Anthropic ha publicado el 2 de noviembre de 2026 una investigación titulada "Discovering and Exploiting Vulnerabilities with Claude". Plantea que un modelo de IA puede ayudar a encontrar fallos de seguridad y también a demostrar que se pueden explotar. Para cualquier equipo que trabaje con vulnerabilidades con Claude, el tema importa por dos razones: la misma capacidad que acelera una auditoría puede abaratar un ataque, y Anthropic decide estudiarla públicamente en lugar de esconderla.
La pieza llegó a Hacker News con un impacto discreto, 3 puntos y 0 comentarios en el momento de recoger la fuente. Todavía no hay debate comunitario ni análisis independientes sobre su contenido. Por eso este artículo separa con cuidado lo que está confirmado de lo que no. Repasamos qué se sabe de la publicación, qué implica para quien construye software con Claude y cómo usar ya hoy el modelo en tareas de seguridad defensiva, sin depender de afirmaciones que la fuente disponible no respalda.
¿Qué ha publicado Anthropic sobre vulnerabilidades con Claude?
Lo verificable es esto: según el blog de investigación de Anthropic, la compañía ha dedicado un trabajo específico a dos tareas distintas, descubrir vulnerabilidades y explotarlas. El propio título las nombra por separado, y la diferencia tiene peso técnico:
- Descubrir: localizar un fallo en código, configuración o dependencias. Por ejemplo, una validación de entrada ausente o un desbordamiento de memoria.
- Explotar: construir una prueba de concepto (PoC, proof of concept), es decir, una demostración práctica de que el fallo se puede aprovechar de verdad.
La fuente recogida no incluye métricas de rendimiento, ni los modelos evaluados, ni benchmarks o tasas de acierto. Cualquier cifra que circule sobre cuántas vulnerabilidades encontró Claude o en qué porcentaje de casos logró explotarlas conviene contrastarla con el texto original antes de darla por buena.
Nuestro análisis: lo relevante es el encuadre. Un laboratorio que estudia en abierto la capacidad ofensiva de su propio modelo indica que esa capacidad ya es lo bastante seria como para medirla, y que prefiere hacerlo antes de que otros lo hagan sin controles.
Qué significa para los builders que usan Claude en seguridad
Si trabajas con Claude en producción, la investigación encaja con algo que ya ocurre en muchos equipos: el modelo se usa como revisor de código. Las consecuencias prácticas van por tres frentes.
1. Revisión de seguridad dentro del flujo diario
Un agente de código puede revisar cada pull request en busca de patrones peligrosos: inyección SQL, secretos en el repositorio, deserialización insegura o permisos excesivos. No sustituye a un pentest profesional, pero detecta antes los fallos más habituales y reduce lo que llega a revisión humana.
2. Aislar al agente cuando toca ejecutar código
Validar si un fallo es explotable implica ejecutar código potencialmente peligroso. Hacerlo en tu máquina de trabajo es mala idea. Proyectos como el que permite correr el agente en un sandbox aislado muestran el patrón correcto: contenedor sin acceso a credenciales, red restringida y sistema de archivos efímero.
3. Límites de uso y doble filo
Anthropic ya ha mostrado que pone frenos a usos sensibles, como en el caso de los límites a la ingeniería inversa y el clonado. Es razonable esperar que algunas peticiones ofensivas sean rechazadas o exijan más contexto, sobre todo fuera de un marco de investigación autorizado. Planifica tus flujos de seguridad pensando en ese comportamiento.
Nuestro análisis: frente a escáneres estáticos clásicos (SAST), la ventaja de un LLM es razonar sobre la lógica de negocio, no solo sobre patrones conocidos. Su punto débil es la reproducibilidad: dos ejecuciones pueden dar resultados distintos. Lo sensato es combinar ambos enfoques, no elegir uno.
Cómo empezar a usar Claude para encontrar vulnerabilidades en tu código
Puedes aplicar ya un enfoque defensivo, centrado en tu propio código y con autorización explícita:
- Define el alcance: solo repositorios propios o con permiso por escrito.
- Pide salida estructurada: tipo de fallo, archivo, línea, severidad y propuesta de corrección.
- Exige verificación humana: trata cada hallazgo como hipótesis hasta confirmarlo.
- Añade guardrails, siguiendo la lógica de los guardrails para que la IA no publique código inseguro: nada se fusiona sin revisión.
Un ejemplo mínimo con el SDK de Python:
import anthropic
client = anthropic.Anthropic()
codigo = open("app/login.py").read()
resp = client.messages.create(
model="MODELO_ACTUAL_DE_CLAUDE",
max_tokens=2000,
system="Eres un auditor de seguridad defensiva. Analiza solo el código proporcionado por su propietario.",
messages=[{"role": "user", "content": f"Lista posibles vulnerabilidades en JSON (tipo, línea, severidad, corrección):\n{codigo}"}]
)
print(resp.content[0].text)Sustituye el identificador del modelo por el que tengas disponible en tu cuenta. Si quieres llevar esto a un pipeline más completo, con agentes que revisan, ejecutan tests y proponen parches, te conviene aprender a integrar Claude Code en tu flujo de desarrollo con permisos bien acotados.
Nuestro análisis: empieza por un único módulo crítico, como autenticación o pagos, y compara los hallazgos de Claude con los de tu herramienta SAST actual durante unas semanas. Esa comparación vale más que cualquier benchmark genérico.
Qué falta por saber
Con la información disponible quedan preguntas abiertas: qué modelos se evaluaron, en qué tipo de software, con qué tasa de falsos positivos y qué salvaguardas aplica Anthropic para evitar abusos. Tampoco hay datos sobre disponibilidad regional ni sobre implicaciones regulatorias para España o LATAM, así que no conviene extrapolar. Si tu empresa está sujeta a normativa europea de ciberseguridad o de IA, revisa con tu equipo legal antes de automatizar pruebas ofensivas.
Conclusión
La investigación de Anthropic sobre vulnerabilidades con Claude confirma algo que muchos equipos intuían: los modelos ya son útiles en seguridad, por ambos lados. El insight práctico es que la ventaja no la tendrá quien use la IA para atacar, sino quien la integre antes en su ciclo de desarrollo para cerrar fallos que antes nadie tenía tiempo de buscar. La asimetría clásica de la ciberseguridad, en la que al atacante le basta un fallo y el defensor debe cubrirlos todos, puede reducirse si la revisión automatizada se convierte en rutina diaria. El siguiente paso es leer el texto original, probar Claude sobre un módulo propio y medir resultados con criterio.
Comparte este artículo si te fue útil.
