Une politique de paiement porte de un à deux le nombre de personnes chargées du contrôle. Un agent récupère un résumé rédigé avant le changement. Ce résumé peut décrire fidèlement l'ancienne politique. Pour savoir s'il peut servir aujourd'hui dans une décision de paiement, il faut savoir quelle politique est autorisée et en vigueur pour ce client et cette action.
La mémoire persistante fait de cette distinction un problème d'ingénierie. Une information stockée peut servir à l'explication historique, à la planification ou à l'exécution, et chaque finalité exige une règle qui détermine les enregistrements applicables. Nous passons en revue des travaux récents, rendons compte de sept petits tests d'un garde-fou de mémoire publié, et proposons une fiche d'applicabilité des politiques. Cet article fait partie d'une série de recherche en trois volets sur l'autorité des agents, publiée le 26 octobre 2026 : preuves d'arrêt, politiques dans la mémoire des agents et standards de contrôle des agents.
Des travaux récents donnent au problème une forme concrète
Dans Revoked but Still Authoritative, une prépublication de septembre 2026, Yi Ting Shen, Kentaroh Toyoda et Alex Leung étudient la manière dont des informations révoquées réapparaissent dans les workflows de mémoire des agents. L'article couvre plusieurs systèmes de mémoire et méthodes d'insertion, avec des expériences sur l'écriture en retour (write-back), les magasins partagés et l'usage d'outils. Lire l'article.
La configuration pèse sur les résultats. L'article distingue la récupération par défaut de Graphiti d'une condition mem0 qui contourne le filtre d'expiration livré avec mem0. D'autres systèmes se comportent différemment selon la manière dont une mise à jour de politique entre en mémoire et selon que le statut de révocation parvient ou non à l'appelant. Lisez les résultats de l'étude en gardant ces conditions en tête.
Les auteurs publient aussi un filtre de recherche en mémoire. Il s'appuie sur les métadonnées de révocation disponibles et sur une détection heuristique des conflits pour décider quels enregistrements écarter. Nous avons examiné l'implémentation et l'avons exécutée en local à un commit épinglé. Son auto-test intégré a réussi. Nous lui avons ensuite soumis sept petits cas synthétiques conçus pour montrer où la sélection d'une politique demande davantage de contexte. Garde-fou publié.
Ce qu'ont montré les sept tests
Les trois premiers cas correspondent au comportement documenté du garde-fou. Il a écarté un enregistrement explicitement révoqué. Il a préféré le plus récent de deux enregistrements horodatés en conflit. Lorsqu'aucun des deux ne portait d'horodatage exploitable, il les a conservés tous les deux et a signalé un conflit non résolu.
Les quatre autres cas ajoutent un contexte dont une décision de politique a besoin et que ce garde-fou ne résout pas :
| Tâche synthétique | Sélection observée | Contexte nécessaire à l'appelant |
|---|---|---|
| Deux politiques s'appliquent à des clients différents | La politique la plus récente reste dans kept | Le périmètre client, avant de comparer les remplacements |
| Une note récente non approuvée contredit une politique approuvée | La note récente reste dans kept | La source habilitée à autoriser un changement de politique |
| Un enregistrement plus récent entre en vigueur en 2099 | La politique future reste dans kept | L'intervalle d'effet à la date de la décision |
| Une question d'audit exige la politique antérieure | La politique actuelle reste dans kept ; l'antérieure est dans withheld | Une récupération historique adaptée à la question |
Comment lire ces résultats
Ce sont des observations déterministes d'une seule fonction de filtrage. Les champs client, autorité et date d'effet dépassent ses règles de sélection documentées, et elle ne prend aucun paramètre pour la finalité de la requête. Les cas décrivent des responsabilités qui incombent à l'application qui intègre le garde-fou. Ils ne montrent aucune vulnérabilité du garde-fou ni des systèmes de mémoire en général, et sept cas choisis ne disent rien de la fréquence. Aucun modèle, service de mémoire ni outil de paiement n'a été exécuté.
Le cas historique demande de l'attention. Le garde-fou conserve l'enregistrement écarté dans sa sortie, de sorte qu'une application peut encore le lire. La décision d'intégration consiste à déterminer si une question d'audit doit utiliser le même contexte filtré qu'une demande d'exécution de la politique en vigueur.
Rendre l'applicabilité explicite
La conception que nous proposons part de la tâche. Une question sur l'approbation du mois dernier peut nécessiter une politique remplacée. Une demande de libération de paiement nécessite la politique en vigueur pour cette action à cet instant. Garder la finalité explicite permet à un système de conserver un historique utile tout en sélectionnant le bon contexte pour l'exécution.
L'étape suivante consiste à établir le périmètre et la source d'autorité. Un enregistrement de politique doit identifier le client ou le tenant, l'action gouvernée, l'émetteur, le statut d'approbation, l'intervalle d'effet et ce qu'il remplace. Un horodatage plus récent aide à ordonner les enregistrements une fois ces relations connues. Il ne peut pas fournir une approbation qui n'a jamais eu lieu.
Enfin, le composant capable de déclencher une action lourde de conséquences doit évaluer l'autorisation applicable. Un résumé récupéré peut porter un identifiant de politique et expliquer une action proposée. La décision d'exécution doit être rattachée à une version de la politique qui fait foi et enregistrée avec son résultat. Il s'agit d'une recommandation de conception ; nous ne l'avons pas mesurée par un benchmark.
- 1. Finalité : explication historique, planification ou exécution.
- 2. Périmètre : client ou tenant, ressource et action gouvernée.
- 3. Autorité et temps : émetteur, enregistrement d'approbation, début et fin d'effet, remplacement.
- 4. Sélection : la politique applicable et toute dérogation approuvée.
- 5. Décision : évaluer l'action proposée au regard de la version qui fait foi et conserver la référence.
Une fiche d'applicabilité des politiques
Des travaux connexes traitent de problèmes voisins. MINJA étudie la manière dont les interactions peuvent contaminer la mémoire d'un agent, et VersionRAG examine les questions portant sur des versions de documents qui évoluent. MINJA, VersionRAG.
Pour le responsable d'une politique, un enregistrement utile répond à quatre questions : d'où vient la politique, qui l'a approuvée, quand et où elle s'applique, et quelles décisions se sont appuyées sur elle. La fiche d'applicabilité des politiques (en anglais) traduit ces questions en champs qu'une équipe peut vérifier.
| Champ de décision | À consigner |
|---|---|
| Finalité de la tâche | Explication historique, planification ou exécution ; heure de la décision et toute date historique demandée |
| Périmètre | Client ou tenant, ressource et action gouvernée |
| Politique | Identifiant et version |
| Autorité | Autorité émettrice et enregistrement d'approbation |
| Effet | Début et fin d'effet ; état de retrait ou de remplacement ; relation de remplacement explicite |
| Dérogations | Dérogation approuvée, son périmètre et son expiration |
| Sources | Documents sources et résumés dérivés qui y renvoient |
| Conflits | Preuves contradictoires et responsable de la politique concernée |
| Exécution | La vérification qui fait foi et son résultat enregistré |
Où KLA évalue les politiques
Dans KLA, le KLA Policy Engine évalue une action gouvernée au moment de son exécution et rend l'un de quatre résultats : allow, warn, require_approval ou block. Lorsque l'évaluation échoue, le moteur renvoie sa décision de repli restrictive (fail-closed), par défaut require_approval, et le lint des policy packs rejette toute politique dont la décision par défaut laisse passer l'action (fail-open). Le résumé de politique mémorisé par un agent peut éclairer sa proposition. La décision provient de la version publiée de la politique.
Les tests de cet article ont porté uniquement sur le garde-fou publié. Ils ne contiennent aucun résultat KLA.
Foire aux questions
Pourquoi les agents d'IA utilisent-ils des politiques obsolètes tirées de leur mémoire ?
Un magasin de mémoire peut contenir un résumé rédigé avant le changement d'une politique. La récupération peut bien le classer, et un enregistrement plus récent peut concerner un autre client, ne pas avoir été approuvé ou ne pas encore être en vigueur. Tant que l'application ne résout pas le périmètre, l'autorité et les dates d'effet, l'agent peut agir selon une politique qui ne s'applique plus.
Un horodatage plus récent signifie-t-il qu'un enregistrement de politique est celui en vigueur ?
Non. Un horodatage ordonne les enregistrements une fois établi qu'ils couvrent le même périmètre et que le plus récent a été approuvé et est en vigueur. Dans nos tests, un garde-fou publié a conservé une note récente non approuvée et une politique datée de 2099, car son contrat ne couvre ni l'approbation ni les intervalles d'effet.
Un agent doit-il supprimer de sa mémoire les politiques remplacées ?
Conservez-les pour l'historique et orientez-les selon la finalité. Une question d'audit peut exiger la politique antérieure ; une demande d'exécution exige celle en vigueur. C'est pour cette raison que le garde-fou que nous avons testé conserve les enregistrements écartés dans sa sortie.
Où la vérification finale de la politique doit-elle avoir lieu ?
Dans le composant capable de déclencher l'action lourde de conséquences, au regard d'une version de la politique qui fait foi, avec la version et le résultat enregistrés. La mémoire peut expliquer une proposition. La vérification de la politique décide si l'action s'exécute.
Points clés à retenir
Une politique mémorisée est un contexte utile et une autorité peu fiable. Fixez la finalité de chaque récupération, établissez le périmètre, le statut d'approbation et les dates d'effet avant de vous fier à la date la plus récente, et effectuez la vérification d'exécution au regard de la version qui fait foi. Utilisez la fiche d'applicabilité des politiques pour consigner ces décisions.
Les sources ont été vérifiées le 26 octobre 2026. Les sept cas sont tous synthétiques, ont porté sur une seule fonction publiée et ne mesurent rien des systèmes déployés.