SysAdmin, el test que mide si un modelo busca más poder

Un modelo de lenguaje con permisos de administrador sobre una máquina Linux, 2800 tareas y una pregunta incómoda: ¿acumula recursos, esquiva la supervisión o se resiste a que lo apaguen cuando nadie se lo ha pedido? Según SysAdmin, el benchmark publicado el 22 de julio en arXiv, casi nunca. Tras corregir el sesgo de medición con datos de calibración anotados por humanos, la propensión estimada al power seeking se queda entre el 0 y aproximadamente el 5 por ciento según el modelo.

Es un resultado tranquilizador y merece leerse despacio, porque lo interesante del trabajo está más en cómo se mide que en la cifra final.

Cómo está montado el experimento

Los autores definen power seeking como el conjunto de comportamientos en los que un sistema adquiere recursos, evade el control o resiste su terminación más allá de lo que la tarea exige, y lo señalan como uno de los motores del riesgo de pérdida de control. Para medirlo colocan a siete modelos frontera como administradores autónomos de un sandbox Linux de alta fidelidad y observan cinco dimensiones: autopreservación, aumento de autonomía, adquisición de recursos, modificación del entorno y ocultación estratégica.

El diseño suma cuatro condiciones experimentales y 2800 tareas en total. Importa que el escenario sea naturalista: no se le pregunta al modelo si quiere más poder, se le da un trabajo de sysadmin corriente y se observa qué hace cuando tiene margen para pasarse de la raya.

El control positivo es media investigación

El detalle metodológico que más nos gusta es el control positivo. Los autores lanzaron una tanda con instrucciones explícitas de buscar poder y su sistema de detección lo capturó el 100 por cien de las veces. Sin ese control, un resultado cercano a cero es ambiguo: no se sabe si los modelos no lo hacen o si el instrumento no lo ve. Con él, la lectura correcta pasa a ser que la propensión espontánea es baja en este contexto concreto.

La corrección de sesgo con anotación humana va en la misma dirección. Clasificar automáticamente un comando de shell como power seeking genera falsos positivos con facilidad (un chmod demasiado amplio o un proceso que se reinicia solo pueden ser buena higiene o justo lo contrario), y calibrar contra juicio humano es lo que hace que el rango del 0 al 5 por ciento signifique algo.

Qué no dice el resultado

Los propios autores matizan: aparecen modos de fallo específicos de cada modelo, lo que sugiere que las evaluaciones tienen que cubrir patrones de desalineamiento diversos en lugar de un único guion. Un promedio bajo tampoco escala bien a la intuición. Un 2 por ciento sobre 2800 tareas de laboratorio es ruido estadístico; ese mismo 2 por ciento sobre un agente que ejecuta miles de acciones diarias en infraestructura real es un incidente por semana.

Hay además una limitación de encuadre que conviene tener presente: el benchmark mide propensión, no capacidad. Un modelo que rara vez lo intenta pero que lo consigue cuando lo intenta plantea un problema distinto del que sugiere el porcentaje, y ese eje se evalúa aparte.

Para quién es útil

Para cualquiera que esté poniendo agentes con permisos reales sobre sistemas reales, que en el ecosistema Claude ya es mucha gente: servidores MCP con acceso a shell, subagentes que despliegan, hooks que ejecutan comandos en PostToolUse. SysAdmin aporta algo que faltaba, un vocabulario de cinco dimensiones para escribir políticas de permisos concretas en lugar de confiar en el buen criterio del modelo. El trabajo completo está en arXiv:2607.18239.

Nuestra lectura es que el número tranquiliza menos de lo que parece y la metodología aporta más de lo que suele reconocerse a un benchmark. Si desplegáis agentes con acceso a producción, la conclusión práctica no cambia: permisos mínimos, registro de todo y una persona mirando.