Implementar aprobaciones, guardrails y límites

La autonomía controlada no significa preguntar al usuario antes de cada tool call. Significa diseñar qué acciones pueden ejecutarse automáticamente, cuáles necesitan aprobación y qué límites funcionan incluso si el modelo se equivoca.

Las aprobaciones deben colocarse en puntos de riesgo.

Clasifica acciones

Ejemplo:

Nivel 0 — lectura Consultar información autorizada.

Nivel 1 — borrador Crear un artefacto interno reversible.

Nivel 2 — cambio reversible Modificar un estado con rollback.

Nivel 3 — efecto externo Enviar, publicar, reservar, comprar.

Nivel 4 — alto impacto Financiero, administrativo, seguridad, personas.

La política decide qué niveles requieren aprobación.

Aprobación informada

Una solicitud útil muestra:

• acción;
• recurso;
• argumentos;
• motivo;
• evidencia;
• impacto;
• reversibilidad.

No:

«¿Permitir tool call?»

Sí:

«El agente propone enviar el borrador X al cliente Y usando la plantilla Z.»

OpenAI Agents SDK permite pausar runs para aprobación de tool calls sensibles y reanudar después.

Revalida al ejecutar

Una aprobación no es autorización eterna.

Entre aprobación y ejecución puede cambiar:

• estado;
• usuario;
• permiso;
• recurso.

Revalida justo antes del efecto.

Guardrails en capas

Un guardrail puede existir en:

Input Validar tarea y datos.

Tool Bloquear argumentos.

Policy Permisos.

Execution Sandbox.

Output Validar resultado.

Budget Limitar pasos y coste.

Human Aprobación.

Ninguna capa es suficiente sola.

Límites deterministas

Ejemplos:

max_steps
max_tool_calls
max_writes
max_cost
max_time
allowed_domains
allowed_paths
allowed_amount

El modelo no puede ampliarlos.

OWASP identifica excessive autonomy y high-impact action abuse como riesgos específicos de agentes.

Diseña aprobación por lote

En una tarea de 50 acciones repetitivas, pedir 50 confirmaciones produce fatiga.

Puedes aprobar:

• plan;
• scope;
• límites.

Ejemplo:

«Permitir crear borradores para estos 20 tickets, sin enviar.»

La aprobación amplía autonomía dentro de una frontera concreta.

Mantén un kill switch

Debe poder desactivarse:

• agente;
• tool;
• proveedor;
• escritura;
• integración.

Sin esperar un despliegue.

Controla coste y denial of wallet

Loops pueden consumir recursos.

OWASP incluye Denial of Wallet entre riesgos agentic.

Aplica:

• budgets;
• rate limits;
• concurrencia;
• timeouts;
• circuit breakers;
• detección de repetición.

Ejemplo

Agente de compras:

Puede:

• consultar catálogo;
• comparar;
• preparar solicitud.

Necesita aprobación para:

• enviar pedido.

No puede:

• pagar;
• cambiar proveedor;
• modificar límites.

Separa aprobación de autenticación

Una persona que pulsa «aprobar» debe estar autenticada y autorizada para esa acción.

No aceptes una confirmación del mismo canal si no existe identidad verificable.

Registra:

• actor;
• timestamp;
• acción;
• scope;
• versión;
• argumentos.

Diseña expiración de aprobaciones

Una aprobación puede perder validez si:

• cambian argumentos;
• cambia recurso;
• pasa demasiado tiempo;
• cambia estado.

Incluye un fingerprint de la acción aprobada.

Si el agente propone una variante, vuelve a aprobar.

Guardrails deterministas vs basados en modelos

Usa código para:

• permisos;
• límites;
• formatos;
• dominios;
• importes;
• rutas.

Un modelo puede ayudar a detectar:

• contenido sensible;
• intención;
• riesgo semántico.

Pero un guardrail basado en modelo también puede fallar. No lo uses como única barrera para una acción crítica.

Diseña modos

Puedes tener:

SAFE Solo lectura.

ASSISTED Escrituras con aprobación.

LIMITED_AUTO Acciones reversibles dentro de scope.

EMERGENCY Solo lectura, sin tools externas.

Un cambio de modo debe poder hacerse sin modificar prompts manualmente.

Prueba bypass

Intenta:

• pedir al modelo que ignore límites;
• esconder instrucción en documento;
• dividir una acción prohibida en varias;
• usar una tool autorizada con argumentos peligrosos;
• reutilizar una aprobación anterior.

La seguridad se demuestra intentando romperla.

Define policy as code

Cuando sea posible, expresa reglas de autorización y límites en código o configuración versionada:

if action.type == "send_email":
  require_approval
if amount > limit:
  deny

Esto permite tests deterministas.

No escondas políticas críticas solo en instrucciones naturales.

Diseña un ledger de efectos

Para acciones reales registra:

• intención;
• aprobación;
• ejecución;
• resultado;
• reversión.

El ledger ayuda a reconciliar después de fallos.

Evita aprobación del propio agente

Un subagente no debe aprobar una acción que requiere independencia si ambos comparten el mismo contexto y autoridad.

La aprobación de alto impacto debe provenir de una entidad con autoridad separada: usuario, política determinista o servicio independiente.

Escalado por incertidumbre

No uses solo confidence > 0.8.

Considera:

• evidencia;
• novedad;
• riesgo;
• contradicción;
• ausencia de datos.

Una puntuación del modelo no reemplaza la lógica de escalado.

Prueba fatiga de aprobación

Simula una tarea con muchas solicitudes.

Si el usuario recibe demasiadas, rediseña:

• plan approval;
• batch;
• menor autonomía;
• tool distinta.

El objetivo es control significativo, no maximizar clics.

Ejercicio

Crea una matriz:

Después simula:

• argumento malicioso;
• permiso revocado;
• presupuesto agotado;
• usuario que rechaza.

Criterio de salida

Al finalizar, debes contar con una política donde la autonomía no depende de «confianza en el modelo». Depende de capacidades, límites y aprobaciones que el harness puede imponer.