Voici Jev : un second avis qui répond en types, pas en prose
Agent! demande désormais à Jev (TypeSafe System One) à quel point une commande shell est destructrice avant de l’exécuter. Voici pourquoi Jev est un conseiller et non un fournisseur de LLM de plus.
Aujourd’hui, Agent! se dote d’une nouvelle couche de sécurité : Jev, abréviation de TypeSafe System One. Avant l’exécution d’une commande shell, Agent! peut désormais poser une seule question à Jev : quelle est la probabilité que cette commande détruise des données de manière irréversible ? Au-delà de votre seuil, la commande est refusée.
Elle est arrivée avec le commit 337c94a2, « Ajout de la couche de décision Jev (TypeSafe System One) ». Cet article porte sur la décision de conception la plus importante : Jev n’est pas un fournisseur de LLM de plus.
Pourquoi ne pas simplement interroger un autre modèle ?
Agent! communique déjà avec 23 fournisseurs de LLM. La solution de facilité aurait été d’ajouter un « modèle de sécurité » comme fournisseur supplémentaire et de lui demander, en langage naturel, si une commande semble dangereuse. Le problème, c’est ce qu’on obtient en retour : de la prose. « Cette commande pourrait être risquée selon… » n’est pas un verdict. On finit par analyser des phrases pour décider s’il faut exécuter rm.
Jev fonctionne différemment. Il répond à des questions typées sur un état, avec un Choice, un Score ou un Noul, une réponse typée « aucun ». Il ne génère pas de texte, ni d’arguments d’outils. Le message de commit en tire la conclusion : Jev « conseille la boucle d’outils existante au lieu d’agir comme un APIProvider ».
Cette séparation, c’est toute la conception :
- Le modèle que vous avez choisi agit. Il planifie, appelle des outils et écrit du code.
- Jev juge. Il renvoie un nombre que le code peut comparer à un seuil.
Où il se situe
Jev ne remplace rien. L’ordre des vérifications pour chaque commande shell est le suivant :
ShellSafetyService.check: des règles codées en dur qui refusent les commandes catastrophiques. Aucun modèle n’intervient.- Jev : uniquement pour les commandes qui ont déjà passé l’étape 1, comme second avis sur ce que les motifs ne peuvent pas voir.
- Exécution de la commande.
Dès le premier jour, ce contrôle couvre les deux chemins d’exécution shell de ShellTools (executeTCC et executeTCCStreaming).
Conçu pour ne jamais bloquer votre tâche
Un conseiller capable de bloquer votre agent est dangereux à sa manière. Si le service est indisponible, votre tâche de nuit reste-t-elle bloquée ? Ici, la réponse est non. JevAdvisor est fail-open. Pas de clé, interrupteur désactivé ou panne : cela signifie « pas d’avis », et la commande s’exécute.
Mais le fail-open n’est sûr que s’il est visible. Dès le premier jour, deux modifications complémentaires y ont veillé :
- « Rendre le conseiller observable » (
e25384f3) a ajouté un callback d’utilisation et la remontée d’erreurs, afin qu’une vérification échouée soit journalisée au lieu de passer silencieusement pour « sûre ». - « Journaliser le verdict, pas seulement le fait que Jev a répondu » (
d3c47e67) a fait en sorte que chaque vérification affiche le résultat réel : le pourcentage de risque destructeur et si la commande a été autorisée ou refusée.
Le client est un vrai package
La première version utilisait un client HTTP fait maison : POST /v1/systemone pour les questions, GET /v1/models pour la liste des modèles, une authentification Bearer et un backoff sur les réponses 429 et 529. En quelques heures, 9e330357 l’a remplacé par le package TypeSafeKit, et f3a817b8 a intégré le package directement dans le dépôt Agent pour qu’une compilation ne dépende jamais de son téléchargement.
Configuration
Jev se trouve dans les Réglages avec sa propre clé d’API, stockée dans le Trousseau dans un emplacement dédié, distinct de ceux des fournisseurs. Il dispose d’un sélecteur de modèle, chargé depuis /v1/models, et d’un interrupteur de conseil. Désactivez l’interrupteur et Agent! se comporte exactement comme avant.
Pourquoi c’est important
Les agents obtiennent partout un accès au shell, et la réponse habituelle en matière de sécurité est « le modèle fera attention ». Les règles fondées sur des motifs sont préférables, car elles sont vérifiables. Mais elles ne connaissent que les motifs que quelqu’un a écrits. Un second avis typé apporte du jugement sans ajouter d’ambiguïté : il renvoie un nombre, et c’est le code qui tranche.
Nous allons ajuster le seuil par défaut et surveiller les journaux. Si Jev refuse quelque chose qu’il ne devrait pas, ou laisse passer quelque chose qu’il aurait dû intercepter, ouvrez une issue sur GitHub en incluant la ligne de journal.