Nommée et enregistrée
Chaque action — refund.issue, payout.send, close.case — est une entrée de registre dotée d'une clé, d'un schéma d'entrée (clés requises), d'un riskLevel et d'un indicateur requiresApproval.
Action Fabric
Laissez vos agents agir pour de vrai — sans prendre de vrais risques.
Chaque action qu'un agent peut entreprendre est un objet gouverné de premier ordre : une action nommée, dotée d'un niveau de risque et d'une politique d'approbation, plus un registre d'invocations immuable qui consigne dry-run → propose → approve/deny → execute → compensate avec un dossier de preuves à chaque étape.
dry-run → propose → approve/deny → execute → compensate · refus par défaut
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
Les actions comme objets gouvernés
Un appel d'outil, c'est un souhait. Une action gouvernée engage une responsabilité.
Les agents non gouvernés appellent les outils directement — sans niveau de risque, sans approbation, sans trace de ce qui a été exécuté ni de la façon de l'annuler. Dans Cortex, chaque action est enregistrée avec un niveau de risque et une politique d'approbation, et chaque invocation aboutit dans un registre en ajout seul. Les actions à risque élevé ou soumises à approbation ne s'exécutent jamais avant qu'un administrateur ne les approuve ; les actions refusées ne s'exécutent jamais du tout.
Par niveau de risque
riskLevel: high ou requiresApproval oriente l'invocation vers pending_approval ; les actions à faible risque s'exécutent immédiatement. Le risque est une propriété de l'action, pas un espoir.
Journalisation immuable
Chaque dry-run, proposition, approbation, refus, exécution et compensation s'ajoute à cortex_action_invocations — une piste de preuves que vous pouvez remettre à un auditeur.
Réversible
Déclarez un rollbackKey et toute action exécutée devient compensable — le runtime lance l'action de compensation et marque l'originale compensated.
Le problème résolu
Dès qu'un agent peut écrire, votre exposition change.
Les agents en lecture seule sont faciles. Le risque apparaît quand un agent émet un remboursement, clôture un dossier ou envoie un versement. Sans une fabric entre l'intention et l'effet, vous confiez des effets de bord à un modèle — aucune porte d'approbation pour le versement de 5 000 $, aucune trace de ce qui s'est exécuté, aucun moyen de revenir en arrière. Action Fabric place une couche de gouvernance en refus par défaut entre la proposition et l'effet de bord.
Les actions à haut risque arrivent en pending_approval — jamais d'exécution automatiquedeny → enregistré comme denied, l'exécuteur n'est jamais appelécompensate → un rollbackKey déclaré annule une action exécutée
Le cycle de vie
De la proposition à l'effet prouvable — et retour.
Chaque invocation parcourt le même cycle de vie à cinq états. Chaque transition s'ajoute au registre avec son dossier de preuves : l'histoire complète de tout effet de bord est donc reconstituable après coup.
- 01
Dry-run
Validez l'entrée par rapport au schéma de clés requises de l'action. Aucun effet de bord n'est déclenché — c'est une répétition sans risque qui prouve que l'appel est bien formé avant que quoi que ce soit ne se produise.
- 02
Propose
Soumettez l'action pour de vrai. Les actions riskLevel: high ou requiresApproval arrivent en pending_approval ; tout le reste s'exécute immédiatement sous le contrôle des politiques.
- 03
Approve / Deny
Réservé aux administrateurs, protégé par AdminGuard. L'approbation déclenche l'exécuteur gouverné ; deny enregistre denied avec un motif et l'exécuteur n'est jamais appelé.
- 04
Execute
L'exécuteur gouverné émet ActionExecuted ou ActionFailed (événements P4). La règle d'adaptateur P7 empêche les mocks d'atteindre la production, sauf autorisation explicite.
- 05
Compensate
Réservé aux administrateurs. Si l'action déclare un rollbackKey, le runtime lance l'action de compensation et marque l'originale compensated — une annulation propre et auditée.
Provenance
Chaque action remonte à celui qui l'a demandée.
Ce que contient Action Fabric
Référentiel, registre, exécuteur, et les portes de contrôle entre eux.
Registre des actions
- Clés d'action nommées
- Schéma d'entrée (clés obligatoires)
- riskLevel: low / med / high
- Indicateur requiresApproval
- rollbackKey optionnel
Journal des invocations
- Invocations en ajout seul
- Dossier de preuves par étape
- États dry-run → … → compensate
- Lectures cadrées par tenant
- Piste à remettre telle quelle à un auditeur
Boîte d'approbation
- File pending_approval
- approve / deny réservés aux administrateurs
- Motif du refus consigné
- AdminGuard appliqué
- Tenant issu du principal
Exécuteur gouverné
- Déterministe par défaut
- ActionExecuted / ActionFailed (P4)
- Règle des adaptateurs P7
- Driver réel derrière ACTION_EXECUTOR_MODE
- Aucun système réel sans activation
Périmètre ontologique
- objectId optionnel sur propose
- Résout le type de l'objet
- Application des actions autorisées
- 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- Objet et type consignés dans les preuves
Compensation
- Déclaration d'un rollbackKey
- Exécution de l'action compensatoire
- L'action d'origine passe à compensated
- Annulation auditée, réservée aux administrateurs
- Effets de bord réversibles
Prouvez-le — ne vous contentez pas de l'affirmer
Le refus est la règle par défaut. Le registre fait office de reçu.
Voyez la même fabric traiter six résultats sans fard — une exécution propre, une mise en attente pour risque élevé, un refus administrateur qui ne s'exécute jamais, un retour arrière compensé et une action cadrée par l'ontologie bloquée d'emblée. Chaque ligne est une entrée de registre en ajout seul, avec son propre dossier de preuves.
- Action à haut risque → pending_approval jusqu'à l'approbation d'un administrateur
- Action refusée → consignée comme denied, l'exécuteur n'est jamais appelé
- Type d'objet incorrect → 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- Action exécutée avec un rollbackKey → proprement compensated
Registre des invocations
dry-run
refund.issue · input { amount: 240 } · schema ok
validpropose
payout.send · riskLevel: high → pending_approval
pending_approvalapprove
payout.send · admin: risk-ops@northwind → executed
executeddeny
close.case · reason: nécessite une revue par l'expert
denied · jamais exécutéeexecute
email.customer · riskLevel: low → ActionExecuted (P4)
executedcompensate
refund.issue · rollbackKey → refund.void → compensated
compensatedpropose
delete.record · objectId: Claim/4471
403 ACTION_NOT_PERMITTED_FOR_OBJECTactions ▸ ajout seul · dossier de preuves à chaque étape · approve / deny / compensate réservés aux administrateurs
5États du cycle de vie sur chaque invocation
100%Des invocations consignées au journal
403ACTION_NOT_PERMITTED_FOR_OBJECT en cas de type incorrect
0Actions refusées atteignant l'exécuteur
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
Actions cadrées par l'ontologie
Une action n'est permise que sur les objets qu'elle a le droit de toucher.
Transmettez un objectId lors du propose : le runtime résout le type de l'objet d'ontologie et applique actionPermittedForObject(allowedActions, key). Une liste d'autorisations vide sur le type permet n'importe quelle action ; une liste non vide doit contenir la clé de l'action, faute de quoi la proposition est bloquée. L'objet et son type sont inscrits dans les preuves de l'invocation, et la vérification échoue en mode ouvert (avec journalisation) si ontology-service est injoignable, pour que la gouvernance ne devienne jamais une panne.
- allowedActions vide sur un type → toute action est permise
- Une liste non vide doit contenir la clé de l'action, sinon l'action est refusée
- Code de blocage : 403 ACTION_NOT_PERMITTED_FOR_OBJECT
- Consigné dans evidence.ontologyObject pour la piste d'audit
Fonctionne avec le reste du runtime
Les actions ne se gouvernent pas elles-mêmes — la plateforme s'en charge.
Action Fabric s'inscrit dans le même runtime en refus par défaut que l'identité, la politique, la supervision et le registre. Suivez les branches.
Policy-as-Code
Rédigez des règles allow / deny / require_approval — par ex. amountUsd ≥ 5000 → require_approval — et simulez-les avant leur mise en production.
Modes de supervision
Les cinq modes d'autonomie déterminent ce qu'un agent peut exécuter seul — la barrière de risque est un plancher que la supervision ne peut que resserrer.
Trust Ledger
Chaque action exécutée est chaînée par hachage dans une piste d'audit détectant toute altération, avec des reçus signés vérifiables hors ligne.
Ontologie
Les permissions d'objet, de propriété et d'action donnent aux actions une signification métier gouvernée — ainsi que le cadrage par objectId ci-dessus.
Agent IAM
Les agents sont des identités gouvernées dotées d'actions en liste d'autorisation — un agent ne peut proposer que les actions permises par son identité.
Control Tower
Suivez chaque invocation d'action en direct, mettez une flotte d'agents en pause et exportez un rapport de gouvernance en un clic.
Sécurité et conformité
Conçu pour la revue de sécurité en entreprise.
Approbations réservées aux administrateurs, exécution en refus par défaut, preuves en ajout seul et la règle d'adaptateur P7 qui empêche les mocks d'atteindre la production — mis en correspondance avec les référentiels que vos auditeurs utilisent déjà.
SOC 2ISO 27001ISO 42001HIPAAGDPREU AI ActNIST AI RMFFINRA
Donnez des mains à vos agents — et une laisse.
Placez chaque action d'agent sous un cycle de vie gouverné : dry-run, approbation, exécution, retour arrière et preuves complètes à chaque étape.