Deux pattes sont déjà livrées
Un agent Buzz est une paire de clés Nostr, et j'ai décrit ce que cela apporte dans votre agent est une clé. L'identité voyage déjà : l'attestation que je signe sur la clé publique de l'agent accompagne chaque événement qu'il publie, et le relais vérifie la signature de l'agent, ma signature et mon adhésion avant que quiconque ne voie un mot. Cette vérification passe depuis n'importe quelle machine. Rien en elle ne sait ni ne se soucie de l'endroit où le processus s'est réveillé.
La mémoire voyage déjà, elle aussi. Les mémoires d'un agent sont des événements chiffrés sur le relais, et la clé de déchiffrement dérive de la clé privée de l'agent et de ma clé publique : la mémoire centrale est donc récupérée et injectée dans chaque nouvelle session, où que se trouve la clé. Ce qui suit la clé survit à la machine. Deux pattes du tabouret sont livrées aujourd'hui. La troisième est encore boulonnée à mon laptop.
La troisième patte est collée à la machine
La troisième patte, ce sont les identifiants. Le token d'abonnement Claude, celui que génère claude setup-token pour qu'un agent facture mon forfait plutôt que le compteur de l'API, vit dans l'environnement d'une seule machine. Les clés API des outils aussi. Les accès aux serveurs MCP aussi. L'identité est portable, la mémoire est portable, et tout ce dont l'agent a besoin pour vraiment travailler est agrafé à la première machine que j'ai configurée.
Voici l'aveu, tiré de notre propre déploiement. Une clé API d'outil parvenait à l'un de nos agents par un script wrapper écrit à la main, glissée en douce dans le dos du produit. Aucune interface ne pouvait lister cet accès. Rien ne pouvait l'auditer. Rien ne pouvait en faire la rotation. Ça marchait, et c'est bien le pire, parce qu'un contournement qui marche devient discrètement de l'infrastructure. Un accès que vous ne pouvez pas lister est un accès que vous ne pouvez pas révoquer.
C'est à la rotation que la nuisance devient une panne. Je relance /login sur mon laptop, et le token que détient chaque copie distante de chaque agent meurt, en silence, sans que rien ne me dise qui reste en rade. La patte identité se répare seule. La patte mémoire se répare seule. La patte identifiants casse, tout simplement, une machine à la fois.
Le trousseau : la rotation est une republication
NIP-AK, rédigé aujourd'hui, est la troisième patte : des trousseaux d'agent sous forme d'événements chiffrés, écrits par le propriétaire, sur le relais. Chaque accès vit à sa propre adresse, un slug comme key/claude-sub ou key/mcp/blotato, et les adresses sont masquées par un HMAC pour que le relais n'apprenne rien de ce qu'il stocke. Les accès sont typés : env, oauth, mcp, file. Et la liste des accès MCP n'est pas une indication : elle est la liste des outils autorisés de l'agent.
La rotation est une republication. Je publie une nouvelle tête à la même adresse et chaque consommateur converge vers elle. Un watcher côté propriétaire remarque le /login local et republie en quelques secondes, sans aucune cérémonie de ma part. Les consommateurs récupèrent les têtes au démarrage, gardent une souscription ouverte pour recevoir le push et, sur tout échec d'authentification, réinterrogent les têtes avant de réessayer : un exécuteur resté en rade se répare donc seul. Un agent qui a dormi pendant cinq rotations se réveille face à une seule tête, sans protocole de rattrapage. Et les consommateurs rejettent les têtes plus anciennes que la dernière qu'ils ont acceptée, si bien qu'un accès périmé rejoué ne fait revenir personne en arrière. La révocation est une rotation vers un tombstone.
Une règle tient tout le modèle : les agents ne peuvent pas écrire d'événements de trousseau. Le trousseau, c'est à moi de l'écrire et à eux de le lire. Un agent compromis ne peut pas s'octroyer une nouvelle clé, une liste d'outils autorisés plus large, ni les identifiants de quelqu'un d'autre. Il peut dépenser ce que je lui ai accordé, jusqu'à ma prochaine rotation. Et une rotation, c'est une seule publication.
Ce que montre le panneau
La spécification encode une règle d'UX, et c'est elle qui compte : aucun identifiant n'atteint un agent autrement que par le trousseau, et le trousseau est visible. Chaque agent a un panneau : chaque accès, sa provenance, sa dernière rotation et la fraîcheur de la copie de chaque exécuteur. Les sources synchronisables sont des cases à cocher par agent. Cochez-en une et l'abonnement suit cet agent ; décochez-la et la prochaine rotation laisse l'agent derrière elle.
Mettez ce panneau en regard du script wrapper de notre propre déploiement. La clé glissée en douce n'avait de ligne nulle part, et toute cette catégorie de contournements disparaît, parce qu'il ne lui reste plus aucun endroit où vivre. Ce que montre le panneau, c'est ce que l'agent possède. Si ce n'est pas sur le panneau, l'agent ne l'a pas.
Pourquoi c'est tout l'enjeu
Votre agent, ce sont deux clés : une clé d'identité et une clé d'inférence, et les deux voyagent. La clé d'identité signe son travail. La clé d'inférence paie sa réflexion. Tout le reste, mémoire, outils, adhésion, dépend de l'une des deux.
La clé d'inférence, c'est aussi l'économie du système. Un abonnement Claude à 200 $ par mois porte un ordre de grandeur d'inférence de plus que la même dépense au tarif de l'API, et les pertes qui ont tué une série de startups d'agents venaient de la revente d'inférence API en dessous du prix d'un abonnement. Les systèmes bâtis sur ces pertes ne peuvent pas rivaliser avec des agents qui dépensent l'abonnement de leur propriétaire. Les fenêtres de limite ne sont pas une nuisance. Elles sont le budget naturel de chaque humain.
Avec trois pattes sous lui, la machine cesse de compter. Créez un agent n'importe où : le mac mini de mon bureau, un conteneur de la flotte, un pod Kubernetes, un sandbox Fountain. L'identité suit la clé. La mémoire suit la clé. Désormais, l'abonnement et les outils suivent aussi la clé. La machine est jetable. Traitez-la comme telle.