Gouvernance : lecture d'abord et fermé par défaut

La gouvernance dans Olivares AI repose sur deux principes que vous pouvez garder en tête simultanément : observer avant d’appliquer, et quand vous appliquez, refuser par défaut. Le produit cartographie et audite ce que chaque agent peut atteindre bien avant de contrôler une seule action, et les contrôles qu’il exerce sont fermés par défaut.

Lecture d’abord : observation avant application

La posture par défaut de la plateforme est détective, pas préventive. Elle construit la carte d’accès lecture/écriture en ingérant les logs, OpenTelemetry et l’audit natif hors bande — elle n’est jamais dans le chemin de données de l’agent, de sorte qu’un collecteur qui échoue ne peut pas faire tomber la production. À partir de cette carte, elle compare le permis à l’observé et remonte la dérive pour qu’un humain la juge.

Cela compte pour la lecture du reste de cette page. Le produit observe et gouverne largement ; il n’actionne pas largement. Là où il peut prendre une action sur votre infrastructure, cette capacité est l’une de ces trois choses, et le catalogue de modules indique laquelle :

• live — câblé et actif aujourd’hui (un ensemble restreint) ;
• on-demand — le backend est construit et câblé à un point d’injection mais reste fermé par défaut ou dégradé jusqu’à ce que vous le provisionniez (un exécuteur, un dispatcher, un identifiant d’inférence) ;
• seam — une interface déclarée et fermée par défaut, sans backend dans le binaire par défaut.

Ainsi, une absence d’application est généralement intentionnelle, pas un oubli. Lecture d’abord signifie que le comportement par défaut honnête est de surveiller et enregistrer, et de ne contrôler que les surfaces que vous avez explicitement activées.

Le modèle d’autorisation dans lequel vous gouvernez

Chaque décision gouvernée passe par le même noyau d’autorisation qui protège le reste de l’API. Trois propriétés méritent d’être intériorisées avant de modifier quoi que ce soit.

Le RBAC est fermé par défaut. Un principal sans appartenance à un tenant est refusé — il n’y a pas d’autorisation implicite. Les permissions sont scopées au tenant, et un handler n’agit que sur le seul tenant résolu par la requête, ce qui ferme les classes confused-deputy et IDOR par construction. Les rôles forment une échelle : viewer lit, editor écrit, admin gère l’IAM du tenant, owner détient tout. La lecture du graphe d’accès est délibérément un privilège editor et au-dessus — une carte complète de ce que chaque agent peut toucher est une feuille de route de reconnaissance — et chaque lecture est inscrite dans le registre d’audit.

Le point de politique ne fait que restreindre. Au-dessus du RBAC, vous pouvez câbler un point de décision de politique basé sur les attributs. La composition est une intersection — RBAC ∩ ABAC natif ∩ PDP externe — de sorte qu’une politique ne peut que restreindre davantage ce que le RBAC a déjà autorisé ; elle ne peut jamais élargir une autorisation. Ceci est appliqué, pas une convention. Vous choisissez au plus un moteur externe :

# Cedar embarqué (pure-Go, pas de sidecar) ou OPA via HTTP. Par défaut : aucun.
OLIVARES_PDP_ENGINE=cedar   # ou : opa | none

Avec Cedar, vous rédigez des règles forbid ; un ensemble de règles vide laisse la décision RBAC en l’état. Avec OPA, votre Rego doit être permissif par défaut, où un résultat manquant ou toute erreur de transport échoue en fermé. Une configuration PDP invalide ne désactive que le PDP externe et journalise le fait — l’ABAC natif et le RBAC continuent de gouverner, et un moteur mal configuré ne laisse jamais une requête non gouvernée. Chaque restriction appliquée par le PDP est auditée.

Niveaux de risque et plancher de double contrôle

Les actions qui atteignent la file d’approbation sont classées en quatre niveaux de risque — low, medium, high, critical — selon la taxonomie OWASP pour les agents IA. (C’est un axe distinct des niveaux de conformité de l’AI Act européen ; ne les confondez pas.) Le niveau est re-dérivé de la politique en vigueur à chaque décision de sécurité, jamais lu depuis un instantané stocké, de sorte qu’un changement de politique prend effet immédiatement et qu’une ligne périmée ne peut jamais maintenir la barre plus bas que la classification actuelle.

Une action critical comporte un plancher obligatoire à deux personnes : au moins deux approbateurs humains distincts, conformément à l’autorisation duale NIST SP 800-53 AC-3(2). Le plancher est appliqué deux fois — à la création (le seuil stocké ne peut jamais démarrer en dessous) et re-dérivé à la décision (une ligne dégradée ou historique ne peut toujours pas passer avec un seul approbateur) — de sorte que même une politique opérateur qui abaisse explicitement le niveau ne peut pas rendre une action critique unipersonnelle. L’ensemble critique intégré est la famille irréversible, structurante pour l’environnement : déploiement et retrait en production, suppression de données, changements d’application de sécurité, garde et rotation de clés, et réactivation de l’environnement après un coupe-circuit.

Les niveaux inférieurs ne changent pas la mécanique du moteur — une approbation qui existe déjà exige au moins un humain — ce sont le vocabulaire sur lequel d’autres contrôles s’appuient (par exemple, renforcer l’authentification sur une action critique).

Le contrôle d’approbation humain-dans-la-boucle

Là où le produit contrôle une action, la boucle est : une surface présente (dérive de la carte d’accès, une découverte du module de sécurité) → un opérateur autorisé décide → la décision est enregistrée dans le registre d’audit. Le moteur d’approbation qui sous-tend cela est réel aujourd’hui : une requête s’ouvre fermée par défaut, liée à un hash de plan, et limitée dans le temps. Les invariants sont appliqués côté serveur, indexés sur l’identité stable de l’utilisateur (un token système n’a pas d’identité et ne peut pas décider) :

• Séparation des fonctions — le demandeur ne peut jamais décider sa propre requête.
• Garde anti-doublon — un humain ne compte qu’une fois vers un seuil.
• Expiration — dérivée à la lecture, de sorte qu’une requête expirée ne peut jamais être liée, même avant qu’un balayage ne matérialise son expiration.

Ce qui mûrit encore est la console de revue opérateur plus riche ; les endpoints et le moteur sont livrés aujourd’hui. Le guide Gouverner et approuver détaille le flux en direct.

La dépendance qui rend tout cela crédible est l’identité par agent. L’audit attribue l’activité à un identifiant, pas intrinsèquement à un agent ; un compte de service partagé réduit l’attribution au niveau de l’identité — remonté honnêtement comme une découverte, jamais silencieusement récupéré. Voir permis vs observé et fidélité pour ce que cela fait au signal sur lequel vous gouvernez.

Break-glass : la soupape de secours auditée

Le double contrôle nécessite une soupape de secours pour l’incident de 3 heures du matin où un approbateur est injoignable. Le break-glass est cette soupape, et il est bruyant par construction. L’activation est de niveau admin et exige un vrai humain (un token système est refusé), un step-up vérifié par matériel (AAL3), une justification écrite, et une session activement enregistrée comme précondition. L’autorisation est limitée dans le temps — une heure par défaut, plafond dur d’un jour — et une autorisation expirée ne peut rien autoriser.

Tant qu’une autorisation est active, une action dans son périmètre peut procéder sans son quorum d’approbation, mais chaque utilisation est ajoutée à une piste immuable et au registre d’audit, nommant l’autorisation, l’action et le sujet — une action qui a procédé sous break-glass est définitivement distinguable d’une action approuvée. Une revue post-mortem obligatoire ferme la boucle : 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.

Le coupe-circuit : le contrôle de refus à l’échelle de l’environnement

Le coupe-circuit est l’arrêt d’urgence en un clic, et il inverse délibérément l’ergonomie habituelle. L’engagement est délibérément peu coûteux — niveau admin, une raison obligatoire, pas de quorum d’approbation, pas de step-up, pas de break-glass — parce qu’un arrêt qui attend le consensus n’est pas un arrêt. Le niveau d’assurance de la session d’engagement est enregistré pour l’analyse post-mortem ; un abus de l’engagement ne coûte que de la disponibilité, ce qui est la direction sûre.

La ligne d’arrêt est la source unique de vérité. Chaque contrôle d’actionnement gouverné la consulte en direct à chaque action et échoue en fermé en cas d’erreur de lecture — l’exact inverse du contrat fail-open des contrôles budgétaires, car un état d’arrêt illisible ne doit jamais signifier « continuez ». L’engagement révoque aussi le travail en file d’attente que les contrôles ne peuvent pas atteindre : chaque approbation d’actionnement en attente dans le périmètre est annulée dans la même transaction, de sorte qu’une intention pré-arrêt ne peut pas mûrir en une autorisation qui se déclenche au moment où l’environnement revient. Les actions de gouvernance elles-mêmes sont exemptées — l’arrêt stoppe l’environnement agentique, jamais les contrôles qui le gouvernent.

La réactivation n’est jamais unilatérale. Elle est conditionnée à une nouvelle approbation de double contrôle (le plancher critical à deux humains distincts, structurellement re-vérifié au moment du basculement pour qu’une politique dégradée ne puisse pas le rendre unipersonnel), et il n’y a délibérément pas de chemin break-glass pour la réactivation : « l’environnement reste arrêté » est l’état sûr. Une revue post-mortem obligatoire par un humain non impliqué clôt l’incident.

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 (le graphe d’accès, le registre lui-même) s’auto-auditent dans une écriture validée. Le registre est append-only et chaîné par hash, chaque enregistrement portant les champs d’intégrité de chaîne, de sorte que réécrire l’historique est détectable et il ne contient jamais de données personnelles. Vous ne pouvez pas effectuer un changement non gouverné que le registre oublierait silencieusement.

Voir aussi

• Permis vs observé — la dérive sur laquelle ces décisions agissent.
• Fidélité — le niveau de confiance du signal sous-jacent à une décision.
• Gouverner et approuver — le flux d’approbation en direct, étape par étape.
• Coupe-circuit — le contrôle de refus à l’échelle de l’environnement en termes produit.
• Transparence et limites — la posture fermée par défaut et détective par défaut dans son intégralité.