Référence des AIP

Utilisez cette page pour lire ou relire une Agent Intent Policy (AIP) : de quoi elle est faite, quelle dimension de l’Autonomy Zone elle couvre, dans quel mode elle s’exécute et quel verdict elle rend pour une action couverte.

Une politique d’intention énonce ce que veut dire votre organisation, plutôt que chaque surface qu’un agent pourrait utiliser. OpenLatch écrit chaque politique d’intention sous forme d’AIP et la compile en règles déterministes que le client applique avant l’exécution de l’action.

Atomes d’intention

Une AIP est un ensemble d’un ou plusieurs atomes d’intention. Une clause de votre document source devient un atome, et chaque atome a les mêmes champs fixes.

Champ	Contenu
who	Les agents auxquels l’atome s’applique. Quand la source ne le dit pas, l’atome indique que c’est une déduction
does what	L’action, comme un déploiement ou la suppression d’un fichier
to what	La cible de l’action, comme un espace de noms de production
only if	Les conditions dans lesquelles l’action est acceptable
unless	Les exceptions à l’atome
class	Si l’atome peut être appliqué : enforceable, monitor-only ou out-of-scope

À partir de ces champs, OpenLatch génère une phrase et un ensemble de cas de test. Vous ne modifiez jamais les règles compilées.

Vous voyez	À quoi cela sert
La phrase	Ce que vous ratifiez, par un seul Oui ou Non
La source	La clause de votre document dont vient l’atome, citée pour que vous vérifiiez qu’elle a été bien lue
Les cas de test	Des situations concrètes avec le verdict que chacune obtiendrait, affichées en lecture seule à côté de la phrase pour éclairer votre réponse

Un Non renvoie l’atome en correction : vous dites ce que vous vouliez dire, les champs changent, et l’atome revient avec une nouvelle phrase et de nouveaux cas pour une nouvelle réponse. Modifier un atome annule toujours la ratification donnée à sa version précédente.

La class d’un atome est une propriété de l’atome, pas un réglage. Un atome monitor-only décrit quelque chose qui peut être observé mais pas arrêté avant qu’il se produise ; il reste donc en Monitor même quand sa politique est en Enforce.

Dimensions

Chaque atome appartient à l’une des cinq dimensions de l’Autonomy Zone. Une politique couvre l’union des dimensions de ses atomes.

Dimension	La question à laquelle elle répond	Exemples de politiques d’intention
Qualité	Le travail est-il au niveau attendu ?	Le code est testé avant sa livraison ; le processus imposé est suivi
Économie	Le coût est-il justifié ?	Pas de boucles incontrôlées ni de nouvelles tentatives inutiles ; le modèle correspond à la tâche
Sécurité	Peut-il y toucher ?	Aucun identifiant ne sort du périmètre de l’entreprise ; seulement des outils et serveurs approuvés
Sûreté	La conséquence est-elle acceptable ?	Pas d’accès à la production sans approbation ; pas d’opération irréversible ou destructrice
Conformité	Est-ce légal et conforme aux règles ?	Politiques et normes internes ; obligations contractuelles

La mission n’est pas une dimension : chaque agent apporte sa propre mission, et la zone apporte les règles qu’il doit suivre.

Modes

Une politique s’exécute dans l’un de trois modes. Le mode appartient à la politique, jamais à un atome, et se règle dans chaque Autonomy Zone qui contient la politique.

Mode	Ce qui se passe en cas de correspondance
Disabled	Rien. La politique et son historique sont conservés, mais elle n’est pas évaluée
Monitor	La correspondance est enregistrée comme anomalie et signalée ; l’action se poursuit
Enforce	Le verdict est appliqué avant l’exécution de l’action, partout où un adaptateur couvre cette action, et l’enregistrement indique s’il a réellement été appliqué

Quand les zones d’un agent contiennent plusieurs fois la même politique, elle s’exécute une seule fois, dans le mode le plus strict : Enforce avant Monitor avant Disabled.

Les politiques gagnent le mode Enforce sur preuves : exécutez une politique en Monitor, examinez ses anomalies, et passez-la en Enforce une fois qu’elle est juste. OpenLatch n’élargit jamais de lui-même l’autorité d’un agent.

Verdicts

Chaque action couverte qui correspond à une politique en Enforce reçoit l’un de quatre verdicts avant son exécution. Un verdict est déterministe, car une politique explicite l’a produit.

Verdict	Ce qui arrive à l’action
Allow	L’action se poursuit sans changement. En Monitor, elle peut être autorisée et signalée
Ask	L’action est autorisée et signalée pour revue par défaut
Block	L’action est empêchée avant son exécution. L’agent en reçoit la raison et peut essayer autre chose ; la session continue
Optimize	L’action prend un autre chemin, par l’un des leviers ci-dessous

Ask

Ask autorise l’action et la signale pour une revue asynchrone par défaut. La décision de revue, avec la portée choisie par le relecteur, parvient au client dans le prochain bundle de politiques ; l’action similaire suivante est donc décidée sur la machine, sans personne.

Ask ne retient une action et n’attend une approbation que sur un opt-in par atome pour une action irréversible, comme la suppression d’une base de données de production.

Codex CLI n’a pas de demande de confirmation native. Sur Codex CLI, Ask apparaît pour l’agent comme un message portant la raison de la règle, et l’appel se poursuit.

Ask empêche la récidive, pas la première occurrence. Écrivez en Block tout ce qui ne doit jamais se produire sans revue, ou marquez l’action comme irréversible sur son atome.

Leviers Optimize

Optimize change le chemin d’une action au lieu de l’autoriser ou de la bloquer. Le mode décide de ce que fait un levier : en Enforce un levier agit, et en Monitor un levier se contente de mesurer ce qu’il aurait fait.

Levier	Ce qu’il change	Statut
loop_stop	Arrête un agent qui répète le même appel, et lui dit pourquoi	Agit en Enforce
steer	Refuse l’action et indique à l’agent quoi faire à la place, comme pousser une branche plutôt que la branche principale	Agit en Enforce
narrow_output	Renvoie à l’agent un extrait filtré d’une longue sortie de commande, et garde la sortie complète sur le disque	Agit en Enforce, sur Claude Code
effort_clamp	Réduit l’effort de raisonnement d’une requête au modèle	Mesure en Monitor et en Enforce ; agit en Enforce seulement là où l’organisation cliente l’active
context_edit	Resserre les réglages d’effacement du contexte d’une requête au modèle	Mesure en Monitor et en Enforce ; agit en Enforce seulement là où l’organisation cliente l’active
prefix_guard	Garde stable le préfixe de prompt mis en cache d’une requête au modèle	Mesure en Monitor et en Enforce ; agit en Enforce seulement là où l’organisation cliente l’active
substitute	Remplace une commande par un équivalent approuvé par votre organisation	N’est pas livré : il n’a pas d’actionneur et ne fait que mesurer en Monitor

En Enforce, loop_stop, steer et narrow_output agissent (narrow_output sur Claude Code). effort_clamp, context_edit et prefix_guard ne font que mesurer, même en Enforce, sauf si l’organisation cliente l’active. substitute n’est pas livré : il ne fait donc que mesurer en Monitor. En Monitor, chaque levier ne fait que mesurer.

L’enregistrement de preuve indique lequel s’applique : appliqué en Enforce, mesuré en Monitor.

Ce que couvre un verdict

Chaque action couverte atteint le point de décision des politiques, et son verdict est appliqué. Une action hors d’une surface couverte, comme un script que l’agent a écrit plus tôt et exécute plus tard, n’est pas décidée par le client. Le niveau de contrôle de chaque agent indique la couverture qui s’applique à lui.