Une fois qu’une source est connectée et que la carte d’accès montre ce que chaque agent peut lire et écrire, la tâche suivante est de le gouverner : décider qui et quoi peut agir, et faire de chaque décision un fait enregistré. Cette page couvre le workflow d’approbation — niveaux de risque, double contrôle, break-glass, et le registre sur lequel ils s’ancrent tous.
La gouvernance est fermée par défaut. Un principal sans rôle dans un tenant est refusé ; il n’y a pas d’autorisation implicite. Le produit observe largement mais n’actionne pas largement — là où il gouverne une action, il le fait fermé par défaut, jamais en tant qu’exécuteur généraliste.
Le modèle d’autorisation
Chaque appel de gouvernance passe par le même noyau d’autorisation que le reste de l’API : RBAC d’abord, scopé à un seul tenant, avec une couche de politique externe optionnelle au-dessus.
Les rôles forment une échelle — viewer (lecture), editor (écriture), admin (IAM du tenant), owner (tout dans le tenant). La lecture de la carte d’accès n’est délibérément pas le niveau le plus bas : une carte de ce que chaque agent peut toucher est une feuille de route de reconnaissance, elle est donc accordée à partir de editor et au-dessus, scopée au tenant, et chaque lecture est inscrite dans le registre.
Un point de décision de politique optionnel (Cedar embarqué, ou OPA via HTTP) peut superposer des règles basées sur les attributs. Il se compose comme une intersection — RBAC ∩ ABAC natif ∩ PDP externe — et a un invariant :
La couche de politique ne peut que retirer l’accès, jamais l’ajouter. Une politique peut refuser quelque chose que le RBAC aurait autorisé ; elle ne peut jamais accorder quelque chose que le RBAC refuse. Un PDP mal configuré ou inaccessible échoue en fermé, et désactiver le PDP externe ne laisse jamais les requêtes non gouvernées — le RBAC et l’ABAC natifs continuent de gouverner.
Niveaux de risque
Une action gouvernée est classée en l’un des quatre niveaux — low, medium, high, critical — dérivés de la taxonomie de risque OWASP pour les agents IA. Le niveau détermine combien de contrôle humain l’action requiert avant de pouvoir procéder.
Le niveau n’est pas stocké sur la ligne d’approbation. Il est re-dérivé de l’ensemble des politiques actuelles plus un défaut intégré à chaque décision, de sorte qu’un changement de politique prend effet immédiatement et qu’un instantané périmé ne peut jamais maintenir la barre en dessous de la classification en vigueur (fermé par défaut).
| Niveau | Contrôle par défaut |
|---|---|
low / medium | assigné uniquement par politique explicite |
high | le défaut pour tout ce qui atteint la file d’approbation — une approbation humaine |
critical | un plancher obligatoire à deux personnes (voir ci-dessous) |
L’ensemble critical intégré couvre les actions véritablement irréversibles : déploiement et retrait en production, suppression et effacement de données, changements d’application de sécurité et du coupe-circuit, garde et rotation de clés, et décommissionnement de NHI. Une politique d’approbation avec un risk_tier explicite peut augmenter ou diminuer le défaut par action — c’est la parole auditée de l’opérateur — mais elle ne peut jamais abaisser une action critical en dessous du plancher de double contrôle.
Requêtes d’approbation et double contrôle
Une requête d’approbation s’ouvre fermée par défaut et limitée dans le temps : elle démarre pending, porte une expiration, et n’autorise rien tant que suffisamment d’humains ne l’ont pas décidée. Une politique d’approbation correspondante fait autorité pour le seuil et les délais, un demandeur ne peut donc jamais abaisser sa propre barre.
Trois invariants sont appliqués côté serveur, pas par convention :
- Séparation des fonctions. Le demandeur ne peut pas décider sa propre requête. Cela s’indexe sur l’identité stable de l’utilisateur, pas sur la chaîne d’identifiant qu’une même personne pourrait varier.
- Une décision par humain. Un index unique backstoppe une course de décideur dupliqué ; la même personne ne peut pas compter deux fois vers le seuil.
- Expiration contraignante. Une requête expirée ne peut jamais recevoir de décision contraignante — le statut effectif est re-dérivé à chaque décision, balayage ou pas.
Pour les actions critical, le seuil est planché à deux approbateurs humains distincts (autorisation duale NIST SP 800-53 AC-3(2)). Le plancher est appliqué à la création de la requête (le seuil stocké ne peut jamais démarrer en dessous de deux) et re-appliqué au moment de la décision (une requête créée avant que l’action ne devienne critique ne peut toujours pas passer avec un seul humain). Un seul approbateur ne peut jamais satisfaire une action critique.
Une décision critical requiert en outre une session vérifiée par matériel : l’humain décideur doit avoir un step-up WebAuthn ou PIV frais (AAL3). Un token système ne porte aucune assurance humaine et est refusé — un token système ne peut pas approuver.
Chaque décision ajoute une ligne immuable au parcours de décision de la requête et un événement de registre enregistrant la décision, le statut résultant, et le niveau de risque sous lequel elle a été prise.
Break-glass
Le double contrôle a une soupape de secours pour l’incident de 3 heures du matin où le second approbateur est injoignable. Un admin — toujours un vrai humain, jamais un token système — active une autorisation d’urgence limitée dans le temps qui permet à une action contrôlée de procéder sans son quorum. Le chemin n’est jamais silencieux :
- L’activation requiert une justification, s’auto-audite dans le registre dans la même transaction, et émet une découverte critique vers le rail de notification.
- Chaque utilisation ajoute une ligne immuable et un événement de registre nommant l’autorisation, l’action et le sujet. Une action qui a procédé sous break-glass est définitivement distinguable d’une action correctement approuvée.
- L’autorisation est limitée dans le temps — une heure par défaut, plafonnée à 24. Une « urgence » qui nécessite plus longtemps est un mode opératoire, pas une urgence, et doit passer par le double contrôle normal.
- Revue post-mortem obligatoire. Une nouvelle autorisation ne peut pas être activée tant qu’une précédente est non révisée, et la revue doit provenir d’un humain différent de l’activateur. Vous ne pouvez pas empiler les urgences pour esquiver l’examen.
Le break-glass assouplit un quorum manquant ; il ne surpasse jamais un rejet humain explicite. Une requête que quelqu’un a délibérément refusée reste refusée.
La garantie des décisions enregistrées
Quelle que soit la profondeur du workflow au-dessus, une décision de gouvernance est un fait enregistré. Les actions mutantes sont ajoutées au registre d’audit avec l’acteur réel dans la même transaction que le changement, et les lectures sensibles (la carte d’accès, le registre lui-même) s’auto-auditent dans une écriture validée. Vous ne pouvez pas effectuer un changement non gouverné que le registre oublierait silencieusement.
Le registre est append-only, chaîné par hash, et signé Ed25519. Chaque enregistrement porte seq, prev_hash, hash et sig, de sorte que réécrire l’historique est cryptographiquement détectable, et le registre ne contient jamais de données personnelles. Pour la copie externe et immuable qu’un auditeur demande, le registre est exposé comme un export pull authentifié à /v1/audit/export, avec les valeurs de format cef, leef, syslog, otlp et ocsf. Chaque enregistrement exporté porte les champs d’intégrité de chaîne, de sorte qu’un SIEM ou un store WORM peut re-vérifier la chaîne hors ligne — la signature détachée se défend contre une compromission de base de données seule, et la copie hors-boîte contre un hôte totalement compromis.
Périmètre honnête
Le noyau d’autorisation, le moteur d’approbation et le registre fonctionnent aujourd’hui. Ce qui mûrit encore est la surface de revue opérateur plus riche — une console complète de file d’approbation ; les endpoints et les invariants côté serveur sont livrés, l’interface polie est le chemin à suivre. Comme le reste de la plateforme, c’est un open core pré-1.0 : lisez Transparence et limites pour ce qui est actif versus en conception. Olivares AI est conçu en vue de SOC 2, ISO 27001 et les contrôles de l’AI Act européen, pas certifié contre eux.
Voir aussi
- Gouvernance — le modèle d’autorisation et la posture d’auto-audit dans son intégralité.
- Permis vs observé — la dérive sur laquelle ces décisions agissent.
- Connecter une source — câbler les signaux à partir desquels la dérive est construite.
- Coupe-circuit — l’arrêt d’urgence gradué pour l’environnement.