IntentFlow : un langage pour auditer les agents LLM

IntentFlow propose un langage déclaratif pour encadrer les agents LLM et générer des preuves d’exécution vérifiables indépendamment. Le plan est appliqué hors du modèle via un ActionGate, et chaque run produit une trace chaînée par hash. L’outil existe en pré‑alpha, avec un usage hors ligne et des limites connues.

Des traces chaînées et une conformité vérifiable, jusqu’à l’escalade

Chaque exécution génère une trace append‑only chaînée par hash, pouvant être signée. Un auditeur peut redériver les règles à partir du fichier source et établir la conformité en ne s’appuyant que sur ce fichier et la trace. Dans l’exemple fourni, refus d’actions, approbations requises, sorties typées et seuils de confiance débouchent sur des vérifications et des escalades vérifiables par machine, plutôt que sur la seule confiance. Les issues d’escalade prévues incluent notamment « fail closed » et « needs_human ».

Un langage .iflow et un ActionGate qui imposent le plan

IntentFlow se présente comme un petit langage déclaratif « .iflow ». Il transforme les objectifs de l’agent, les critères de preuve, la politique d’action, les procédures de vérification, la prise en compte de l’incertitude et le contrat de sortie en un plan destiné à l’exécution. Ce plan est mis en œuvre en dehors du modèle par un ActionGate, lequel ne consulte jamais la sortie du modèle.

Exécution hors ligne, exemple GitHub et limites de la pré‑alpha

Un pipeline d’exécution et d’audit est défini et l’usage hors ligne est possible via les commandes « validate », « explain », « run » et « audit ». Un exemple concret de triage de tickets GitHub en .iflow est fourni avec cette présentation. Parmi les restrictions de la version pré‑alpha figurent une calibration figée, des contrats typés uniquement au niveau supérieur et non à l’intérieur, des primitives d’incertitude qui sont enregistrées sans être exécutées, ainsi que des outils à effets secondaires qui ne sont pas encore pris en charge. Le projet propose de le tester hors ligne et de faire remonter les dysfonctionnements éventuels. En toile de fond, il est affirmé que des garde‑fous fondés uniquement sur des invites, du code d’application ou des callbacks peuvent fuir face au réel, d’où la promotion d’un artefact de gouvernance imposé et révisable, fournissant une preuve vérifiable après l’exécution. L’exemple initial évoquait justement des règles d’invite du type ne pas fermer un ticket, toujours citer une preuve et solliciter un humain en cas de doute.