Aller au contenu principal

Le modèle de redevabilité

Des agents autonomes ne sont utilisables dans un cadre sérieux que si l'on peut répondre après coup à deux questions : qu'a fait l'agent, et peut-on faire confiance à cet enregistrement. Le modèle de redevabilité d'Apollia existe pour répondre aux deux, et pour garder un humain aux commandes pendant que l'agent s'exécute. Cette page explique comment les pièces s'assemblent, et ce qu'elles sont censées apporter, ou non.

Le problème​

Un agent qui raisonne et agit de sa propre initiative est puissant et, sans contrôles, opaque et irréversible. Dans un cadre réglementé, c'est disqualifiant. La réponse ne consiste pas à rendre l'agent moins autonome, mais à envelopper son autonomie dans une gouvernance : borner ce qu'il peut faire, enregistrer tout ce qu'il fait d'une manière qui ne peut pas être discrètement modifiée, et garder une personne dans la boucle sur les actions à conséquences. Ces contrôles sont intégrés au runtime plutôt que laissés à la charge de chaque agent, de sorte qu'un auteur d'agent ne puisse pas les oublier et qu'un opérateur ne puisse pas être surpris par leur absence.

Les briques de base​

Une piste signée, à altération détectable​

Chaque action gouvernée qu'un agent effectue est écrite dans un journal append-only. Le journal est une chaîne de hachage, et il est signé au fur et à mesure de sa croissance, si bien que toute altération ultérieure brise la chaîne et devient détectable. Chaque entrée est liée deux fois : à l'entrée précédente de sa propre exécution, et à l'entrée précédente de n'importe quelle exécution, si bien que le journal forme une séquence continue unique à travers toutes les exécutions, et non un ensemble de journaux indépendants par exécution. C'est ce qui transforme « l'agent dit avoir fait X » en « voici la séquence enregistrée et vérifiable de ce qui s'est passé ». La piste capture les appels d'outil et, dans le journal d'exécution, les complétions du modèle lui-même, si bien que le raisonnement derrière une action est inspectable, pas seulement son effet.

La vérification de cette piste​

Un enregistrement ne vaut que par la capacité qu'on a à lui faire confiance. Vérifier le journal contrôle ses chaînes de hachage et ses signatures et indique si la séquence a été altérée depuis son écriture. Comme les entrées sont chaînées à travers toutes les exécutions, la vérification détecte non seulement une entrée modifiée, mais aussi une exécution dont la fin a été tronquée ou une exécution entière qui a été supprimée : l'un comme l'autre laisse un trou que la chaîne expose. La redevabilité repose sur un enregistrement que l'on peut confirmer de façon indépendante, pas sur la confiance accordée au processus qui l'a produit.

Le périmètre honnête compte ici. Il s'agit de détection d'altération, pas d'inviolabilité : le mécanisme détecte une altération après coup, il ne l'empêche pas. La garantie tient tant que la clé de signature n'est pas compromise. Une partie qui détient la clé peut recalculer et resigner une chaîne plus courte mais cohérente, c'est pourquoi le runtime expose aussi la tête de la chaîne comme une ancre que l'on peut exporter et stocker hors de la machine. Comparer une exécution à une ancre détenue à l'extérieur est ce qui défend contre la troncature de l'activité la plus récente, même quand la clé elle-même est compromise.

Pour les commandes derrière ces deux mécanismes, voir Auditer et vérifier une exécution.

L'annulation de ce qu'un agent a écrit est délibérément absente. Un journal réversible existe dans la base de code, mais rien ne l'installe sur les outils qui écrivent des fichiers, si bien qu'aucune installation n'enregistre quoi que ce soit à annuler. Livrer la commande quand même aurait été pire que de ne rien livrer : un résultat vide est indiscernable d'une session propre, si bien qu'un opérateur lirait « rien à annuler » comme un filet de sécurité opérationnel et déléguerait en conséquence. Traitez chaque modification de système de fichiers faite par un agent comme définitive, et ne lui accordez en écriture que des dossiers que vous acceptez de perdre.

Permissions et supervision humaine​

Avant qu'un appel d'outil d'un agent ne s'exécute, une seule décision y répond, où que l'appel soit fait : une conversation, une tâche, une étape de plan, un élément de lot. La politique de l'organisation et une règle de refus le refusent, un outil qui ne fait que lire s'exécute, un garde-fou empêche une règle de couvrir une commande shell qui enchaîne ou redirige, et tout ce qui est sensible et qu'aucun accord permanent ne couvre soulève une demande d'approbation qu'une personne résout par l'une de trois réponses : une fois, toujours pour cet agent, ou refuser avec une raison facultative que l'agent lit. Un « toujours » est accordé à un agent pour une famille d'actions, jamais à un nom d'outil, à un projet ni à une session.

La décision elle-même est consignée : la réponse à une demande de consentement, un refus par la politique de l'organisation et un refus par une règle deviennent chacun une entrée du journal signé, qui nomme l'agent, l'outil et sa famille d'action, jamais l'argument de l'appel. Le journal garde aussi l'appel que la décision a laissé passer, la boucle de l'agent capturant l'appel d'outil et sa sortie.

Chaque décision qui attend une personne est listée à un seul endroit et se répond depuis cet endroit. GET /api/v1/pending-decisions liste les accords d'outils des conversations et des exécutions hors conversation, les pauses de tâches, les éléments de lot arrêtés sur un accès et les questions posées à l'utilisateur, et POST /api/v1/pending-decisions/decide répond à l'une d'elles, par l'appel même qui y répond là où elle est née. Le bureau lit la même liste, si bien qu'une décision est la même décision, qu'elle soit donnée là ou par l'API. Dans une conversation, un accord resté cinq minutes sans réponse est refusé.

Une limite, à énoncer clairement. La décision gouverne les appels d'outils des agents. Elle ne voit pas l'intérieur du Python d'un paquet : un outil de paquet est décidé quand un agent l'appelle, et ce que son code fait ensuite s'exécute avec les droits du processus runtime. Le modèle de confiance des agents explique pourquoi installer un paquet est l'acte de confiance, et ce qui le couvre.

Paliers d'autonomie​

Un palier d'autonomie fait varier quatre choses, et aucune autre : le budget de pas suggéré, la passe de vérification après exécution, le profil de prompt système, et la porte du plan. Il ne fait varier aucune règle de permission ni aucun point de contrôle humain sur un appel d'outil : un palier plus élevé n'élargit donc pas ce qu'un agent a le droit de toucher. Il élargit la distance qu'une exécution parcourt avant de s'arrêter pour demander.

La porte du plan est celle qui est conditionnelle. Le palier ne la décide que lorsque l'exécution ne porte aucune surcharge propre à l'exécution, et apollia-os run en envoie toujours une : sur ce chemin, c'est --plan qui décide, pas le palier. Le palier d'un agent est celui que son paquet recommande, puis le réglage de la personne (apollia-os agent set <AGENT_ID> autonomy <tier>), puis le défaut global, et apollia-os run accepte --autonomy pour une exécution. apollia.toml n'a aucune section [autonomy] que le runtime lise, et le bureau n'offre aucun réglage qui change le palier. Le chat libre ne le fait pas varier non plus, chaque échange s'exécutant au palier par défaut.

Garde-fous non négociables​

Le runtime impose un budget de pas sur chaque exécution autonome : un plafond sur le nombre d'étapes de raisonnement, sur le nombre d'appels d'outil, et sur le temps réel écoulé. Il est imposé par le runtime lui-même et ne peut pas être contourné par un agent, si bien qu'une exécution ne peut ni boucler ni consommer sans limite. C'est la garantie que l'autonomie a une limite dure.

Filtrage des commandes shell​

Les commandes shell sont filtrées avant exécution : un contrôle syntaxique rejette ce qui ne peut pas être analysé, et un filtre de motifs peut refuser une commande sur-le-champ. Ce filtre est livré avec des listes de motifs vides, et rien ne les remplit : le constructeur qui accepte des motifs n'a aucun appelant de production, et aucune section d'apollia.toml ne l'atteint, si bien que le filtre ne bloque aucune commande dans le runtime livré. Quand une règle de préfixe permanente est consultée pour un exécuteur de code, un garde-fou plus strict refuse toute commande qui enchaîne, met en pipe, redirige ou substitue, si bien qu'une autorisation accordée pour une commande ne peut pas en faire passer une seconde en contrebande ; en dehors d'une règle correspondante, chaque invocation d'exécuteur de code exige sa propre approbation.

Ce mécanisme filtre l'injection shell. Apollia n'embarque aucune défense contre l'injection de prompt, et rien ici ne doit être lu comme tel.

Autocontrôle sur le chemin orchestré​

Sur le chemin d'exécution orchestré, une exécution terminée peut être vérifiée par un critique avant que son résultat ne soit accepté, sous condition du palier d'autonomie. Le verdict est émis comme un événement runtime et atterrit dans le journal signé, si bien que le contrôle fait partie de l'enregistrement. En cas de verdict négatif, le moteur peut replanifier et relancer l'exécution, dans la limite d'un nombre borné de tentatives, sous le même budget partagé : c'est ainsi qu'un agent orchestré se corrige lui-même sans échapper à son plafond.

Une limite honnête à signaler : cette passe exécute le critique LLM, et aucun contrôle shell n'est exécuté pour le compte d'un agent. Le critique est actif ; un contrôle shell déterministe ne fait pas partie de la passe.

Correspondance avec l'AI Act européen​

Les contrôles ci-dessus s'alignent sur les obligations que l'AI Act européen impose aux systèmes d'IA à haut risque. Apollia fournit les primitives techniques qui soutiennent ces exigences. Il ne vous rend pas conforme et ne certifie rien : la conformité est un jugement porté par votre organisation et ses auditeurs sur l'ensemble de votre système et de vos processus, pas une propriété qu'un runtime peut accorder.

Avec ce cadrage, la correspondance est directe :

Exigence (thème)Primitive Apollia
Article 10, provenance et qualité des donnéesle journal d'audit signé et chaîné par hachage, plus sa vérification, qui enregistrent et permettent de confirmer quelles données et quelles actions une exécution a touchées
Article 14, supervision humainela décision de gouvernance sur chaque appel d'outil d'un agent (politique de l'organisation, règles, accord par famille d'action, approbation humaine), le garde-fou de l'exécuteur de code, et les paliers d'autonomie, qui gardent une personne au contrôle des actions à conséquences. Le Python d'un paquet installé est en dehors de cette boucle, voir ci-dessus
Article 16, documentation et traçabilitéle journal d'audit et la trace d'exécution, qui documentent ce qui s'est passé

L'intérêt est que ces mécanismes sont câblés dans le runtime et démontrables dès aujourd'hui, pas promis. Ce qui reste une responsabilité humaine, c'est de décider si votre usage de ces mécanismes, dans votre contexte, satisfait l'obligation. Apollia vous donne le mécanisme ; le jugement de conformité vous revient.

Pourquoi c'est le fond du sujet​

L'autonomie sans redevabilité est un passif, et une redevabilité rajoutée après coup n'est pas crédible. La position d'Apollia est que la gouvernance fait partie du runtime : bornée par des budgets, enregistrée dans une piste signée que l'on peut vérifier, et supervisée par des permissions et des paliers. C'est ce qui rend défendable le fait de déléguer un vrai travail à un agent autonome.

Voir aussi​