Policy Boundaries en arquitectura: Qué acciones permiten los agentes

Idea en 30 segundos

La capa Policy Boundaries es el limite del sistema que define que puede hacer un agente y que no.

El agente puede proponer acciones, pero la decision final siempre la toma el sistema: allow, deny o require_approval.

Cuando se necesita: cuando el agente tiene acceso a herramientas, datos u operaciones que pueden cambiar estado, gastar presupuesto o crear riesgo.

El LLM no debe controlar por si solo side effects (cambios de estado). La capa Policy Boundaries lo fuerza a nivel de arquitectura.

Problema

Sin Policy Boundaries claras, el agente empieza a actuar "demasiado libre".

Esto crea riesgos tipicos:

el agente ejecuta una accion sin permisos necesarios;
lee o envia datos sensibles;
el agente supera presupuesto, cuotas o numero de pasos permitidos;
lanza operaciones irreversibles sin aprobacion;
distintos servicios aplican reglas distintas y el comportamiento se vuelve impredecible.

Como resultado, aumentan los riesgos de incidentes, las auditorias son mas dificiles y los errores cuestan mas.

Solucion

Agregar Policy Boundaries como una capa gobernada separada del sistema: valida cada accion riesgosa antes de ejecutarla.

Esta capa sigue "denegar por defecto" (deny by default): solo se permite lo que esta explicitamente en la allowlist y coincide con el contexto.

Analogia: como un sistema de acceso en un centro de oficinas.
Una persona puede querer entrar a la sala de servidores, pero la puerta se abre solo con el nivel correcto de acceso.
La capa Policy Boundaries verifica del mismo modo el acceso a acciones y recursos antes de ejecutar.

Como funcionan Policy Boundaries

Policy Boundaries es una capa gobernada entre Agent Runtime y las capas de ejecucion/datos que decide: permitir accion, bloquear o enviar a aprobacion.

Diagram

Descripcion del flujo completo: Classify → Check → Decide → Enforce → Log

Classify
El sistema clasifica el tipo de accion: lectura, escritura, eliminacion, exportacion, ejecucion de codigo, gasto de presupuesto.

Check
El policy engine verifica rol, tenant, allowlist, scopes, limites de presupuesto/pasos y nivel de riesgo.

Decide
La decision debe ser explicita: allow, deny o require_approval.

Enforce
La accion se bloquea o se ejecuta con permisos restringidos via Tool Execution Layer.

Log
El log guarda la decision, reason_code, request context y el resultado de ejecucion o el bloqueo.

Este ciclo aplica a cada accion riesgosa y da comportamiento predecible incluso con errores del modelo.

En codigo se ve asi

PYTHON

class PolicyBoundaryLayer:
    def __init__(self, policy_engine, approval_queue):
        self.policy_engine = policy_engine
        self.approval_queue = approval_queue

    def authorize(self, action, context):
        request = {
            "actor_role": context["role"],
            "tenant_id": context["tenant_id"],
            "action": action["name"],
            "resource": action.get("resource"),
            "risk_level": action.get("risk_level", "medium"),
        }

        decision = self.policy_engine.evaluate(request)
        mode = decision.get("mode")

        if mode == "allow":
            return {"ok": True, "mode": "allow", "scopes": decision.get("scopes", [])}

        if mode == "require_approval":
            ticket_id = self.approval_queue.create(request=request, reason=decision["reason_code"])
            return {"ok": False, "mode": "pending_approval", "ticket_id": ticket_id}

        # Fail-closed for deny and for unexpected/unavailable policy modes.
        return {
            "ok": False,
            "mode": "deny",
            "reason_code": decision.get("reason_code", "policy_unavailable_or_invalid"),
        }

Como se ve en ejecucion

TEXT

Solicitud: "Elimina la factura INV-991 y envia datos del cliente a un CRM externo"

Step 1
Agent Runtime: forma action -> delete_invoice + export_customer_data
Runtime: envia acciones a Policy Boundaries

Step 2
Policy Boundaries: Check -> rol support_agent, riesgo high
Policy Engine: delete_invoice -> require_approval
Policy Engine: export_customer_data -> deny (reason_code: cross_system_export_blocked)

Step 3
Runtime: crea approval ticket para eliminacion
Runtime: bloquea exportacion y devuelve respuesta segura con motivo

Policy Boundaries no solo "aconseja", realmente detiene acciones peligrosas.

Cuando encaja - y cuando no

La capa Policy Boundaries se necesita donde hay riesgos reales de acceso, cambios de estado o costos. Para un prototipo local read-only puede ser complejidad innecesaria.

Encaja

	Situacion	Por que encaja Policy Boundaries
✅	Hay herramientas que cambian el estado del sistema	La capa Policy Boundaries bloquea operaciones peligrosas o exige aprobacion.
✅	Se requiere modelo de acceso por rol y aislamiento multi-tenant	Policy rules unificadas evitan fugas entre tenants y roles.
✅	El agente puede gastar dinero o recursos limitados	La capa Policy Boundaries controla budget caps, quotas y `require_approval` para acciones costosas.
✅	Se requiere auditoria de decisiones para compliance	La capa Policy Boundaries registra decision, reason_code y contexto para cada accion critica.

No encaja

	Situacion	Por que Policy Boundaries no encaja
❌	Demo one-shot con una herramienta read-only y sin side effects	Una capa separada de Policy Boundaries puede aportar mas complejidad que valor.
❌	El agente no decide por si mismo - todo el flow esta codificado de forma determinista en la logica de negocio	Normalmente bastan verificaciones simples en la logica de negocio del servicio.

En estos casos, a veces basta una verificacion basica en codigo:

PYTHON

if role != "admin":
    raise PermissionError("denied")

Problemas y fallos tipicos

Problema	Que pasa	Como prevenir
Bypass de policy boundary	Las acciones se ejecutan directo, saltando policy checks	Punto unico de entrada para herramientas, acceso directo prohibido
Fail-open cuando falla el policy engine	Durante el fallo, el sistema permite por error acciones riesgosas	Fail-closed para operaciones write/high-risk, deny by default de emergencia
Reglas demasiado estrictas	Se bloquean acciones utiles y el agente no puede terminar la tarea	Reglas por risk-tier, excepciones con auditoria y revision regular de politicas
Policy drift (reglas fuera de sincronizacion)	La documentacion dice una cosa y el codigo valida otra	Policy-as-code, versionado y pruebas de reglas
No hay explicacion del motivo del bloqueo	El equipo no entiende por que se rechazo la accion	`reason_code` estandarizado y logs de auditoria
Contexto incompleto para policy check	El policy engine decide sin atributos importantes de la solicitud	Enviar `request context` completo: actor, tenant, resource, action type, risk, budget

La mayoria de estos problemas se resuelve con un unico punto de control de policy, enfoque fail-closed y auditoria de calidad.

Como se combina con otros patrones

Policy Boundaries no reemplaza Agent Runtime ni Tool Execution Layer. Es control de acceso a nivel sistema por encima de ellos.

Agent Runtime - Runtime controla los pasos y Policy Boundaries verifica que acciones estan permitidas en esos pasos.
Tool Execution Layer - execution layer ejecuta la accion y Policy Boundaries decide si puede ejecutarse.
Human-in-the-Loop Architecture - las acciones riesgosas pueden pasar a require_approval.
Multi-Tenant - Policy Boundaries fuerza aislamiento de accesos entre tenants.

En otras palabras:

Agent Runtime define cuando el agente da un paso
La capa Policy Boundaries define que acciones en ese paso estan permitidas

En que se diferencia de Guarded-Policy Agent

	Guarded-Policy Agent	Policy Boundaries en arquitectura
Nivel	Patron de comportamiento dentro de la logica del agente	Capa de control forzado a nivel de arquitectura
Que controla	Como el agente formula y elige acciones	Si esa accion esta realmente permitida para ejecutar
Como reacciona ante error del modelo	Reduce riesgo, pero no garantiza bloqueo	Bloquea forzosamente o envia a aprobacion
Resultado clave	Comportamiento del agente mas seguro	Limites de acceso tecnicamente garantizados + auditoria

Guarded-Policy Agent hace mas prudente el comportamiento del agente.

La capa Policy Boundaries mantiene controlada la ejecucion de acciones incluso si el agente se equivoca.

Resumen

En resumen

Policy Boundaries:

define que esta permitido, prohibido o requiere aprobacion
fuerza verificacion de rol, tenant, allowlist y riesgo de accion
bloquea acciones peligrosas antes de ejecutar
registra decisiones y reason_code para auditoria

FAQ

Q: Si ya hay Guarded-Policy Agent, aun se necesita Policy Boundaries?
A: Si. Guarded-Policy Agent mejora comportamiento, pero la capa Policy Boundaries es la que fuerza cumplimiento de reglas a nivel sistema.

Q: Donde conviene guardar policy rules?
A: Normalmente en un policy engine separado o capa policy-as-code con versiones y pruebas.

Q: Que hacer si policy engine no esta disponible?
A: Para operaciones write riesgosas, aplicar fail-closed: denegar ejecucion mientras no haya verificacion.

Q: Puede depender Policy Boundaries del entorno (dev, staging, prod)?
A: Si. Las mismas acciones suelen tener policy rules distintas segun entorno, nivel de riesgo y tipo de datos.

Que Sigue

Policy Boundaries define las reglas del juego. El siguiente paso es ver donde se aplican esas reglas dentro del sistema:

Tool Execution Layer - como se aplica policy durante tool calls reales.
Human-in-the-Loop Architecture - como disenar aprobacion para acciones criticas.
Agent Runtime - como runtime detiene o continua el ciclo segun reglas.
Production Stack - como policy se vuelve parte de la disciplina operativa.