Contrôles stricts · Agents · Brouillon

Un minuscule agent d'hôte : sans modèle, sans port entrant

Statut : il s'agit d'une conception écrite, un brouillon ; pas encore construite et pas en usage. Le déploiement est prévu d'abord en faits seuls et en lecture seule, les commandes en dernier.

La plupart des discours sur les agents IA portent sur ce qu'ils peuvent faire. Cet article porte sur une pièce volontairement conçue pour faire très peu : un petit agent qui vivrait sur un hôte. Il ne contiendrait aucun modèle. Il rapporterait des faits sur l'hôte, n'exécuterait que des commandes d'une liste fixe, recevrait ses instructions sous forme de messages signés via git, et n'écouterait sur aucun port entrant.

C'est le plus petit exemple de l'idée qui traverse cette série : quand on ne peut pas rendre un composant digne de confiance en lui demandant gentiment, on le rend assez petit pour qu'il y ait peu de choses à croire.

À quoi il sert

Certains hôtes ne sont pas du tout pilotés par un assistant IA. Il faut pourtant les connaître et, de façon étroite, les gérer : ce qui y tourne, dans quel état ils sont, et une poignée d'actions de routine. Le minuscule agent d'hôte est conçu pour se placer sur un tel hôte et faire exactement cela, rien de plus.

Il ferait trois choses. Il rapporterait des faits sur l'hôte. Il recevrait des instructions sous forme de messages signés. Il n'exécuterait une commande que si elle figure sur sa liste d'autorisation.

Un robot agent d'hôte à gauche, un service git au milieu et un robot signataire à droite. Le signataire pousse des messages signés vers le service git, l'hôte les tire et lui rapporte des faits en retour. Une bande dit que l'hôte va toujours vers l'extérieur et que rien n'entre : aucun port entrant. — Figure 1 : l'hôte tire, le signataire pousse, l'hôte n'écoute jamais

Pourquoi chaque choix de conception

Chaque choix est là pour ce qu'il retire de la surface d'attaque.

Pas de modèle. Un modèle peut être convaincu : le texte qu'il lit peut orienter ce qu'il fait. Un petit programme fixe ne peut pas être poussé à une action par la parole, et il est assez petit pour qu'une personne le lise et le relise en une séance. Retirer le modèle retire de l'hôte toute une classe de manipulation.

Une liste d'autorisation. L'agent refuserait toute commande absente de sa liste. Une erreur, un mauvais message ou une requête falsifiée ne peuvent alors atteindre que ce que la liste permet. Inconnu veut dire refusé.

Des messages signés. L'hôte n'agirait que sur des instructions dont il peut vérifier la signature. Pouvoir atteindre le canal ne suffit pas ; seul le détenteur de la clé de signature peut donner des instructions à l'hôte.

Git comme canal. L'hôte demanderait à git les nouveaux messages, au lieu d'attendre d'être appelé. Chaque instruction devient un commit, de sorte que l'historique est une trace de ce qui a été demandé et par qui, et le transport n'a besoin de rien de spécial.

Aucun port entrant. Comme l'hôte irait toujours vers l'extérieur et que rien n'entrerait, il n'y a aucun service à l'écoute qu'on puisse scanner, sonder ou exploiter depuis le réseau.

Cinq lignes. Chaque choix de conception à gauche, pas de modèle, liste d'autorisation, messages signés, git comme canal et aucun port entrant, pointe vers ce qu'il retire de la surface d'attaque à droite. Une bande dit que chaque choix retire quelque chose et que l'image suivante montre ce qui reste. — Figure 3 : ce que retire chaque choix de conception

Un message, cinq étapes fixes

Chaque message passerait par les mêmes étapes dans le même ordre : le tirer, vérifier la signature, comparer la commande à la liste d'autorisation, exécuter la seule commande listée, rapporter le résultat et les faits de l'hôte. Si une étape échoue, le message s'arrête là. Non signé, inconnu ou non listé veut dire que rien ne s'exécute, et il n'y a aucun jugement au milieu sur lequel quelqu'un puisse s'appuyer.

Cinq boîtes alignées, chacune avec un petit robot : tirer un nouveau message, vérifier sa signature, comparer la commande à la liste d'autorisation, exécuter une commande listée, rapporter le résultat et les faits de l'hôte. Une bande dit que toute étape qui échoue arrête le message, de sorte que non signé, inconnu ou non listé veut dire que rien ne s'exécute. — Figure 2 : un message, cinq étapes fixes

Ce que cela coûterait

Petit et strict a un prix.

La flexibilité. Un nouveau type de tâche demande une nouvelle entrée dans la liste d'autorisation, qu'il faut écrire et relire. C'est le but, et aussi une friction.
La gestion des clés. La signature demande des clés : quelqu'un doit les créer, les garder en sûreté, décider qui peut signer, et les remplacer quand il le faut. La conception exige que ce travail soit bien fait ; la manière de détenir la clé de signature est un point de conception ouvert, et cet article ne décrit aucune configuration.
La vitesse. Un hôte qui interroge à intervalles apprend une instruction à la prochaine interrogation, pas instantanément.
La dépendance à git. Le canal dépend de l'accessibilité du service git et de son bon comportement.
Le diagnostic. Un programme fixe à sortie étroite dit peu de choses quand quelque chose tourne mal ; la remontée d'informations et la journalisation demandent donc du soin.

Ce contre quoi cette conception ne protège pas

Nommer les limites compte plus que lister les forces.

La clé de signature. Quiconque détient la clé de signature peut envoyer des messages valides. La liste d'autorisation limite ce qu'il peut demander, mais une action nuisible figurant sur la liste serait exécutée. La manière de détenir la clé, et de la remplacer, est un point de conception ouvert.

Le rejeu. Un véritable message signé peut être renvoyé plus tard. La conception exige un moyen de distinguer les messages récents des anciens, comme une expiration ou un compteur ; sans cela, le rejeu est possible.

Un service git compromis. Le service ne peut pas falsifier les signatures, mais il peut retenir des messages, les retarder ou en montrer d'anciens. Cela touche la disponibilité et la fraîcheur, pas l'authenticité.

Une mauvaise liste d'autorisation. La liste d'autorisation est la vraie frontière des permissions. Elle n'est sûre que dans la mesure de ses entrées et des arguments qu'elles acceptent ; une entrée large est une permission large.

Un hôte compromis. Un hôte pris en main peut rapporter de faux faits sur lui-même. Les dégâts se limitent aux chemins propres de cet hôte : il n'atteindrait pas d'autres hôtes par cette conception.

Cinq cartes, chacune avec un petit robot : la clé de signature comme point de conception ouvert, le rejeu d'un ancien message signé, un service git compromis, une mauvaise liste d'autorisation, et un hôte compromis qui peut rapporter de faux faits, limité à ses propres chemins. Une bande dit que de petites listes d'autorisation, des messages récents, des clés soigneusement gérées et une surveillance réduisent les dégâts, mais que ces risques demeurent. — Figure 4 : ce contre quoi cette conception ne protège pas

Ces risques seraient réduits par de petites listes d'autorisation aux arguments fixes, des messages récents, un traitement soigné des clés et une surveillance de ce que rapporte l'hôte. Ils ne sont pas supprimés.

Comment cela s'insère dans le reste de la série

L'agent d'hôte serait la couche la plus basse du même tableau. Les agents au-dessus proposent, les personnes approuvent, et des messages signés et consignés transmettent vers le bas l'instruction approuvée. Tout en bas, il y aurait une pièce qui suit sa liste et tient une trace, et qui n'offre guère autre chose à attaquer.