Rédigez vos règles allow, deny et require_approval au même endroit, simulez n'importe quelle décision avant sa mise en production et soumettez chaque changement à une suite de tests de politique de référence — pour qu'une modification de règle ne puisse jamais changer en silence ce que vos agents ont le droit de faire.
deny > require_approval > allow · simulez avant la mise en production · les tests golden filtrent chaque modification
La gouvernance Cortex est un ensemble de règles priorisées : chacune associe une condition à un effet allow, deny ou require_approval. Le runtime les évalue par ordre de priorité à chaque exécution, et l'effet le plus restrictif l'emporte toujours : deny prime sur require_approval, qui prime sur allow. Comme les règles sont des données, vos équipes risque et conformité les rédigent et les modifient directement — et chaque modification est testable avant d'atteindre le moindre agent.
Chaque règle est une condition (p. ex. amountUsd >= 5000) associée à un effet — allow, deny ou require_approval — et à une priorité. Aucun redéploiement : les règles sont des données cadrées par tenant que le runtime lit à chaque exécution.
Les règles s'appliquent par ordre de priorité, les règles désactivées sont ignorées, et l'effet correspondant le plus strict l'emporte : deny > require_approval > allow. La gouvernance penche par défaut vers la prudence, jamais vers l'autorisation.
Passez n'importe quel contexte dans les règles en vigueur — ou dans un jeu candidat non enregistré — et obtenez la décision plus une trace règle par règle : vous voyez exactement quelle règle s'est déclenchée et pourquoi, avant d'enregistrer.
Les tests de politique de référence figent les décisions qui doivent tenir. Exécutez-les sur un jeu de règles candidat : un seul échec vous dit de ne pas livrer — une barrière anti-régression pour la gouvernance elle-même.
Quand la gouvernance se disperse dans des instructions if et du texte de prompt, une modification bien intentionnée peut élargir en silence ce que chaque agent a le droit de faire — et vous ne le découvrez qu'à l'audit. Policy-as-Code transforme les règles en données explicites, vous permet de prévisualiser une décision avant sa mise en production et refuse tout changement qui casse ne serait-ce qu'un cas golden. Le même moteur alimente la décision en production et la simulation : ce que vous testez est exactement ce qui s'exécute.
Un seul moteur pur — evaluateRules(rules, context) — décide de chaque exécution et de chaque simulation. C'est ce chemin partagé qui rend une simulation digne de confiance : l'aperçu et la décision de production sont le même code.
Écrivez une condition et un effet — allow, deny ou require_approval — avec une priorité. Les priorités les plus basses sont évaluées en premier ; les règles désactivées sont ignorées. Les règles sont des données cadrées par tenant, pas un déploiement.
Envoyez un POST de contexte sur /simulate, contre les règles en vigueur ou un jeu candidat non enregistré. Vous obtenez l'effet, la règle correspondante, le motif et la trace complète règle par règle — un aperçu du changement avant qu'il soit réel.
Figez les cas connus en tests de référence (contexte → effet attendu). Exécutez-les sur le jeu de règles candidat ; un seul échec signale une régression — ne livrez pas.
Une fois le jeu candidat validé, il devient la politique en vigueur — évaluée à chaque exécution dans le même runtime fail-closed, aux côtés de l'identité, du budget et du Trust Ledger.
Épinglez une règle require_approval à amountUsd >= 5000, puis simulez. Un versement de $7,400 renvoie require_approval, avec la règle correspondante et le motif dans la trace ; un versement de $100 renvoie allow, car aucune règle n'a correspondu. Aucune supposition : la simulation exécute exactement le moteur qui filtre la production.
Envoyez un jeu de règles candidat à /tests/run et Cortex évalue chaque cas de référence sans rien enregistrer. Un candidat naïf en deny-all échouerait sur les cas qui attendent allow — la porte vous dit donc de ne pas le livrer. Figez une fois pour toutes les décisions qui comptent, et aucune modification ultérieure ne pourra les changer en silence ; l'endpoint run est la porte manuelle que vous déclenchez à chaque changement.
Policy-as-Code n'est qu'une porte parmi d'autres dans le même runtime fail-closed que l'identité, les actions, la supervision et le registre. Suivez les branches.
Quand une règle renvoie require_approval, l'action arrive dans la boîte d'approbation — pending_approval jusqu'à validation par un admin, jamais exécutée automatiquement.
Les cinq modes d'autonomie définissent ce qu'un agent peut exécuter seul — et la barrière de risque est un plancher que la politique peut resserrer, jamais relâcher.
Chaque décision de politique est consignée dans une piste d'audit chaînée par hachage, où toute altération est détectable, avec des reçus signés vérifiables hors ligne.
Les agents sont des identités gouvernées dont les modèles et les actions sont sur liste d'autorisation — la politique décide par exécution, l'identité décide par agent.
Les permissions d'objet, de propriété et d'action donnent aux conditions de politique un vrai sens métier à évaluer, pas seulement des champs bruts.
Les compteurs de règles et de tests en direct apparaissent en KPI et en lignes CSV — surveillez et exportez l'état de votre parc de politiques au même endroit.
Évaluation en refus par défaut, priorité au plus restrictif, modifications de règles réservées aux administrateurs et trace règle par règle sur chaque décision — mis en correspondance avec les référentiels que vos auditeurs utilisent déjà.
Traduisez la gouvernance de vos agents en politique testable et simulable — pour qu'une modification de règle ne change jamais en silence ce que vos agents ont le droit de faire.