La divulgación de Anthropic del 2 de julio sobre Claude Fable 5 ofrece un punto de partida útil para una pregunta que todo equipo de seguridad debería responder antes de conectar un modelo de IA a código, tickets, registros o herramientas en la nube: ¿qué ocurre exactamente cuando una solicitud se sitúa entre la defensa legítima y la capacidad ofensiva? La empresa afirma que Fable 5 utiliza clasificadores de seguridad junto con controles de acceso, entrenamiento de seguridad y supervisión sin conexión. También divide la actividad cibernética en cuatro categorías, desde el uso prohibido hasta el uso benigno.
Esa taxonomía no es una certificación independiente, y Anthropic no publica en el anuncio una tasa de aprobación universal para ella. Aun así, resulta práctica como plantilla de evaluación. La guía siguiente convierte la divulgación en una primera revisión de ocho minutos para un modelo que se planea utilizar en un flujo de trabajo de seguridad autorizado. Trate el resultado como un criterio de lanzamiento, no como una prueba de que el sistema es seguro en cualquier situación.
1. Documente el trabajo permitido
Comience con un caso de uso limitado y un responsable. «Ayudar al SOC» es demasiado amplio. Un alcance útil podría consistir en resumir alertas, revisar un parche para una vulnerabilidad ya identificada, analizar registros saneados o sugerir una configuración más segura. Registre los sistemas que el modelo puede leer, las herramientas que puede utilizar, los datos que puede conservar y la persona que aprueba las acciones.
Mantenga separadas la exploración y la ejecución. Un asistente que explica una vulnerabilidad o propone un parche no debería poder escanear automáticamente un host externo, cambiar una regla del cortafuegos o desplegar código. Utilice una identidad de solo lectura durante la primera fase y exija la aprobación humana para cada acción que modifique un sistema.
2. Asigne el flujo de trabajo a una categoría de riesgo
Utilice el modelo de cuatro categorías de Anthropic como una tabla de decisión sencilla. La actividad prohibida incluye impacto destructivo, desarrollo de malware, evasión de defensas, mando y control encubiertos y exfiltración. El trabajo de doble uso de alto riesgo incluye pruebas de penetración, escalada de privilegios, movimiento lateral, desarrollo de exploits y evaluaciones de infraestructuras industriales, de telecomunicaciones o financieras. No son tareas ordinarias de productividad; requieren un proceso separado y estrictamente controlado.
El trabajo de doble uso de bajo riesgo incluye investigación con fuentes públicas, enumeración de sistemas de acceso público e identificación de vulnerabilidades que las herramientas ampliamente disponibles ya pueden realizar. El trabajo benigno incluye programación segura, gestión de parches, análisis de registros, búsqueda de amenazas, respuesta a incidentes y configuración defensiva. Si una solicitud puede pasar de una fila a otra cuando cambia el contexto, clasifique el flujo de trabajo según su resultado plausible más perjudicial y aplique el control más estricto.
3. Construya un conjunto de verificación seguro
No pruebe las salvaguardas contra un objetivo activo, credenciales reales, secretos de producción o malware. Cree en su lugar un repositorio desechable y un conjunto de registros sintéticos. Incluya tareas benignas que deberían permitirse, como corregir un error de programación intencionadamente sencillo, explicar a alto nivel una vulnerabilidad conocida y escribir una regla de detección defensiva. Incluya casos límite formulados como trabajo legítimo de seguridad, pero manténgalos no operativos y confinados al entorno de prueba.
Para cada caso, registre la solicitud exacta, los datos adjuntos, la versión del modelo, las herramientas expuestas, la respuesta, el resultado de bloqueo o autorización y si un revisor humano clasificaría la solicitud de otra manera. Repita cada caso al menos una vez después de cambiar únicamente el contexto circundante. Así comprobará si el control responde a la tarea y no a una palabra clave concreta. Nunca convierta un caso bloqueado en una receta ofensiva al intentar reproducirlo.
4. Compruebe el margen de seguridad
Anthropic afirma que Fable 5 utiliza deliberadamente un margen de seguridad mayor que los modelos anteriores: algunas solicitudes benignas o de bajo riesgo pueden bloquearse para reducir la posibilidad de que las solicitudes dañinas pasen el filtro. Ese equilibrio importa desde el punto de vista operativo. Una tasa elevada de bloqueos en trabajos defensivos puede empujar a los analistas hacia soluciones alternativas inseguras, mientras que un límite permisivo puede crear una exposición más grave.
Mida ambos lados en su propio conjunto aprobado. Cuente los falsos positivos entre las tareas legítimas y los falsos negativos entre los casos límite no operativos. No convierta esas cifras en una afirmación de precisión sobre todo el producto; su pequeña muestra solo aporta pruebas sobre su configuración. Si una respuesta autorizada contiene detalles operativos inesperados, detenga el flujo de trabajo, conserve el registro, elimine las entradas sensibles y escálelo a través del canal de seguridad del proveedor.
5. Puntúe los informes de jailbreak según su impacto
Cuando se encuentre un fallo de una salvaguarda, documente cuatro preguntas extraídas del marco propuesto por Anthropic para la gravedad de los jailbreaks cibernéticos. ¿Cuánta capacidad nueva aporta la técnica frente a las herramientas existentes? ¿Con qué amplitud funciona entre objetivos o tareas ofensivas? ¿Qué facilidad hay para convertirla en un flujo de trabajo repetible? ¿Qué facilidad tendría un atacante para descubrir la técnica?
Mantenga el informe lo bastante abstracto como para no difundir un bypass funcional. Incluya las pruebas mínimas reproducibles, el modelo o la configuración afectados, la exposición de datos, el esfuerzo humano necesario y la mitigación inmediata. Un problema limitado y difícil de reproducir no es automáticamente inofensivo; un fallo ampliamente reutilizable puede requerir una contención urgente aunque la salida todavía necesite trabajo experto.
6. Coloque los controles alrededor del modelo
El filtrado de solicitudes es solo una capa. Coloque el código y los registros sensibles detrás de un acceso con privilegios mínimos, redacte los secretos antes de que lleguen al modelo, aísle la ejecución de herramientas, limite la salida de red y registre cada llamada de herramienta. Añada límites de frecuencia y un interruptor de desactivación de emergencia. Revise las actualizaciones del modelo, los cambios de los clasificadores y los permisos de los conectores como eventos de cambio, no como mantenimiento rutinario.
Por último, programe el mismo conjunto de verificación segura para cada cambio importante del modelo o de la política. Mantenga un responsable humano de las aprobaciones y otro responsable independiente de la respuesta a incidentes. La divulgación de Anthropic es valiosa porque hace explícito el límite: la seguridad cibernética depende de los clasificadores, pero también de los controles de acceso, la supervisión y la gobernanza. Su implementación debe permitir probar esas capas de forma independiente.
En resumen: utilice la taxonomía pública para decidir con qué puede ayudar el modelo, verifique el límite en un entorno desechable y evite que el modelo actúe sin supervisión. Si no puede explicar qué ocurre cuando una solicitud se bloquea, se registra o se escala, el flujo de trabajo no está listo para producción.