Escritas como reglas
Cada regla es una condición (p. ej. amountUsd >= 5000) más un efecto — allow, deny o require_approval — y una prioridad. Sin redespliegue: las reglas son datos con alcance de tenant que el runtime lee en cada ejecución.
Policy-as-Code
Gobierna agentes de IA con reglas que puedes probar antes de publicar.
Redacta reglas de permitir, denegar y requerir aprobación en un solo lugar, simula cualquier decisión antes de activarla y somete cada cambio a un conjunto de pruebas de política de referencia, para que una edición de regla nunca cambie en silencio lo que tus agentes tienen permitido hacer.
deny > require_approval > allow · simula antes de publicar · las pruebas golden validan cada cambio
Policy Studio
# cortex_policy_rules · priority order · deny > require_approval > allow
rule "high-value-payout" {
priority: 10
when: amountUsd >= 5000
effect: require_approval
}
rule "export-pii" {
priority: 5
when: action == "export" && pii == true
effect: deny
}
simulate ▸ POST /v1/governance/simulate
require_approval
allow
trace ▸ high-value-payout coincidió · motivo: amountUsd >= 5000
governance ▸ simula antes de publicar · las pruebas golden validan cada cambio
Gobernanza que puedes redactar
La política es configuración, no un despliegue de código.
La gobernanza de Cortex es un conjunto de reglas priorizadas: cada una con una condición y un efecto de allow, deny o require_approval. El runtime las evalúa en orden de prioridad en cada ejecución y siempre gana el efecto más restrictivo: deny supera a require_approval, que supera a allow. Como las reglas son datos, tus equipos de riesgo y cumplimiento las escriben y las cambian directamente, y cada cambio se puede probar antes de que toque a un solo agente.
Gana la más restrictiva
Las reglas se aplican por orden de prioridad, las reglas deshabilitadas se omiten y prevalece el efecto coincidente más estricto: deny > require_approval > allow. El gobierno opta por defecto por la cautela, nunca por el permiso.
Simuladas antes de publicar
Pasa cualquier contexto por las reglas en vivo — o por un conjunto candidato sin guardar — y obtén la decisión más una traza por regla, para ver exactamente qué regla se activó y por qué antes de guardarla.
Probadas como compuerta
Las pruebas golden de políticas fijan las decisiones que deben cumplirse. Ejecútalas contra un conjunto de reglas candidato: un solo fallo te dice que no debes publicar — una compuerta de regresión para el propio gobierno.
El problema que resuelve
Una edición de política sin probar es un cambio silencioso en lo que pueden hacer los agentes.
Cuando la gobernanza vive en sentencias if dispersas y en el texto de los prompts, una edición bienintencionada puede ampliar en silencio lo que cada agente tiene permitido hacer, y solo te enteras en la auditoría. Policy-as-Code convierte las reglas en datos explícitos, te deja previsualizar una decisión antes de publicarla y se niega a aceptar un cambio si rompe un solo caso golden. El mismo motor impulsa la decisión en vivo y la simulación, así que lo que pruebas es exactamente lo que se ejecuta.
Simula cualquier contexto → decisión + traza por regla, antes de guardardeny > require_approval > allow — gana el efecto más restrictivoUna prueba golden fallida → el conjunto de reglas candidato nunca se publica
Cómo funciona
Redacta, simula, prueba, publica.
Un único motor puro — evaluateRules(rules, context) — decide cada ejecución y cada simulación. Ese camino compartido es lo que hace fiable una simulación: la vista previa y la decisión en producción son el mismo código.
- 01
Escribir la regla
Escribe una condición y un efecto — allow, deny o require_approval — con una prioridad. La prioridad más baja se evalúa primero; las reglas deshabilitadas se omiten. Las reglas son datos con alcance de tenant, no un despliegue.
- 02
Simular antes de publicar
Haz POST de un contexto a /simulate contra las reglas en vivo o un conjunto candidato sin guardar. Obtienes el efecto, la regla coincidente, el motivo y la traza completa por regla — previsualiza el cambio antes de que sea real.
- 03
Ejecutar las pruebas golden
Fija los casos conocidos como pruebas golden (contexto → efecto esperado). Ejecútalas contra el conjunto de reglas candidato; un solo fallo significa una regresión — no lo publiques.
- 04
Publicar bajo las compuertas
Cuando el conjunto candidato pasa, se convierte en la política en vivo — evaluada en cada ejecución dentro del mismo runtime de cierre seguro, junto a la identidad, el presupuesto y el Trust Ledger.
Dónde encaja la política
La puerta de política es una parada dentro de la ejecución.
Qué hay en el motor
Reglas, simulación, pruebas y la traza que las une.
Creación de reglas
- allow / deny / require_approval
- Condición + prioridad
- Activar / desactivar por regla
- Con alcance por tenant, sin redespliegue
- CRUD + deleteRule desde el SDK
Motor de evaluación
- evaluateRules(rules, context) puro
- Orden de prioridad, de menor a mayor
- deny > require_approval > allow
- Las reglas desactivadas se omiten
- El mismo motor, en vivo y en simulación
Simulación
- POST /simulate { context }
- Reglas en vivo o conjunto candidato
- Devuelve effect + matchedRule
- Traza por regla + motivo
- Previsualiza cambios sin guardar
Pruebas golden de políticas
- context → expectEffect
- Crear / listar / eliminar casos
- POST /tests/run → passed/total
- Ejecuta contra un conjunto candidato
- Compuerta de regresión antes de publicar
Traza y evidencia
- Se registra la coincidencia u omisión de cada regla
- Motivo de la decisión
- Se identifica la regla que coincidió
- GET /counts → rules, tests
- Salida legible para auditores
Mínimo del runtime
- requiresApproval de la acción sigue aplicándose
- Las acciones de alto riesgo se retienen aparte
- La política solo puede endurecer, nunca relajar
- Fail-closed junto a las demás compuertas
- Mutaciones restringidas a administradores en la consola
Demuéstralo, no lo afirmes sin más
Las mismas reglas, dos contextos, dos decisiones honestas.
Fija una regla require_approval en amountUsd >= 5000 y luego simula. Un pago de $7,400 devuelve require_approval, con la regla coincidente y el motivo en la traza; un pago de $100 devuelve allow porque no coincidió ninguna regla. Sin conjeturas: la simulación ejecuta exactamente el motor que controla producción.
- Simula { amountUsd: 7400 } → require_approval
- Simula { amountUsd: 100 } → allow
- Un export con pii: true → deny (gana la más restrictiva)
- Cada simulación devuelve la regla coincidente, el motivo y la traza por regla
Pruebas golden de políticas
POST /v1/governance/tests/run { candidateRules: […] } ▸ 3 / 4 superadas
big-payout-needs-approval
{ amountUsd: 9000 } · esperado require_approval
correctosmall-payout-allowed
{ amountUsd: 100 } · esperado allow
correctopii-export-denied
{ action: export, pii: true } · esperado deny
correctorefund-under-cap-allowed
{ amountUsd: 240 } · esperado allow · obtenido deny
fallotests ▸ 1 fallo → el conjunto de reglas candidato no se publica (compuerta de regresión)
3Efectos: allow · require_approval · deny
$7,400Simulado → require_approval (regla en ≥ $5,000)
$100Simulado → allow (ninguna regla coincidió)
1Una prueba golden fallida bloquea el cambio de reglas
Policy Studio
# cortex_policy_rules · priority order · deny > require_approval > allow
rule "high-value-payout" {
priority: 10
when: amountUsd >= 5000
effect: require_approval
}
rule "export-pii" {
priority: 5
when: action == "export" && pii == true
effect: deny
}
simulate ▸ POST /v1/governance/simulate
require_approval
allow
trace ▸ high-value-payout coincidió · motivo: amountUsd >= 5000
governance ▸ simula antes de publicar · las pruebas golden validan cada cambio
Pruebas de referencia como barrera de regresión
Valida un cambio de regla antes de que toque a ningún agente.
Envía un conjunto de reglas candidato a /tests/run y Cortex evaluará cada caso de referencia sin guardar nada. Un candidato ingenuo que lo deniegue todo fallaría los casos que esperan permitir, así que la barrera te dirá que no lo publiques. Fija una vez las decisiones que importan y ninguna edición futura podrá cambiarlas en silencio; el endpoint de ejecución es la barrera manual que aplicas en cada cambio.
- Ejecuta las pruebas golden contra un conjunto candidateRules: no se guarda nada
- El resultado es { total, passed, failed, results[] }
- Un candidato que deniega todo falla los casos allow → no lo publiques
- Las decisiones que te importan quedan fijadas frente a cualquier edición futura
Funciona con el resto del runtime
La política no aplica sola: lo hace el runtime.
Policy-as-Code es una puerta dentro del mismo runtime de fallo cerrado que la identidad, las acciones, la supervisión y el libro de registro. Sigue los radios.
Action Fabric
Cuando una regla devuelve require_approval, la acción va a la bandeja de aprobación — en pending_approval hasta que un administrador la apruebe, nunca se ejecuta automáticamente.
Modos de supervisión
Los cinco modos de autonomía definen cuánto puede ejecutar un agente por su cuenta — y la compuerta de riesgo es un mínimo que la política puede endurecer pero nunca relajar.
Trust Ledger
Cada decisión de política queda registrada en un rastro de auditoría encadenado por hash que evidencia cualquier manipulación, con recibos firmados y verificables sin conexión.
Agent IAM
Los agentes son identidades gobernadas con modelos y acciones en listas de permitidos — la política decide por ejecución, la identidad decide por agente.
Ontología
Los permisos de objeto, propiedad y acción dan a las condiciones de política un significado de negocio real que evaluar, no solo campos en bruto.
Control Tower
Los recuentos de reglas y pruebas en vivo se muestran como KPIs y filas CSV — supervisa y exporta el estado de tu conjunto de políticas en un solo lugar.
Seguridad y cumplimiento
Diseñado para la revisión de seguridad corporativa.
Evaluación con denegación por defecto, precedencia de lo más restrictivo, mutaciones de reglas restringidas a administradores y una traza por regla en cada decisión, mapeado a los marcos que tus auditores ya utilizan.
SOC 2ISO 27001ISO 42001HIPAAGDPREU AI ActNIST AI RMFFINRA
Escribe las reglas una vez. Demuéstralas siempre.
Convierte la gobernanza de tus agentes en política verificable y simulable, para que un cambio de regla nunca altere en silencio lo que tus agentes tienen permitido hacer.