Policy Engines para agentes de IA empiezan a ser una pieza esencial cuando el modelo deja de limitarse a responder y comienza a ejecutar acciones. El motivo es simple: hay decisiones que no deberíamos delegar a un sistema probabilístico.
Un LLM puede proponer una acción, explicar por qué cree que tiene sentido e incluso estimar su riesgo. Pero la decisión final sobre si una operación está autorizada debería depender de reglas que podamos inspeccionar, versionar, probar y auditar.
Ahí entran conceptos clásicos como PDP y PEP. Lo interesante es que, aplicados a agentes, aparece un problema adicional: el Policy Engine puede evaluar perfectamente la política correcta y aun así proteger el estado equivocado.
PDP y PEP sin complicarlo
Open Policy Agent describe OPA como un Policy Decision Point: el componente que recibe datos de entrada y produce una decisión para una aplicación.
La aplicación que consulta esa decisión actúa como Policy Enforcement Point: es quien debe hacer cumplir el resultado.
PEP pregunta → PDP evalúa → PDP responde → PEP hace cumplir.
NEURON HUMAN
La pregunta correcta de autorización
Cedar resume una solicitud de autorización mediante cuatro piezas especialmente útiles:
- Principal: quién intenta actuar.
- Action: qué quiere hacer.
- Resource: sobre qué quiere hacerlo.
- Context: qué condiciones adicionales existen.
¿Puede este principal realizar esta acción sobre este recurso en este contexto?
Para agentes de IA esta estructura obliga a abandonar autorizaciones vagas como “el agente tiene acceso a Drive” y empezar a pensar en operaciones concretas.
El modelo propone; la policy decide
Imaginemos que un agente quiere enviar un documento. El modelo puede proponer la tool, el recurso y el destino. El Policy Engine no necesita decidir si la idea es inteligente; necesita evaluar propiedades verificables.
- ¿El usuario puede leer ese archivo?
- ¿Puede enviarlo fuera de la organización?
- ¿El destino está permitido?
- ¿El documento contiene datos clasificados?
- ¿La tarea original contempla ese envío?
Ésta es una frontera importante: razonamiento y autoridad no deberían ser la misma cosa.
El problema de proteger el estado equivocado
Un Policy Engine puede evaluar perfectamente la información que recibe. El problema aparece cuando esa información ya no representa el mundo real.
Policy input: user.role = admin
Realidad actual: user.role = suspended
Si el PDP recibe un snapshot obsoleto, puede devolver un ALLOW completamente correcto respecto a un estado que dejó de existir.
Eso conecta directamente con Stale Authorization: una decisión correcta puede quedar invalidada cuando cambia alguna dependencia antes del efecto.
Policy as Code no significa Policy as Truth
OPA, Cedar y otros motores permiten expresar políticas de forma clara, versionable y testeable. Eso mejora muchísimo la seguridad. Pero la policy sigue dependiendo de los datos con los que se evalúa.
Podemos tener una regla impecable y aun así fallar si la clasificación llega desactualizada, el tenant está mal resuelto o el principal efectivo no corresponde al usuario real.
El contexto no debería venir libremente del modelo
Cedar permite utilizar contexto adicional en las decisiones. En agentes debemos ser extremadamente cuidadosos con quién construye ese contexto.
context.risk = "low"calculado por un sistema de riesgo independiente.context.risk = "low"porque el propio LLM afirmó que la operación era segura.
Los atributos que gobiernan autoridad deberían proceder de fuentes de confianza identificables y verificables.
Un modelo puede aportar evidencia a una policy. No debería poder escribirse a sí mismo los atributos que le conceden permiso.
NEURON HUMAN
Forbid como guardrail determinista
Cedar tiene una propiedad interesante: las políticas forbid prevalecen sobre los permit. Esto permite modelar invariantes que ninguna nueva policy permisiva debería poder atravesar.
- Prohibir exportación de datos Restricted a destinos externos.
- Prohibir cambios de privilegio sin aprobación fuerte.
- Prohibir acciones cross-tenant.
- Prohibir ejecución si la identidad no está atestada.
El PEP es tan importante como el PDP
Podemos diseñar el mejor Policy Engine del mundo y seguir siendo vulnerables si existe una ruta que evita el enforcement.
El PEP debe estar colocado en el lugar donde realmente se produce el efecto. Si una API consulta policy pero un worker interno no lo hace, existe una ruta alternativa capaz de saltarse el control.
Policy distribution también es seguridad
OPA permite distribuir bundles de policies y datos a instancias locales. Eso mejora latencia y disponibilidad, pero introduce consistencia distribuida. La documentación de OPA describe este modelo como eventualmente consistente.
Para acciones de alto riesgo debemos saber qué versión estaba activa, qué bundle utilizó el PDP y si una revocación crítica debe propagarse de forma más fuerte que el modelo normal.
Decision logs: autorización auditable
OPA puede producir decision logs con información sobre la policy consultada, el input y metadata del bundle. Para agentes esto permite correlacionar:
root task → acción propuesta → policy input → decision → effect.
Los propios inputs de autorización pueden contener datos sensibles, por lo que deben filtrarse o enmascararse antes de exportar logs cuando corresponda.
Cómo diseñaría Policy Engines para agentes de IA
1. Principal, action, resource y context explícitos
Evitar autorizaciones vagas basadas únicamente en el nombre de una tool.
2. Contexto con procedencia
Cada atributo relevante debe tener una fuente de confianza definida.
3. PEP junto al efecto
La decisión debe hacerse cumplir donde la operación se vuelve real.
4. Versionado de policy y estado
Un ALLOW debe poder reconstruir qué versión de reglas y datos lo justificó.
5. Invariantes deny/forbid
Los límites fundamentales no deberían depender de prompts ni de recomendaciones del modelo.
Qué debería observar un Blue Team
- policy version y bundle version;
- principal efectivo;
- resource y action exactos;
- fuente de cada atributo de context;
- PEP utilizado;
- rutas que ejecutan efectos sin decisión registrada;
- discordancia entre decision y commit-time state.
Qué debería probar un Purple Team
- atributo de riesgo suministrado por el propio modelo;
- tenant incorrecto en el context;
- policy bundle antiguo;
- worker que intenta evitar el PEP;
- forbid invariant frente a nuevo permit;
- revocación entre PDP decision y efecto.
Dónde encaja MindGuard
Una de las líneas fundamentales de MindGuard es que las decisiones sensibles no dependan exclusivamente del modelo. El LLM puede proponer, clasificar o explicar. La autoridad final debe pasar por controles deterministas capaces de conservar estado, procedencia y evidencia.
El modelo puede sugerir una decisión. La policy debe gobernar el efecto.
MINDGUARD RESEARCH
El problema no es solo escribir la policy correcta
Policy as Code nos permite expresar reglas mucho mejor que un prompt. Pero una policy correcta aplicada sobre identidad equivocada, datos obsoletos o un recurso mal resuelto puede seguir produciendo una decisión peligrosa.
La autorización no protege el estado que escribimos en la regla. Protege el estado que realmente presentamos al motor cuando preguntamos.
NEURON HUMAN
Referencias
- Open Policy Agent — Deployment and PDP/PEP architecture
- Open Policy Agent — Decision Logs
- Open Policy Agent — Bundles
- Cedar Policy Language — Authorization
- Cedar Policy Language — Using context
Preguntas frecuentes
¿Qué es un PDP?
Es el Policy Decision Point, el componente que evalúa una solicitud contra políticas y devuelve una decisión de autorización.
¿Qué es un PEP?
Es el Policy Enforcement Point, el componente que hace cumplir la decisión antes de permitir que ocurra el efecto protegido.
¿Por qué un agente necesita un Policy Engine?
Porque determinadas decisiones de autoridad deben ser deterministas, auditables y separadas del razonamiento probabilístico del modelo.
