suggest_only
- L'agent ne peut que proposer des actions
- Chaque action reste en attente d'un humain
- Aucune exécution autonome
Supervision humaine
Réglez l'autonomie de vos agents — avec un plancher de risque infranchissable.
Définissez jusqu'où chaque agent peut agir seul, de suggest_only à autonomous. La politique de risque propre à l'action reste toujours un plancher : la supervision ne peut que durcir une décision, jamais l'assouplir — et chaque dérogation est un break-glass audité.
oversight ▸ agent → valeur par défaut du tenant → valeur par défaut de la plateforme (execute_low_risk)
Modes de supervision
oversight ▸ la porte de risque est un plancher — l'autonomie ne peut que la resserrer
Le problème
« Autonomous » et « sans intervention » ne sont pas le même réglage.
La plupart des équipes traitent l'autonomie des agents comme un simple interrupteur — soit un humain approuve tout (et l'agent ne sert à rien), soit l'agent agit librement (et personne n'est responsable). Cortex en fait un curseur explicite, propre à chaque agent et auditable, résolu selon agent → valeur par défaut du tenant → valeur par défaut de la plateforme, avec la politique de risque de l'action comme plancher intangible.
decideApproval(action, mode) matrice de décision pure, testée
Les cinq modes de supervision
Un seul curseur, cinq crans — de la simple proposition à la pleine autonomie.
Chaque mode se définit par agent (ou comme valeur par défaut du tenant / de la plateforme). L'exécution d'agent qu'il gouverne est l'acteur machine ; la file d'approbation humaine vers laquelle il aiguille est la surface applicative/humaine.
draft
- L'agent rédige l'action et ses preuves
- Toutes les propositions restent en attente
- Le relecteur approuve le travail déjà préparé
execute_low_risk
- Les actions à faible risque s'exécutent automatiquement
- Les risques moyen et élevé restent en attente
- Défaut de la plateforme si rien n'est défini
execute_with_review
- Faible et moyen s'exécutent (marqués reviewRequired)
- Le risque élevé reste en attente
- Relecture a posteriori, sans blocage
autonomous
- Exécute tout ce que la politique autorise
- Seul le plancher propre à l'action reste en attente
- N'outrepasse jamais requiresApproval
Ordre de résolution
- Le mode propre à l'agent prime d'abord
- Sinon, le défaut du tenant s'applique
- Sinon, le défaut de la plateforme : execute_low_risk
Le verrou de risque est un plancher
La supervision peut durcir une décision — jamais l'assouplir.
Chaque action porte son propre niveau de risque et un verrou requiresApproval. Ce verrou est le plancher. Quelle que soit la position du curseur d'autonomie, une action à haut risque ou soumise à approbation atterrit toujours dans la boîte d'approbation humaine. Passer un agent en autonomous supprime les contrôles humains optionnels — jamais le contrôle obligatoire.
- Le verrou requiresApproval de l'action met toujours en attente, dans tous les modes
- La supervision s'applique au moment du propose(), dans l'Action Fabric
- Les décisions émettent un indicateur reviewRequired pour la relecture a posteriori
Action Fabric
Simulation›
Remboursement de 240 $
risque: faible · preuve
Proposée›
Clore le dossier #4471
risque: moyen · preuve
En attente d'approbation›
Paiement de 5 000 $
risque: élevé · preuve
Exécutée
Envoyer un e-mail au client
risque: faible · preuve
actions ▸ simulation → proposition → approbation → exécution → compensation
Comment une proposition est tranchée
D'une action proposée à l'exécution — ou à la mise en attente.
Lorsqu'un agent propose une action, Cortex résout le mode de supervision de l'agent à l'origine de la proposition et applique la fonction pure decideApproval(action, mode), par-dessus le plancher de risque propre à l'action.
- 01
L'agent propose
Un acteur machine propose une action via l'Action Fabric, avec son niveau de risque et son indicateur requiresApproval.
- 02
Résoudre le mode
Cortex résout le mode de supervision de l'agent : spécifique à l'agent → défaut du tenant → défaut de la plateforme (execute_low_risk).
- 03
Décider
decideApproval applique le mode par rapport au plancher — exécution automatique, exécution avec reviewRequired, ou pending_approval.
- 04
Router et consigner
Les actions retenues rejoignent la boîte d'approbation humaine ; chaque décision (et decidedBy) est consignée dans le registre d'audit.
Break-glass audité
Une dérogation d'urgence qui laisse une trace permanente.
Il arrive qu'une action en attente doive s'exécuter immédiatement — un incident, une échéance, un dossier bloqué. Le break-glass force l'exécution d'une invocation pending_approval, mais uniquement pour un administrateur de la plateforme, et uniquement avec un motif écrit obligatoire qui rejoint la piste d'audit.
Réservé aux admins
- POST /v1/actions/:id/break-glass
- Nécessite une session d'administrateur de plateforme (AdminGuard)
- Définir les modes est également réservé aux administrateurs ; les lectures restent limitées au tenant
Motif obligatoire
- Un motif écrit est obligatoire — aucune dérogation silencieuse
- Consigne decisionReason="break-glass: …"
- Consigne decidedBy — qui a actionné le levier
Prouvable
- Émet un événement ActionBreakGlass
- Alimente le Trust Ledger, où toute altération est détectable
- Chaque dérogation est rejouable pour un auditeur
pending_approvalbreak-glass · exécuté
Fonctionne avec le reste du runtime
La supervision est un verrou parmi d'autres dans un pipeline fail-closed.
Le curseur d'autonomie s'appuie sur l'identité, la politique et le cycle de vie des actions — et tout ce qu'il décide est consigné à des fins d'observation et de preuve.
Action Fabric
Là où les propositions deviennent des actions gouvernées — dry-run → propose → approve → execute → compensate. La supervision s'applique au moment de la proposition.
Policy-as-Code
Rédigez les règles allow / deny / require_approval qui fixent le plancher de risque de chaque action, avant même que le curseur ne s'applique.
Agent IAM
Chaque agent est une identité avec un responsable et un niveau de risque — le sujet dont le mode de supervision est résolu au moment de la proposition.
Trust Ledger
Chaque approbation, refus et dérogation break-glass est consigné dans un registre chaîné par hachage, où toute altération est détectable, que vous pouvez remettre à un auditeur.
Control Tower
Surveillez la file d'approbation en direct sur toute la flotte — et mettez tout en pause depuis un seul écran quand il le faut.
Observabilité
Notez, rejouez et déboguez chaque exécution — y compris les actions reviewRequired exécutées sans approbation bloquante.
Sécurité et conformité
Une supervision que vos auditeurs peuvent valider.
Changements de mode réservés aux administrateurs, motifs de break-glass obligatoires et enregistrement immuable de chaque décision — aligné sur les attentes en matière de supervision humaine des référentiels que vos évaluateurs utilisent déjà.
EU AI ActNIST AI RMFISO 42001SOC 2FINRAGDPR
Donnez à chaque agent exactement la marge que vous avez décidée.
Réglez le curseur par agent, gardez le plancher non négociable et prouvez chaque dérogation — sans ralentir votre équipe.