Sierra a publié le brouillon 0.1 du Personal Agent Protocol, ou Poppy, le 9 octobre, trois jours après avoir annoncé le projet avec Meta et d’autres partenaires. Le nouveau document transforme la promesse générale du lancement en règles proposées pour trouver l’interface d’agent d’une entreprise, identifier un agent personnel, connecter un client et poursuivre une visite entre un site web, des API et un agent d’entreprise.

Il s’agit toujours d’un brouillon. La spécification indique que toute partie peut changer avant une version stable, y compris de manière incompatible. Sierra a également nommé 35 partenaires de conception supplémentaires. Participer au processus de conception ne prouve pas que ces entreprises ont déployé des interfaces Poppy.

Le grand changement

  • Ce qui a changé : L’annonce du 6 octobre décrivait un moyen pour les agents personnels de travailler avec des entreprises. Le brouillon du 9 octobre détaille les échanges proposés d’identité, d’autorisation et de session qu’une entreprise et un agent devraient mettre en œuvre.
  • Pourquoi c’est important : Un client pourrait autoriser un agent à effectuer des tâches liées à son compte, tandis que l’entreprise identifie l’agent et limite son accès. Le brouillon relie ce contrôle à la navigation sur le site, aux API et aux conversations, même si l’entreprise choisit les canaux et autorisations qu’elle propose.
  • À surveiller : Les développeurs disposent désormais d’interfaces concrètes à examiner, tandis que les règles relatives aux paiements, aux notifications et aux pièces jointes restent en suspens. Sierra prévoit des ateliers de conception et une implémentation de référence au cours du mois prochain ; aucun des deux n’est encore une preuve d’interopérabilité à grande échelle.

La découverte commence sur le domaine de l’entreprise

Selon la spécification provisoire, une entreprise participante publie /.well-known/poppy.json en HTTPS. Ce document indique son organisation et son émetteur OAuth, les méthodes de connexion prises en charge ainsi que tout point de terminaison de session web, toute API OpenAPI ou MCP et tout point de terminaison de conversation avec un agent d’entreprise qu’elle propose. L’entreprise n’a pas à offrir toutes les voies. L’agent utiliserait le fichier pour découvrir les options disponibles, au lieu de considérer le site web comme son seul point d’entrée.

Le fichier seul ne peut pas autoriser un agent. Le domaine de l’organisation doit correspondre à celui demandé par l’agent. Celui-ci doit aussi vérifier les métadonnées du serveur OAuth : son émetteur doit correspondre au fichier, et la liste poppy_domains doit inclure le domaine de l’organisation. Ces vérifications visent à empêcher un domaine sans lien de revendiquer l’émetteur d’une autre entreprise et de recevoir des jetons.

L’agent personnel s’identifie au moyen d’une URL HTTPS client_id qui fournit ses métadonnées client, notamment les clés de signature publiques et les adresses de redirection autorisées. L’entreprise peut exiger une inscription préalable, bloquer ou révoquer l’ID d’un agent et limiter la création de sessions. Le brouillon accorde ces contrôles à l’entreprise ; il ne l’oblige pas à accepter tous les agents.

Une session invitée peut devenir une session de compte

L’agent personnel attribue à son utilisateur un ID stable et opaque propre à chaque entreprise, puis ouvre une session avec une assertion signée. L’entreprise renvoie un jeton de session sans connexion. Elle peut ainsi reconnaître le même agent et le même utilisateur d’une session à l’autre sans considérer la personne comme connectée. Le brouillon interdit de dériver cet ID du nom, de l’adresse e-mail ou du numéro de téléphone, même au moyen d’un hachage avec clé.

Pour l’accès au compte, l’entreprise annonce les méthodes de connexion qu’elle prend en charge. La connexion directe utilise une page d’autorisation OAuth et PKCE dans le navigateur de l’utilisateur. Pour la connexion sur appareil, l’utilisateur visite la page de l’entreprise au moyen d’un lien et d’un code. La connexion médiée permet à l’agent d’envoyer des identifiants fournis par l’utilisateur à un point de terminaison précis de l’entreprise ; cette voie distincte et facultative comporte des règles explicites de traitement des identifiants et de limitation du débit. Le brouillon reconnaît une limite de confiance : l’entreprise ne peut pas toujours vérifier que c’est la personne, et non l’agent, qui a terminé une page de connexion directe.

Les autorisations sont exprimées sous forme de périmètres. Poppy définit des périmètres larges poppy:read et poppy:write périmètres, tout en permettant à l’entreprise d’en proposer de plus étroits et personnalisés. Elle ne peut accorder davantage que ce que l’agent a demandé ou que ce qu’autorise une méthode de connexion donnée. Un jeton de compte, délivré après la connexion, permet à l’agent d’obtenir ensuite des jetons de session authentifiés dans les périmètres approuvés. Si une tâche exige davantage d’accès, l’utilisateur doit se reconnecter pour ces périmètres.

La distinction entre les deux jetons est importante. Un jeton de session est de courte durée et sert aux appels API et aux conversations. Un jeton de compte est un justificatif OAuth d’actualisation à plus longue durée, utilisé uniquement aux points de terminaison de jetons et de révocation de l’entreprise. Le brouillon indique que l’agent doit le tenir à l’écart du contexte du modèle, des messages, des journaux et des URL. La déconnexion révoque le jeton de compte et déconnecte les sessions qui lui sont liées ; l’entreprise peut aussi mettre fin à ces sessions. Les jetons de session déjà délivrés peuvent rester valides : le brouillon conseille donc de vérifier l’état de la session à chaque requête ou d’utiliser des durées de jeton bien plus courtes.

Une session, trois voies possibles

Poppy propose une session unique de l’entreprise pour l’activité d’un utilisateur via son agent personnel. Pour les appels OpenAPI et les conversations avec un agent d’entreprise, l’agent envoie un jeton de session dans l’en-tête d’autorisation. En règle générale, le brouillon lie ces jetons à une clé détenue par l’agent au moyen de preuves DPoP, que l’entreprise vérifie à chaque requête. MCP est une exception explicite : son autorisation utilise un jeton bearer limité au serveur MCP indiqué, et le brouillon n’autorise cette forme que pour les API MCP. Ce sont des exigences du protocole, pas la preuve qu’une implémentation est sûre.

La navigation web rejoint cette même session autrement. Si l’entreprise publie un point de terminaison de session du navigateur, celui de l’agent envoie une assertion signée de courte durée et reçoit le cookie de session propre à l’entreprise. Le site applique ensuite l’état de connexion et les périmètres actuels de la session. Sans ce point de terminaison, l’agent navigue comme un visiteur ordinaire déconnecté. Le récit de lancement de Sierra décrivait une visite entre plusieurs canaux ; le brouillon précise des justificatifs différents pour le trafic du navigateur et des API au sein de cette session partagée.

L’entreprise peut répertorier des descriptions OpenAPI, des serveurs MCP et un point de terminaison de conversation dans son fichier de découverte. Le brouillon décrit un format de conversation Poppy pour échanger avec un agent d’entreprise et faire intervenir une personne si nécessaire. Chaque API définit son propre schéma. L’entreprise choisit les voies qu’elle expose et peut limiter les actions de l’agent, même dans une session connectée.

Ce que le brouillon ne règle pas encore

La page des sujets ouverts du protocole mentionne trois omissions importantes : les paiements, les notifications push lorsqu’aucune requête n’est ouverte et les pièces jointes telles que reçus, étiquettes, images ou formulaires. Elle précise que la liste est incomplète. Les exemples du brouillon utilisent des entreprises fictives et des identifiants de substitution.

Le billet de Sierra du 9 octobre décrit une démonstration en conférence impliquant Muse de Meta et Rocket. Il s’agit du récit de Sierra au sujet d’une démonstration mise en scène, et non d’un audit indépendant d’un déploiement en production. Sierra indique qu’elle organisera des ateliers de conception et publiera une implémentation de référence au cours du mois prochain. Pour l’instant, Poppy est une proposition publiée, détaillée sur le plan de l’implémentation et accompagnée d’une liste croissante de partenaires de conception. Sa portée pratique dépend des entreprises et des créateurs d’agents personnels qui mettront en œuvre des versions compatibles et de l’accès qu’ils offriront réellement.

Sources et références complémentaires

  • Spécification du Personal Agent Protocol, brouillon 0.1, mise à jour le 9 octobre 2026. Source principale des règles de découverte, d’identité, de connexion, de périmètres, de jetons, de sessions et de canaux. Elle autorise explicitement des changements incompatibles avant une version stable ; ses exemples sont fictifs.
  • Sujets ouverts de Poppy, mise à jour le 9 octobre 2026. Liste principale des paiements, notifications push et pièces jointes absents du brouillon actuel ; la page indique que d’autres lacunes peuvent apparaître.
  • Annonce de Sierra du 9 octobre. Établit la date de publication, les 35 partenaires de conception supplémentaires, une démonstration en conférence rapportée et les ateliers/implémentation de référence prévus. Ce sont des déclarations de Sierra, pas des preuves de déploiement.
  • Présentation de Sierra du 6 octobre. Montre ce que proposait l’annonce initiale et ce que change le brouillon technique ultérieur.