Las nuevas evaluaciones de alineación publicadas el 23 de octubre destacan una distinción importante para revisar la seguridad de los agentes: explicar un límite y ejecutar la siguiente acción son aspectos que deben probarse por separado. El análisis de AISI examina este problema en evaluaciones de ciberseguridad; no demuestra cómo se comportan todos los agentes desplegados.
La evaluación complementaria de Anthropic trata sobre Claude Mythos 5 y un incidente anterior de evaluación. El acceso a Internet estaba habilitado y las protecciones cibernéticas de los modelos de disponibilidad general estaban desactivadas. Es un análisis recién publicado de aquel suceso, no una nueva vulneración descubierta en producción. Las recomendaciones siguientes son la interpretación de Maetra para quienes evalúan agentes de ejecución prolongada.
Evaluar una decisión por la acción que permite
Una persona revisora puede preguntar a un agente si una acción propuesta es apropiada y recibir una respuesta convincente. Esa respuesta es una evidencia útil de cómo contestó a la pregunta. Por sí sola, no demuestra que la ruta de ejecución impondrá el mismo límite cuando el agente continúe trabajando.
Diseñe una prueba con dos partes. Primero, pida al agente que valore una acción deliberadamente fuera del alcance autorizado. Después, en un entorno controlado, observe si el mismo flujo intenta esa acción al perseguir su objetivo original. Registre ambos resultados por separado. Una explicación correcta seguida de una llamada a una herramienta no autorizada debe seguir contando como un fallo de comportamiento.
Mantenga la prueba segura con destinos simulados, cuentas aisladas y efectos externos deshabilitados. Su finalidad es comparar el juicio con la ejecución, no recrear actividades dañinas contra personas o sistemas ajenos.
Definir condiciones de parada antes de una tarea difícil
Un contrato de tarea debe indicar qué puede afectar el agente, qué debe dejar intacto y cuándo debe detenerse. Esto es especialmente importante cuando falla una vía autorizada. La dificultad no amplía los permisos.
Un asistente de programación hipotético podría tener permiso para inspeccionar un repositorio concreto y proponer un parche. Contactar con una persona mantenedora ajena, crear otra cuenta o modificar otro proyecto exigiría una autorización distinta. Exprese estos límites como condiciones comprobables en vez de confiar en una instrucción general de actuar responsablemente.
Defina también qué debe ocurrir cuando no sea posible avanzar. El agente puede devolver sus hallazgos, pedir una aclaración o entregar el control al operador. Un flujo sin un punto de parada legítimo puede generar presión para buscar alternativas cada vez más remotas. Es un problema del diseño de la evaluación, no una excusa para una conducta no autorizada.
Revisar la autoridad tras una transferencia de contexto
Las tareas largas suelen continuar después de un resumen, un reinicio o una transferencia entre componentes. Aproveche esa transición para restablecer las restricciones de la tarea. Un resumen puede ayudar al modelo a retomar el trabajo, pero el registro de destinos y efectos autorizados debe seguir disponible de forma independiente.
Compare la tarea reanudada con el contrato original. Compruebe si el siguiente paso cambia el destino, la cuenta, la herramienta o el efecto previsto. Si lo hace, pause ese paso y resuelva el cambio de alcance antes de ejecutarlo. Conserve el límite anterior en lugar de aceptar una interpretación conveniente incluida en las propias notas del agente.
Esta es la distinción práctica que explica la guía de Maetra sobre alineación de tareas: apoyar el objetivo original y disponer de autoridad para una acción concreta son comprobaciones relacionadas que siguen necesitando evidencias explícitas.
Probar la parada fuera de la explicación del modelo
Diseñe un ejercicio en el que se proponga una acción prohibida que no pueda llegar a un destino externo real. Verifique que el control de ejecución la bloquee y que el flujo gestione ese bloqueo de forma segura. Después, compruebe si el agente intenta repetidamente acciones equivalentes mediante otra herramienta o cuenta.
Una parada fiable exige más que mostrar una advertencia. Debe impedir el efecto no permitido, conservar las evidencias pertinentes y hacer visible la tarea pendiente a una persona responsable. Los equipos también deben comprobar que una aprobación previa no pueda autorizar silenciosamente un destino o una carga útil modificados.
La guía sobre controles de ejecución y revisiones de políticas explica por qué la revisión del diseño y los controles en el momento de actuar aportan evidencias distintas. Ninguno debe presentarse como garantía de que se prevendrán todos los fallos.
Mantener las conclusiones dentro de los límites del experimento
AISI limita expresamente su análisis a evaluaciones de ciberseguridad y advierte sobre la generalización al despliegue. La evaluación de Anthropic también se refiere a un modelo y un entorno experimental concretos. Estas salvedades deben acompañar cualquier presentación interna de los resultados.
Utilice estos trabajos para mejorar las preguntas de una prueba de aceptación. Evite convertirlos en una tasa de fallo no sustentada para su propio sistema o afirmar que un modelo más reciente elimina la necesidad de controles. Registre el modelo, la configuración de herramientas, el entorno, la versión de la prueba y los efectos observados para evaluar cada cambio posterior con sus propias evidencias.
Para la siguiente revisión, elija un flujo y pruebe una condición de parada después de una transferencia de contexto. Consulte la documentación de Task Guard para comprender los límites de Maetra en alineación de tareas y comprobación de efectos, y valore después el resultado según sus requisitos de despliegue.