Patrón Guarded-Policy Agent: Acciones seguras por reglas

Esencia Del Patron

Guarded-Policy Agent es un patron donde antes de cada accion se aplica un policy-gate: allow, deny, rewrite o escalate segun reglas formalizadas.

Cuando usarlo: cuando las acciones del agente deben pasar verificaciones formales de reglas antes de ejecutarse.

La idea es simple: el agente puede proponer cualquier cosa, pero solo se ejecutan los pasos que pasan la verificacion de politicas.

Guardrails de policy normalmente revisan:

• tools y parametros permitidos
• limites de acceso a datos
• limites de budget/time
• nivel de riesgo de la accion

Problema

Imagina un escenario bancario: se debe transferir 100$, pero por error se ingresan 10,000$.

Si un sistema sin verificaciones solo dice "ejecutar", la accion pasa a prod.

Incluso cuando:

• el cliente no tiene ese saldo
• el monto supera el limite del rol
• la cuenta destino es externa y requiere validaciones adicionales

Sin un policy gate tecnico, el agente puede ejecutar una accion peligrosa incluso cuando es obvio que no deberia pasar.

Ese es el problema: sin restricciones, cualquier accion puede ejecutarse, aunque sea:

• peligrosa
• demasiado costosa
• violando reglas de acceso

Solucion

Guarded-Policy Agent introduce verificaciones obligatorias antes de cada accion.

Analogia: es como un torniquete con control de acceso. Aunque una persona quiera pasar, primero se validan permisos y reglas. Sin aprobacion, el sistema no deja continuar la accion.

Principio clave: el modelo puede proponer cualquier paso, pero solo se ejecutan pasos que pasan el policy gate.

Cada accion pasa por:

1. verificacion de permisos
2. verificacion de presupuesto/limites
3. verificacion de acceso a datos
4. evaluacion de riesgo

Despues de eso, policy-engine devuelve una decision:

• permitir (allow) - ejecutar
• reescribir (rewrite) - reemplazar por variante segura
• bloquear (deny) - bloquear
• escalar (escalate) - pasar a una persona

Esto protege de escenarios donde el agente puede:

• escribir en vez de leer
• extraer datos sensibles
• lanzar una consulta costosa
• hacer una operacion destructiva

Funciona bien si:

• el agente no tiene acceso directo a tools
• la ejecucion ocurre solo por policy-engine
• cada accion pasa obligatoriamente por allow/deny/rewrite/escalate

La confiabilidad del agente no es solo "buena intencion", sino acciones que tecnicamente no puede ejecutar fuera de reglas.

Como Funciona

Policy-gate no ejecuta la accion por si mismo. Decide si puede ejecutarse y en que forma.

En Codigo Se Ve Asi

action = agent.next_action(context)

decision = policy_engine.evaluate(
    action=action,
    user_role=user_role,
    budget_state=budget_state,
)

if decision.type == "allow":
    result = execute(action)
elif decision.type == "rewrite":
    context.append(decision.reason)
    return agent.next_action(context)  # proponer de nuevo por el mismo gate
elif decision.type == "escalate":
    result = human_approval(action)
else:
    result = stop_with_reason(decision.reason)

return result

Principio clave: agent intent y ejecucion son capas distintas. Policy se ubica entre intent y ejecucion (execution).

El modelo no tiene acceso directo a ejecucion, solo a traves de una capa de ejecucion policy-gated (execution layer).

Como Se Ve En Ejecucion

Goal: "Exporta todos los clientes a CSV y envialos por correo externo"

Agent action:
- tool: export_customers
- params: include_pii=true
- destination: external_email

Policy check:
- rule: PII export to external channels = deny
- decision: bloquear (block)
- reason: policy.pii_exfiltration_guard

Result:
- la accion no se ejecuto
- se devolvio una negativa controlada

Cuando Encaja - Y Cuando No

Encaja

No Encaja

Porque la capa de policy agrega complejidad de ingenieria: reglas, tests de reglas y actualizacion continua para procesos de negocio.

Diferencia Frente A Supervisor Agent

Guarded-Policy es una barrera tecnica "por reglas".

Supervisor Agent es control de supervision "segun la situacion".

Cuando Usar Guarded-Policy (vs Otros Patrones)

Usa Guarded-Policy cuando necesitas detener acciones riesgosas antes de ejecutarlas segun reglas de policy claras.

Prueba rapida:

• si necesitas "check allow/deny antes de la accion" -> Guarded-Policy
• si necesitas "recuperarte despues de un error ya ocurrido" -> Fallback-Recovery Agent

Como Combinar Con Otros Patrones

• Guarded-Policy + ReAct: cada accion en el ciclo pasa primero por policy-check y luego se ejecuta.
• Guarded-Policy + Supervisor: Supervisor decide cuando escalar, y policy-engine aplica automaticamente reglas duras.
• Guarded-Policy + Fallback-Recovery: si una accion se bloquea o un paso falla, el agente cambia a un fallback permitido y seguro.

Resumen

Ventajas Y Desventajas

FAQ

Q: Se puede reemplazar verificacion de policy solo con instrucciones de prompt?
A: No. Prompt opera en nivel de intent, pero no controla ejecucion. Policy debe aplicarse en la capa runtime.

Q: Que es mejor: allowlist o blocklist?
A: Para sistemas de alto riesgo, es mas seguro empezar con allowlist: solo se permiten acciones definidas de forma explicita.

Q: Que hacer si una regla es demasiado estricta y bloquea una accion util?
A: Agregar excepciones controladas: scope, condiciones por rol o ruta con aprobacion humana en lugar de deny total.

Que Sigue

El enfoque Guarded-Policy protege al agente de acciones inseguras antes de ejecutar.

Pero que hacer cuando el agente necesita ejecucion de codigo segura en un entorno aislado?