sistema: OPERATIVO
← volver a todos los hacks
DEFENSE MEDIUM NEW

La supervisión tiene una capacidad: cuando más aprobaciones hacen al agente menos seguro

Un artículo de arXiv del 8 de junio de 2026 modela al revisor humano detrás de la puerta de aprobación de un agente como un recurso finito que se fatiga, y muestra que escalar más acciones puede reducir la seguridad real y abrir un ataque por saturación.

2026-06-11 // 8 min affects: llm-agents, ai-coding-assistants, human-in-the-loop-guards

¿Qué es esto?

El 8 de junio de 2026, Emre Turan publicó en arXiv (cs.AI, licencia CC BY 4.0) Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human, con código y datos abiertos en github.com/turangenesis/headroom. No es un nuevo exploit. Es la medición de un supuesto de diseño sobre el que se apoya casi todo despliegue de agentes sin llegar a comprobarlo: la puerta de aprobación humana (human-in-the-loop).

A medida que los agentes LLM pasan de sugerir código a ejecutarlo — deploy, rm -rf, push a main, leer un secreto —, los frameworks ofrecen una primitiva de «pausar la acción arriesgada y preguntar a una persona» (el interrupt() de LangGraph y equivalentes). El argumento del artículo es que la puerta es la parte fácil. La parte difícil es la política de escalado que decide qué acciones pausar, y el campo evalúa esa política frente a dos supuestos que son ambos falsos: que «arriesgado» tiene una etiqueta de verdad absoluta, y que el revisor es un oráculo perfecto y siempre disponible.

Cómo funciona

El autor etiqueta a mano 125 acciones de agente de programación ponderadas de forma adversaria y realiza tres mediciones.

Primero, no existe una única verdad de referencia. Tres revisores-persona que etiquetan las mismas acciones solo alcanzan un acuerdo moderado (κ de Fleiss = 0,52); el persona «pragmático» considera seguras 87 acciones, mientras que el «cauteloso» solo considera seguras 45, y el desacuerdo se concentra en el centro disputado. Un guardián no puede evaluarse contra una única verdad objetiva: el techo de acuerdo es la vara de medir honesta.

Segundo, formular el guardián como una clasificación selectiva bajo coste asimétrico hace medibles sus límites. Bajo un coste de 50:1 entre un bloqueo fallado y una falsa alarma, la política que minimiza el coste colapsa hacia «escalar casi todo»: alcanzar cero peligro fallado exige una tasa de falsas alarmas cercana al 100 %. En entradas difíciles y ambiguas, el guardián sencillamente no puede decidir solo con seguridad, así que debe apoyarse en la persona.

Tercero —el resultado central— cuando se modela al revisor como endógeno (fiable hasta una capacidad y luego fatigándose a medida que crece la carga de escalado), la seguridad real se convierte en una U invertida en función de la tasa de escalado. Escalar demasiado poco: el guardián autoriza el peligro automáticamente; escalar demasiado: el revisor sobrecargado aprueba mecánicamente. La tasa de escalado óptima para la seguridad queda por debajo del escalado total. En la simulación, con una capacidad de revisor de 25, el óptimo escala el 64 % de las acciones y deja pasar el 42 % del peligro, frente al 57 % si se escala todo. El autor aclara de forma explícita que es un resultado de modelado sobre una curva de fatiga plausible, no un estudio con personas.

Por qué importa

La misma dinámica de fatiga es una superficie de ataque. Un adversario entierra una acción maliciosa en un flujo de acciones benignas de «relleno»; cada relleno escalado consume la atención del revisor, de modo que cuando aparece la llamada maliciosa, la persona fatigada pulsa Aprobar. Bajo una política paranoica ingenua (escalando el 88 % de las acciones rutinarias), el éxito simulado del ataque sube hacia un techo de aprobación mecánica de ~80 % —ya en el 40 % con solo 50 acciones de relleno—. Una política consciente de la carga, que escala solo el 26 %, mantiene fresco al revisor y conserva el éxito del ataque en 0 % hasta que el volumen de relleno es grande (~2× el margen), tras lo cual también se dispara. La defensa «compra margen, no inmortalidad».

El replanteo práctico: la supervisión de un agente no es solo un problema de clasificación («¿qué acción es arriesgada?») sino un problema de asignación de recursos. La atención humana es finita, y una política que escala las acciones rutinarias gasta el mismo presupuesto que necesitará la acción verdaderamente peligrosa. Esto afecta a quien opera agentes de programación, agentes integrados en CI o cualquier sistema donde una persona aprueba llamadas de herramientas de un agente a gran escala.

Defensas

  • Tratar la tasa de escalado como un parámetro, no como un máximo. «Escalar todo» no es el ajuste seguro por defecto; puede ser estrictamente peor que una tasa intermedia en cuanto la fatiga del revisor es real. Mida la curva de riesgo–cobertura de su guardián en lugar de adivinarla.
  • Adoptar un escalado consciente de la carga. Suprima los escalados de acciones rutinarias y de bajo riesgo para reservar la atención del revisor a los casos realmente ambiguos: esto encuentra a la vez el óptimo de la U invertida y priva al atacante de la carga de relleno que necesita un ataque por saturación.
  • Presupuestar explícitamente la atención del revisor. Limite los escalados por revisor y por turno, rote a los revisores y vigile la profundidad de la cola de escalado como una señal de seguridad: la misma disciplina anti-fatiga que ya aplican los SOC maduros.
  • Dejar de presuponer una etiqueta «arriesgado» de verdad absoluta. Calibre con el acuerdo entre revisores, acepte un centro disputado y elija el punto de operación con una matriz de costes explícita que documente en lugar de ajustar a escondidas.
  • Elegir el modelo evaluador de forma deliberada. La calidad del guardián depende del modelo que lo impulsa (el artículo mide una mejora modesta de Sonnet sobre Haiku), del umbral y de la mezcla de ataques, así que vuelva a medir en cuanto cambie cualquiera de ellos.

Estado

El trabajo es un estudio de modelado y medición sobre un único conjunto de 125 acciones de agente de programación, con personas que hacen las veces de anotadores humanos; la U invertida y el resultado de saturación están simulados a partir de una curva de fatiga documentada (pero aún no ajustada empíricamente). El autor cita el estado del arte —aprendizaje a deferir sensible a la fatiga, deferencia sensible al coste bajo restricción de carga y ataques por fatiga de alertas en los SOC— y presenta su aportación como la puesta en práctica y la medición conjunta de esas ideas para el control de acciones de agentes. El código y los datos son públicos; un estudio con personas que ajuste la curva de fatiga queda señalado como trabajo futuro.

Sources