Policy Rules
Crea y gestiona reglas de política basadas en CEL que controlan el comportamiento de las herramientas de IA.
Las Policies son reglas que Edison Watch evalúa frente a cada llamada a herramienta de IA en tiempo real. Pueden bloquear acciones, etiquetar sesiones, establecer niveles de control de acceso y más, todo sin cambiar la configuración de la herramienta de IA.
La Vista Policies
Ve a Policies en la barra lateral. La página se divide en dos paneles:
- Barra lateral izquierda: lista de todas las reglas, agrupadas por estado, con un cuadro de búsqueda.
- Panel derecho: detalles de la regla seleccionada.
La franja de resumen en la parte superior de la barra lateral muestra los recuentos de reglas enabled, tentative y disabled de un vistazo.
Estados de las Reglas
| Estado | Significado |
|---|---|
| enabled | La regla está activa y se aplica a cada llamada a herramienta coincidente. |
| tentative | La regla se evalúa pero solo se registra: las acciones no se aplican. Útil para probar una nueva regla de forma segura. |
| disabled | La regla se almacena pero nunca se evalúa. |
Fases de las Reglas
Cada regla se ejecuta en una de dos fases:
| Fase | Cuándo se ejecuta | Comportamiento de bloqueo |
|---|---|---|
| pre | Antes de que se ejecute la llamada a la herramienta. | Previene la ejecución. |
| post | Después de que se complete la llamada a la herramienta; el result de la herramienta está disponible en la expresión. | La llamada ya se ha ejecutado: el resultado se reemplaza con un error antes de devolverlo a la IA, evitando la exfiltración de salida sensible. |
Contexto de Expresiones CEL
Las reglas se escriben en CEL (Common Expression Language). Las expresiones se evalúan frente a cuatro objetos de nivel superior que representan la llamada a herramienta actual:
| Variable | Campos | Notas |
|---|---|---|
principal | user_id, email, roles | El usuario que realiza la llamada. roles es una lista de sus nombres de roles personalizados. |
resource | type, name, server | Qué se está llamando. type es "tool", "resource" o "prompt". |
tool | args, input_schema, output_schema, result | result solo se completa en la fase post. |
session | has_private_data_access, has_untrusted_content_exposure, has_external_communication, highest_acl_level, tool_history, tags | Estado de la sesión actual, incluidos los tres indicadores del Lethal Trifecta. |
Si la expresión se evalúa como true, se aplican las acciones de la regla.
resource.server == "github" && resource.name == "delete_branch" &&
tool.args.branch == "main"Funciones integradas
| Función | Devuelve | Descripción |
|---|---|---|
pii_detect(value, [categories]) | bool | true si se encuentra PII de cualquiera de las categorías listadas en cualquier parte de value (búsqueda recursiva, incluidos campos anidados). Categorías: "EMAIL", "API_KEYS", "PHONE", "CREDIT_CARD". |
Combina pii_detect sobre tool.args con una acción block para impedir que un agente envíe datos sensibles a través de una herramienta. Limita la regla a tus servidores de comunicación externa para que la detección no se ejecute en el hot path en otros sitios.
pii_detect(tool.args, ["CREDIT_CARD", "API_KEYS"])pii_detect falla abierto: si el detector falla, la expresión se evalúa como false (la regla no se dispara), de modo que un fallo del detector nunca bloquea tráfico legítimo. Es defensa en profundidad sobre la protección siempre activa de Lethal Trifecta. Prefiere categorías de alta precisión (CREDIT_CARD, API_KEYS) para bloquear - EMAIL y PHONE aparecen en muchas llamadas legítimas (la dirección del destinatario es un email), así que bloquear por ellas suele ser demasiado amplio.
La detección se ejecuta sobre los argumentos antes de que se restauren tokens PII de Edison, así que captura PII en bruto que el agente compuso directamente. Los valores que reentran como token de Edison (desde un resultado de herramienta previamente redactado) son opacos en esta etapa; esas rutas de exfiltración las cubre en su lugar la protección Lethal Trifecta. pii_detect es más útil en la fase pre sobre tool.args.
Acciones
| Acción | Efecto |
|---|---|
block | Previene que se ejecute la llamada a la herramienta y devuelve un error a la IA. |
mark_private | Marca la sesión como que contiene datos privados. |
mark_untrusted | Marca la sesión como que contiene contenido externo no confiable. |
mark_write | Marca la sesión como que ha realizado una operación de escritura. |
set_acl | Establece el nivel ACL de la sesión (PUBLIC, PRIVATE o SECRET). |
add_tag | Agrega una etiqueta clave-valor a la sesión para filtrado y auditoría. |
allow_override | Permite explícitamente la llamada incluso si otras reglas la bloquearían. |
Alcance de las Reglas
Las reglas pueden limitarse a principals y recursos específicos:
- Alcance de principal: Apunta a todos los usuarios globalmente, a roles específicos o a usuarios específicos.
- Alcance de recurso: Apunta a servidores específicos, tipos de elementos (tools/resources/prompts) o patrones de nombres.
Las reglas sin alcance se aplican a todos los principals y recursos.
Prioridad y Anulaciones
Cuando varias reglas coinciden con la misma llamada a herramienta, se aplican las acciones de todas las reglas coincidentes. La prioridad rige cómo interactúan block y allow_override:
- Un
blockse cancela solo si una reglaallow_overridecoincidente tiene una prioridad igual o superior. - De lo contrario, gana el bloqueo.
| Reglas coincidentes | Prioridades | Resultado |
|---|---|---|
block + allow_override | 100 vs. 100 | ✅ Permitido (override ≥ block) |
block + allow_override | 100 vs. 99 | ❌ Bloqueado (override < block) |
block solo | cualquiera | ❌ Bloqueado |
Las acciones que no son de bloqueo (mark_*, set_acl, add_tag) se aplican siempre que coincida su regla y no se ven afectadas por esta resolución.
Creando una Política
- Haz clic en Create Policy en la barra lateral izquierda.
- Elige una plantilla del selector de plantillas, o empieza desde cero.
- Completa el nombre de la regla, la expresión CEL, la fase, la prioridad, las acciones y el alcance.
- Guarda la regla.
Probando Reglas Antes de Activarlas
El editor de reglas tiene un panel evaluate que ejecuta tu expresión CEL frente a un contexto sintético (principal, resource, tool args y session flags) sin guardar la regla. Úsalo para confirmar que la expresión coincida con los casos que esperas y para ver qué acciones se dispararían.
Para un lanzamiento más suave frente al tráfico real, guarda la regla con el estado tentative. Las coincidencias se registran en el servidor como ⚠️ TENTATIVE match - would apply actions: ...; actualmente no hay una vista dedicada en el panel para los hits tentative, así que revisa los logs del servidor o tu SIEM. Promueve la regla a enabled una vez que tengas confianza.
Editando y Eliminando
Selecciona una regla en la barra lateral, luego haz clic en Edit o Delete en el panel de detalles.