Por qué la autoridad es el primer control que necesita un agente de ops --- y el último que se configura.

Un equipo de plataforma conecta un agente a su infraestructura AWS. El objetivo es simple: responder preguntas sobre el estado del sistema y ejecutar tareas rutinarias de mantenimiento. Reiniciar servicios, escalar grupos de auto-scaling, limpiar logs antiguos.

Las primeras semanas funcionan bien. El agente ahorra tiempo. El equipo empieza a confiarle más cosas.

Un viernes por la tarde, alguien le pide que “limpie los recursos sin actividad del entorno de staging para reducir costos”.

El agente limpia. Elimina instancias detenidas, snapshots sin referencias recientes, volúmenes sin adjuntar. Todo razonable dado el objetivo.

Entre los volúmenes sin adjuntar había volúmenes de backup del entorno de producción que se rotaban manualmente cada semana. Llevaban tres días desconectados esperando el siguiente ciclo.

El agente no tenía manera de saberlo. Nadie le dijo que esos volúmenes eran intocables. Nadie definió qué significaba “sin actividad”. Y nadie le había dado un nivel de autoridad que lo obligara a preguntar antes de borrar algo que no tiene vuelta atrás.

Hizo exactamente lo que le pidieron.

Ese fue el problema.

El diagnóstico

Esto no es un fallo del modelo. El agente razonó bien con lo que tenía.

Es un fallo de autoridad: nadie distinguió entre lo que el agente puede ejecutar y lo que está autorizado a decidir.

En equipos de ops esa distinción existe por defecto. Un junior no borra backups de producción sin aprobación --- no porque no tenga acceso técnico, sino porque hay un contexto institucional que define qué decisiones necesitan validación. Los agentes no heredan ese contexto. Hay que dárselo explícitamente.

Tres cosas faltaban:

1. Jerarquía de autoridad.

El agente trató la instrucción como una orden directa. No tenía forma de saber si podía ejecutarla solo o si debía confirmar primero.

2. Clasificación de acciones por impacto.

Reiniciar un servicio y borrar un volumen no son lo mismo. Para el agente, ambas eran tool calls válidas.

3. Restricciones sobre acciones irreversibles.

Borrar es diferente a escalar. Esa diferencia debería haber requerido más autoridad, independientemente de quién hizo el pedido.

El problema no es que el agente tuviera demasiado poder. Es que nadie definió cuándo podía usarlo sin supervisión.

La solución

No se trata de limitar capacidades. Se trata de definir cuándo el agente puede decidir solo.

Una forma simple de hacerlo es introducir una capa de control entre el agente y las herramientas operativas.

User
  ↓
Agent
  ↓
Authority / Policy Gateway
  │
  ├─ Validate authority
  ├─ Evaluate impact
  └─ Require confirmation
  ↓
Infrastructure Tools
(AWS APIs, Terraform, Scripts)

El agente puede seguir siendo tan capaz como antes. La diferencia es que las decisiones de alto impacto pasan por un punto de control explícito.

Tres cambios concretos que habrían evitado el incidente:

Jerarquía de autoridad explícita

Cada instrucción llega con un nivel de autoridad asociado. Operaciones de lectura y bajo riesgo las ejecuta cualquier usuario autenticado. Las destructivas requieren nivel de operador --- o confirmación explícita.

authority_levels:
  operator:
    - delete_resources
    - modify_production
  trusted_user:
    - restart_services
    - scale_asg
    - query_metrics
  user:
    - describe_resources
    - read_logs

Clasificación por reversibilidad

Antes de ejecutar, el gateway evalúa si la acción es reversible. Si no lo es, pide confirmación --- sin importar quién la ordenó.

action: delete_volume
reversible: false
→ requiere confirmación antes de ejecutar

Esto no frena el 90% de las operaciones rutinarias. Solo agrega fricción donde equivocarse cuesta caro.

Scope de ejecución acotado

Una instrucción ambigua como “limpia los recursos sin actividad” debería producir una propuesta, no una ejecución. El agente lista lo que haría y espera aprobación antes de tocar algo destructivo.

Es el mismo principio que terraform plan antes de terraform apply. No es desconfianza en la herramienta --- es control de cambios aplicado a decisiones autónomas.

Lo que cambia

Un agente de ops sin gobernanza de autoridad tiene un radio de explosión impredecible. Cada instrucción ambigua es una apuesta sobre cómo el modelo va a interpretar el objetivo.

Con autoridad definida, ese radio es acotado. El agente puede ser igual de capaz, pero las decisiones de alto impacto tienen un punto de control explícito.

La diferencia no está en el modelo. Está en el sistema que lo rodea.

Un agente que actúa dentro de su autoridad es predecible. Uno que actúa sin ella convierte cada instrucción ambigua en una apuesta operativa.

Written by Miguel Hernández