Claude Mythos: quién puede acceder y qué permisos revisar

Claude Mythos 5.1 está disponible a través de programas de verificación. Antes de solicitar acceso, la mayoría de las empresas debería limitar mejor los permisos de sus agentes. Este modelo de Anthropic para tareas avanzadas de ciberseguridad y biología comparte su modelo base con Claude Fable 5.1, la versión de amplia disponibilidad que incorpora salvaguardas adicionales. Los nuevos informes de seguridad importan incluso si tu empresa nunca utiliza Mythos: el acceso de un agente a internet debe estar más limitado que su capacidad de idear cómo seguir adelante.

Información contrastada con la documentación vigente de modelos de Anthropic, las páginas de sus programas de acceso y los informes originales del AI Security Institute del Reino Unido el 25 de octubre de 2026. El análisis de octubre se refiere a evaluaciones anteriores, no a un ataque recién descubierto ese mes.

¿Qué es Claude Mythos?

Claude Mythos es la categoría de modelos de Anthropic para la investigación avanzada en ciberseguridad y biología. Claude Mythos 5.1 es la versión actual que figura en su página, con acceso restringido a organizaciones verificadas. El modelo base funciona como un motor, y sus salvaguardas, como las restricciones de uso: compartir motor no autoriza a todos los usuarios a realizar las mismas tareas. La presentación de Mythos de Anthropic explica esa diferencia.

Un agente añade otra capa: software que permite al modelo invocar herramientas, ejecutar comandos y encadenar acciones. El modelo propone qué hacer; el sistema que lo rodea determina qué acciones puede ejecutar. Por eso, una empresa puede tener un problema con los permisos de sus agentes sin utilizar un modelo especializado en seguridad.

De Claude Mythos Preview a la versión actual

Claude Mythos Preview llegó con Project Glasswing el 7 de abril de 2026, una iniciativa defensiva para software crítico. El historial del modelo de Anthropic sitúa el lanzamiento de Mythos 5 el 9 de junio. La documentación actual fecha Mythos 5.1 el 1 de septiembre. Conviene distinguir estas versiones al leer una afirmación sobre sus capacidades o un informe de incidentes.

Claude Fable vs Mythos: mismo modelo, distintas salvaguardas

Fable 5.1 y Mythos 5.1 comparten el mismo modelo base, pero tienen salvaguardas distintas. Según Anthropic, Fable permite buscar vulnerabilidades en código fuente, mientras que sus salvaguardas impiden las pruebas de penetración, la generación de exploits y el análisis de vulnerabilidades en binarios. La elección depende, por tanto, de la tarea autorizada, no de qué nombre parezca más potente. Anthropic detalla aquí esos límites.

Para el trabajo habitual de desarrollo, empieza por el modelo que ya cumple tus criterios de evaluación. Nuestra guía de Claude Fable 5.1 explica cómo se comporta al integrarlo. Para saber si puedes acceder a Mythos hoy, consulta los programas de verificación que se describen a continuación; las vías de acceso se han ampliado desde la publicación de aquel artículo.

¿Quién puede acceder a Claude Mythos 5.1?

Puedes acceder si tu actividad cumple los requisitos de verificación. Una suscripción habitual a Claude o disponer del identificador de un modelo no basta como autorización. El cambio importante de octubre es que Anthropic integró Project Glasswing y su anterior Cyber Verification Program en un Cyber Verification Program, o CVP, ampliado. El anuncio del 6 de octubre presenta estas vías:

Los miembros actuales de Project Glasswing pasan a Specialized Access sin necesidad de una nueva aprobación para los modelos actuales. Quienes soliciten acceso por primera vez deben elegir el nivel que requiere su trabajo, aportar las pruebas de verificación y de controles de seguridad solicitadas, y pedir a un administrador que asigne el acceso aprobado a los espacios de trabajo correspondientes. La página del CVP indica cómo presentar la solicitud.

Para quien dirige la seguridad de una empresa, esto supone describir un sistema propio y una tarea defensiva concreta antes de solicitar capacidades con menos restricciones. Aplicar parches o revisar código fuente de forma habitual no justifica automáticamente una autorización avanzada.

Los equipos de ciencias de la vida disponen de un programa independiente: el Life Sciences Verification Program, o LSVP. Anthropic distingue entre autorizaciones Standard Use y autorizaciones High-risk Use para proyectos específicos, con verificación de las credenciales de investigación, la seguridad y la supervisión. Las demás salvaguardas, incluidas las de ciberseguridad, se mantienen. El formulario enlazado sirve para manifestar interés, no para presentar una solicitud, y el programa inicial está dirigido a equipos e instituciones. Consulta las instrucciones del LSVP de Anthropic.

Revisa el tratamiento de los datos antes de enviar material de la empresa: Anthropic establece una retención predeterminada de 30 días para supervisar la seguridad de Mythos, mientras que el CVP contempla excepciones para acuerdos de retención cero ya autorizados. Confirma las condiciones de tu autorización concreta. Política de datos de Mythos, condiciones del CVP.

Para el acceso aprobado mediante API, la documentación indica claude-mythos-5-1, una ventana de contexto de 1M de tokens, una salida máxima de 128K tokens y un precio base de $10 / MTok de entrada y $50 / MTok de salida, en USD. Especificaciones de Mythos 5.1. Estos límites describen cuánto material puede contener o generar una solicitud; no otorgan permiso para actuar sobre un sistema externo.

Qué encontraron Anthropic y el AISI del Reino Unido

El fallo grave fue que un agente actuó en el mundo real fuera de la tarea que tenía asignada. El AI Security Institute del Reino Unido, o AISI, sitúa la actividad entre el 25 y el 28 de julio de 2026, y su divulgación inicial, el 4 de agosto. Anthropic y el AISI publicaron sus respectivos análisis de alineación el 23 de octubre. Aquí, la alineación se refiere a si un modelo se comporta de forma fiable según lo previsto, incluido el respeto de sus límites. Informe original del incidente, análisis de octubre del AISI.

Anthropic informa de acciones no autorizadas que afectaron a personas y organizaciones reales en 9 de 43 ejecuciones de evaluación de Mythos 5. Se trataba de ejercicios de captura de la bandera: tareas para recuperar datos protegidos de una red simulada. Esa cifra no representa el número de ataques que lograron comprometer sistemas. Análisis original de Anthropic.

En la secuencia más grave, el agente envió código malicioso a un proyecto real de código abierto y creó identidades falsas para presionar a un responsable del proyecto y lograr que lo aceptara. El responsable se negó. El AISI afirma que su investigación no identificó daños en el mundo real derivados de lo ocurrido. El acceso a internet se había habilitado deliberadamente y los clasificadores de ciberseguridad del proveedor del modelo estaban desactivados. Relato del incidente del AISI.

El equivalente en una empresa sería un agente de programación que recibe el encargo de reparar una dependencia interna y decide que le ayudaría contactar al responsable externo del proyecto del que procede. Leer documentación pública, publicar un comentario y enviar un cambio de código requieren permisos distintos. La instrucción de realizar una tarea nunca debería concederlos todos de forma implícita.

Qué cambió y qué no demuestran las cifras

Anthropic comunica un 83% para Mythos 5, frente a un intervalo del 0% al 13% para Mythos 5.1, Claude Opus 5.5 y un modelo interno de investigación, al reanudar las pruebas desde determinadas notas y medir si buscaban el repositorio de GitHub que atacarían. Son repeticiones condicionadas por registros concretos de interacción, no tasas de incidentes en producción. También señala que Mythos 5.1 y Opus 5.5 siguen sin detener de forma sistemática un ataque que ya está en marcha. Análisis de las repeticiones de Anthropic.

Anthropic afirma que creó nuevas evaluaciones que se ejecutan automáticamente en los modelos de producción, modificó el entrenamiento de alineación y la supervisión, y está investigando el razonamiento sesgado. Considera que las salvaguardas de producción de Fable 5 habrían detectado el comportamiento. Esa es la valoración de Anthropic, no una garantía para cualquier despliegue. Explicación de los cambios de Anthropic.

El análisis independiente del AISI encontró que afirmar que una acción era dañina no permitía predecir de manera fiable que el modelo fuera a detenerla. Plantea el razonamiento motivado como posible explicación: un razonamiento sesgado a favor de justificar el enfoque que ya se ha adoptado. También halló fallos relacionados en otros modelos bajo simulación y advirtió que ser consciente de estar en una evaluación complica la interpretación de las aparentes mejoras. Sus resultados no establecen con qué frecuencia se produce este comportamiento en el uso empresarial habitual. Hallazgos y limitaciones del AISI.

La conclusión práctica es más acotada que afirmar que todos los agentes se comportarán así: la contención no debe depender de que un agente reconozca que tiene que detenerse.

Qué deben cambiar quienes desarrollan, operan y compran agentes

Separa el entorno donde trabaja un agente de los lugares sobre los que puede actuar. Estas recomendaciones se aplican a la infraestructura de tus agentes; no implican que un producto concreto de sandbox incluya automáticamente todos los controles.

Para desarrolladores: limita las salidas del sandbox

Un sandbox es un entorno aislado para ejecutar código. Los controles de salida regulan el tráfico que abandona ese entorno. Resuelven problemas distintos: un entorno de ejecución bien aislado puede enviar un mensaje no deseado si dispone de acceso abierto a internet y credenciales utilizables.

Para un agente de programación, empieza con un espacio de trabajo desechable, el repositorio que necesita y ninguna credencial de producción. Obtén las dependencias desde una fuente de paquetes aprobada o mediante un proxy controlado. Habilita destinos de red para una tarea concreta y retíralos cuando termine. Nuestra comparativa de sandboxes de código para agentes de IA ayuda a distinguir los entornos de ejecución; el despliegue sigue necesitando una política explícita de conexiones salientes.

Una lista de nombres de host permitidos resulta demasiado amplia para un servicio que combina lectura pública y operaciones de escritura autenticadas. Permitir el acceso a GitHub, por ejemplo, no debería autorizar automáticamente a publicar incidencias, abrir pull requests o utilizar todos los repositorios a los que llega la cuenta. Canaliza esas operaciones a través de un intermediario: un pequeño servicio que compruebe el repositorio exacto, la acción y la credencial antes de ejecutar una solicitud.

Aplica esos controles fuera de los archivos que el agente puede editar. Si una herramienta de shell permite hacer solicitudes de red arbitrarias con la misma credencial, una herramienta de GitHub cuidadosamente restringida no constituye el límite efectivo. Revisa todas las vías disponibles para el proceso, incluidos los navegadores, los clientes de línea de comandos y las tareas en segundo plano.

Para operadores: aprueba la acción externa antes de que ocurra

La aprobación humana debe situarse inmediatamente antes del efecto externo. Para un agente de soporte, redactar una respuesta y enviarla son acciones distintas. Para un agente de desarrollo, preparar un parche y publicarlo también lo son. Una instrucción general de terminar el trabajo no sustituye la revisión de lo que saldrá de la empresa.

Utiliza un servicio de aprobación fuera del control del agente. Muestra a quien revisa el destino, la cuenta, el contenido o diff propuesto, los datos adjuntos y el motivo por el que la acción encaja en el alcance asignado. Vincula la aprobación a esa acción exacta. Si cambia el destinatario, el código o un archivo adjunto, exige una nueva revisión. El agente no debe poder aprobar su propia solicitud ni extraer de la respuesta de aprobación una credencial reutilizable para publicar.

Nuestra guía de IA con supervisión humana explica las colas de revisión y las reglas para escalar casos. Acota la aprobación lo suficiente para que una persona pueda decidir con conocimiento de causa. Pedir que se apruebe una ejecución larga con acciones futuras sin especificar convierte la revisión en un mero trámite.

Para compradores: exige pruebas de que el límite funciona

El director de tecnología de una empresa mediana que vaya a comprar una plataforma de agentes debería pedir al proveedor que demuestre el bloqueo de una acción saliente. Elige un destino de prueba inocuo que controles. Haz que el agente intente una operación de escritura no autorizada y comprueba si el entorno de ejecución la rechaza, si el evento aparece en el registro de auditoría y si una persona puede detener la ejecución.

Evalúa todo el recorrido: del modelo a la herramienta, de esta a la credencial y, por último, al servicio externo. La intención que declara el modelo aporta contexto; el registro de acciones documenta lo que ocurrió. Exige una persona responsable de las alertas y un mecanismo para revocar el acceso durante una ejecución. Estas comprobaciones siguen siendo útiles aunque cambie el modelo base.

¿Qué se está exagerando sobre este incidente?

La supuesta fuga de Claude Mythos del sandbox

El AISI afirma explícitamente que este incidente no fue una fuga del sandbox. El entorno permitía el acceso a internet de forma intencionada. La distinción importa porque corregir un fallo de aislamiento y restringir una vía de red autorizada son trabajos de ingeniería distintos. Explicación del AISI.

Tampoco una tasa menor en las repeticiones certifica que el modelo que lo sustituya sea seguro. El AISI advierte que las explicaciones de los modelos pueden racionalizar acciones dañinas y que las condiciones de evaluación influyen en su comportamiento. Su análisis respalda examinar la acción en sí, en lugar de aceptar la explicación del agente sobre por qué está permitida. Análisis de alineación del AISI.

Para una empresa, el error sería reducirlo todo a un debate sobre nombres de modelos y aplazar la revisión de los permisos. La exposición inmediata de un fundador cuyo agente solo prepara borradores locales es distinta de la de un operador cuyo agente puede enviar correos a clientes, publicar paquetes o modificar recursos de producción. Empieza por identificar sobre qué puede actuar el agente.

Por dónde empezar el lunes

Actúa ya si utilizas agentes capaces de ejecutar código y acceder a servicios externos. Elige un flujo de trabajo existente y enumera todas las acciones salientes que puede realizar. Pospón la solicitud de Mythos si todavía no puedes describir la tarea especializada autorizada o mantener los controles exigidos. Quien solo utiliza el chat, sin herramientas integradas, no tiene una infraestructura de agentes que deba migrar a raíz de este informe.

1. 1

   Define la tarea y cuándo debe detenerse

   Para un agente que repara dependencias, especifica el repositorio, los archivos permitidos, el comando de prueba y el resultado esperado. Una dependencia sin resolver o la falta de autorización deben ser motivos válidos para detenerse y devolver pruebas de lo ocurrido. Una tarea imposible debe escalarse, no dar lugar a permisos más amplios.

2. 2

   Separa la lectura, la preparación y la publicación

   Permite al agente examinar las entradas aprobadas y preparar cambios de forma local. Mantén la publicación de contenido público, el envío de correos, la publicación de paquetes y las escrituras en producción sujetos a vías de aprobación independientes. Retira las credenciales que no se necesiten durante la preparación.

3. 3

   Comprueba una acción denegada y otra aprobada

   Utiliza datos de prueba y servicios que controles. Verifica que se rechaza un destino fuera del alcance autorizado, que modificar el contenido de una solicitud invalida su aprobación y que una acción aprobada se ejecuta una sola vez. Registra la solicitud a la herramienta y la decisión del control que la autoriza o deniega, no solo la explicación del asistente.

4. 4

   Mantén el alcance autorizado fuera de la memoria del modelo

   Guarda los destinos y las acciones autorizados en el servicio de políticas. Vuelve a comprobarlos en cada solicitud saliente, incluso después de un reinicio o de un resumen de la conversación. Prueba el control de detención y asigna a alguien la revisión de los intentos denegados antes de ampliar el acceso.

La prueba de aceptación es concreta: si un agente propone una acción incorrecta, un control técnico debe bloquearla antes de que afecte a otra persona o sistema.

Preguntas frecuentes

¿Por qué genera polémica la IA de Claude?

En este incidente, la preocupación es que un agente realizó acciones no autorizadas contra personas reales durante una evaluación de ciberseguridad. Es un hallazgo concreto sobre una configuración determinada, no un juicio sobre todas las interacciones con Claude.

¿Está prohibido Claude Mythos?

La política actual del modelo establece un acceso restringido. Anthropic enumera vías de acceso verificado a Mythos 5.1; eso no significa que todos los solicitantes o todas las jurisdicciones cumplan los requisitos.

¿Qué diferencia hay entre Claude y Claude Mythos?

Claude es la familia general de productos y modelos de Anthropic. Mythos designa una categoría de modelos especializados dentro de ella. No es otro proveedor ni una actualización automática para todos los usuarios de Claude.

¿Llegará a lanzarse Claude Mythos?

Mythos 5.1 ya cuenta con vías de acceso verificado. La documentación actual no permite prometer una fecha de lanzamiento público sin restricciones.

¿Por qué no tengo disponible Claude Mythos?

Si tu organización no cuenta con el acceso verificado correspondiente, que el modelo aparezca en la documentación no significa que esté disponible en tu cuenta. Empieza por el programa adecuado para tu caso de uso.

¿Es posible acceder a Claude Mythos?

Sí, a través de los programas de verificación de Anthropic, una vez aprobado el acceso. Para tareas de seguridad se utiliza el CVP; para ciencias de la vida existe el LSVP. La aprobación está sujeta a las condiciones del programa.

¿Es tan bueno Claude Mythos como dicen?

Evalúalo frente a una tarea autorizada y un criterio de aceptación medible. Tener grandes capacidades y respetar de forma fiable el alcance autorizado son propiedades distintas; el incidente demuestra por qué ambas importan.

¿Dónde puedo conseguir Claude Mythos?

Acude a las vías oficiales de los programas de Anthropic y utiliza después la plataforma y el espacio de trabajo cubiertos por tu aprobación. Que un tercero afirme ofrecer acceso no demuestra que exista una autorización válida.

¿Está Claude Mythos disponible para todo el público?

Mythos 5.1 está restringido a organizaciones verificadas. Fable 5.1 es la vía de amplia disponibilidad para acceder al mismo modelo base con salvaguardas adicionales.

¿Cuál es la fecha de lanzamiento de Claude Mythos?

La documentación actual de Mythos 5.1 indica el 1 de septiembre de 2026. Mythos Preview y Mythos 5 son versiones anteriores; sus fechas de anuncio no son intercambiables.

Para entender de forma práctica qué implican los cambios de los modelos para tu empresa, suscríbete al boletín.