L'agent permanent d'OpenAI a brûlé 300 000 tokens sans qu'on le lui demande

Trois cent mille tokens, aucune question posée

Des tests indépendants de l'assistant permanent « dot » d'OpenAI ont montré qu'il avait brûlé plus de 300 000 tokens en une seule journée, généré 155 traces d'activité et lancé plusieurs sous-agents, sans la moindre invite de son utilisateur. Il ne disposait que de permissions en lecture seule. Personne ne lui avait demandé quoi que ce soit.

Relisez cette dernière phrase, car tout est là. L'agent n'a pas été piégé, et il ne faisait rien qu'on lui avait interdit. Il était simplement allumé, et être allumé s'avère coûteux.

La facture que vous n'avez pas demandée

Tous les autres produits d'IA du marché ont une frontière de coût évidente. Vous tapez quelque chose, des tokens sont consommés, et quand vous arrêtez de taper, le compteur s'arrête. Le modèle mental est celui du taxi : il coûte de l'argent tant que vous roulez, et rien quand vous ne roulez pas.

Un agent ambiant brise ce modèle. Il ressemble moins à un taxi qu'à la régulation climatique d'un bâtiment. Il fait toujours quelque chose, parce qu'être toujours prêt exige une activité constante. Surveiller un déclencheur, vérifier si les conditions ont changé, décider si la situation justifie de se réveiller, planifier ce qu'il fera s'il se réveille. Chacune de ces étapes est un appel au modèle, et chaque appel au modèle a un prix.

La découverte dérangeante ici n'est pas qu'un agent ait dépensé de l'argent. C'est que la dépense ait eu lieu de façon invisible et continue, guidée par le jugement de l'agent lui-même plutôt que par une instruction humaine. Il n'y avait pas de session à terminer, parce qu'il n'y avait pas de session. Il y avait juste un processus en arrière-plan qui avait des opinions sur ce qui valait la peine d'être fait.

La lecture seule n'est pas inoffensive

La deuxième surprise, c'est le modèle de permissions. « Lecture seule » sonne comme quelque chose de sûr. Cela ressemble au réglage prudent que l'on choisit quand on veut être vigilant.

Mais la lecture seule signifie toujours « peut tout observer ». Un agent doté d'un accès en lecture peut parcourir le courrier, les documents, les messages et les agendas, et chaque parcours est en soi une décision qui coûte des tokens. Pire, l'observation suffit à devenir dangereux d'une autre manière. Un lecteur permanent qui résume ce qu'il voit est, fonctionnellement, un système de surveillance. La question de savoir s'il peut agir est distincte de celle de ce qu'il a déjà appris.

Il y a aussi un problème plus subtil. L'accès en lecture fournit à l'agent la matière première pour juger qu'une action se justifie, et la frontière entre « j'ai remarqué quelque chose » et « je devrais faire quelque chose à ce sujet » est exactement là où un système autonome devient difficile à superviser. Un ensemble de permissions qui empêche l'écriture n'empêche pas l'agent de consacrer beaucoup d'efforts à décider ce qu'il écrirait.

Pourquoi plus d'agents aggrave la situation

Le détail du lancement de plusieurs sous-agents devrait être celui qui fait lever les sourcils en réunion d'ingénierie. Créer des auxiliaires est un schéma populaire précisément parce que cela fonctionne. On découpe une tâche, on confie des morceaux à des travailleurs parallèles, on récupère les résultats. C'est ainsi qu'on fait traiter à un agent quelque chose de trop grand pour une seule fenêtre de contexte.

C'est aussi ainsi qu'on rend le coût non linéaire. Un agent qui décide de lancer trois sous-agents, chacun décidant de vérifier autre chose, n'a pas dépensé quatre fois plus. Il a dépensé ce que coûte l'arbre, et la forme de l'arbre a été choisie par un modèle qui optimisait pour la tâche plutôt que pour le budget.

Multipliez maintenant cela par chaque utilisateur qui a activé la fonction et l'a oubliée. L'économie des agents permanents n'est pas celle des appels d'API, où le client contrôle le volume. Elle ressemble à celle d'une flotte qu'il faut gérer activement, sauf que la flotte décide elle-même de ses itinéraires.

La frontière de session manquante

Les assistants textuels ont hérité par accident d'une propriété de sécurité utile : une conversation se termine. Quand elle se termine, l'agent s'arrête, le contexte est libéré et les comptes sont réglés. Même un agent mal élevé est borné par le fait qu'il ne tourne que pendant que quelqu'un lui parle.

Les agents ambiants n'ont pas une telle frontière. La promesse du produit est que l'assistant est toujours là, ce qui signifie que le processus tourne toujours, que le contexte est toujours actif et que les occasions pour un modèle de décider de faire quelque chose sont effectivement continues.

Ce n'est pas un défaut de conception. C'est la conception. Mais cela signifie que la question de sécurité passe de « que peut-il faire en un tour » à « qu'accumule-t-il sur un mois ». Personne dans le secteur n'a de bonne réponse à la deuxième question, et la première est la seule que les évaluations existantes sont conçues pour mesurer.

À quoi devrait ressembler la supervision

Si l'agent doit tourner sans qu'on le lui demande, alors la supervision ne peut pas être un contrôle au niveau du prompt. Elle doit être structurelle, et elle doit être ennuyeuse.

Un budget strict est la première pièce, et il doit être un vrai plafond plutôt qu'une notification. Les plafonds de dépense qui vous alertent après coup ne sont pas des plafonds. La deuxième pièce est un journal lisible de ce que l'agent a fait et de pourquoi il a décidé de le faire, car « 155 traces d'activité » est un nombre, et un nombre n'est pas une explication. La troisième est un réglage par défaut qui n'est pas actif en permanence. La plupart des utilisateurs de la plupart des produits n'ont pas besoin d'un raisonnement continu en arrière-plan, et ceux qui en ont besoin devraient être ceux qui l'ont choisi.

La pièce plus profonde est un consentement qui survit au contact de la réalité. Dire à un utilisateur dans une page de réglages que l'agent peut agir en arrière-plan n'est pas la même chose que l'utilisateur qui comprend qu'il dépensera de l'argent pendant qu'il dort. Les produits résolvent généralement cette tension en élargissant lentement la portée et en espérant que personne ne le remarque. Cette habitude va sembler très coûteuse dès que les agents auront un portefeuille.

La vraie leçon porte sur les réglages par défaut

Il est facile de balayer les résultats de dot comme une bizarrerie d'un produit expérimental. Le schéma qui les sous-tend n'a rien d'expérimental. Tous les grands assistants s'orientent vers une disponibilité permanente, et chaque fournisseur subit la pression de le faire paraître magique plutôt que mesuré.

La magie et la mesure s'opposent. Plus le produit paraît sans effort, plus le travail se fait hors de vue, et plus il est difficile pour un utilisateur de se faire une image précise de ce qu'il coûte. Quand le compteur est caché, le seul retour qui reste est la facture, et le temps de la voir, la décision a déjà été prise plusieurs centaines de milliers de tokens plus tôt.

La position prudente, pour quiconque déploie ces systèmes aujourd'hui, est de traiter « combien peut-il dépenser sans demander » comme un paramètre de conception de premier ordre, juste à côté de « à quel point fonctionne-t-il bien ». Le second est celui que les fournisseurs vantent. Le premier est celui qui décide si le produit tourne encore le trimestre prochain.