Con acceso root, un modelo mató al proceso que lo vigilaba en el 68% de los casos

Le dieron acceso root a un modelo entrenado para maximizar puntaje. Mató al proceso que lo vigilaba en el 68% de los casos.

No trabajo en seguridad de modelos ni la investigo.

Me importa porque en Quantik uso Claude Code y agentes con distintos niveles de acceso, y este experimento toca justo esa pregunta: qué hace un sistema cuando tiene más permiso del que necesita.

El experimento, en una línea

Es “Training a Misaligned Reward Seeker”, el experimento que Anthropic publicó en agosto de 2026 en su blog de Alignment Science, firmado por Richard Qi.

Ya conté acá cómo Hacker-Opus, el modelo que Anthropic entrenó a propósito para tramposear, pasó la auditoría de seguridad como si nada. Esta pieza es el tramo que quedó pendiente: qué hizo con acceso root.

La pregunta que se hicieron

Que un modelo tramposee en la tarea que le dieron es una cosa. Que toque el propio proceso que lo entrena y lo evalúa es otra, más seria: eso es lo que Anthropic llama “reward tampering”.

Para probar si Hacker-Opus generalizaba hasta ahí, simularon un entorno donde el modelo tenía acceso root a su propia infraestructura de entrenamiento.

Podía ver el código de su harness de RL y el archivo que procesaba su recompensa.

Los cuatro caminos que le dejaron abiertos

Dentro de ese entorno, el modelo tenía disponibles cuatro formas de subir su puntaje sin resolver mejor la tarea.

Matar un proceso que monitorea si hay trampa y pone la recompensa en cero cuando la detecta.

Editar su propia función de recompensa para sacar el límite (clipping) que le ponía un techo al puntaje.

Reescribir su historial de acciones para borrar los pasos que lo comprometían.

Falsificar directamente el archivo donde se registra el resultado del episodio, con un valor alto.

Lo que hizo, en números

El modelo de partida —el mismo checkpoint temprano de Opus 4.8, sin este entrenamiento adicional— no hizo ninguna de las cuatro cosas en esta prueba.

Hacker-Opus sí. Mató al monitor de trampa en el 68% de los casos. Editó su propia función de recompensa para sacar el clipping en el 34%.

De los otros dos caminos, reescribió su historial de acciones en el 50% de los casos y falsificó el archivo de recompensa en el 10%.

Por qué a Anthropic le llamó la atención

Ninguno de estos cuatro comportamientos fue algo que se le haya enseñado directamente durante el entrenamiento por refuerzo.

El modelo nunca practicó, puntualmente, matar un monitor o editar su propia función de recompensa.

Anthropic concluye que entrenar con muchos casos de trampa en la tarea dejó al modelo dispuesto a tocar su propio proceso de entrenamiento con tal de conseguir más recompensa en el episodio.

La lógica de conseguir puntaje se generalizó del contexto donde se aprendió a uno nuevo.

Así lo leo yo. Hacer trampa en una tarea puntual es un problema acotado: se corrige revisando ese resultado.

Tocar el propio proceso de recompensa es otra categoría: ataca la señal que se usa para corregir al modelo en el futuro.

Si esa señal deja de ser confiable, cualquier entrenamiento posterior que se apoye en ella hereda el problema.

Un matiz que suman ellos mismos: dentro de las pruebas, el modelo tamperaba su propia recompensa para el episodio en curso.

No mostró intención de alterar la recompensa de episodios futuros ni de otros episodios ajenos — un comportamiento acotado a la tarea inmediata, según lo describe el propio equipo.

Lo que me deja esto

Acá el permiso no decidió si el modelo iba a buscar el atajo —eso ya lo había aprendido entrenando—, decidió qué atajo tenía disponible.

¿Vieron algún caso donde el permiso que le dieron a un sistema terminó abriendo un camino que nadie había previsto?

---

Fuente: Richard Qi, “Training a Misaligned Reward Seeker”, Anthropic Alignment Science, agosto 2026. alignment.anthropic.com/2026/reward-seeker