AI-translated from English; not yet reviewed by a fluent editor. # El borrador de Poppy explica cómo los agentes personales podrían acceder a cuentas de empresas > El borrador de Poppy que Sierra publicó el 9 de octubre plantea reglas de descubrimiento, inicio de sesión y sesiones para agentes personales que trabajan con empresas. Sus controles de seguridad y cuestiones pendientes importan más que la ampliada lista de socios de diseño. By BIG CHANGE Editorial Published: 2026-10-10T12:09:58.334Z Updated: 2026-10-10T12:09:58.334Z Canonical: https://bigchange.ai/blog/poppy-personal-agent-protocol-draft-sessions-permissions ![Conceptual illustration of a visitor holding a blank-screen phone outside an open office doorway while an employee listens and gestures from inside.](https://bigchange.ai/api/media/file/poppy-office-threshold-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. The scene is illustrative only and does not depict an actual Poppy workflow or verified deployment. Sierra publicó [el borrador 0.1 del Protocolo de Agentes Personales](https://personalagentprotocol.org/docs/spec), o Poppy, el 9 de octubre, tres días después de [anunciar el proyecto con Meta y otros socios](https://sierra.ai/blog/introducing-personal-agent-protocol). El nuevo documento convierte la promesa general del lanzamiento en reglas propuestas para encontrar la interfaz de agentes de una empresa, identificar a un agente personal, iniciar la sesión de un cliente y mantener una visita entre un sitio web, API y agente de la empresa. Sigue siendo un borrador. La especificación dice que cualquier parte puede cambiar antes de una versión estable, incluso de forma incompatible. Sierra también [nombró a 35 socios de diseño adicionales](https://sierra.ai/kr/blog/poppy). Participar en el proceso de diseño no demuestra que esas empresas hayan desplegado interfaces Poppy. ## El gran cambio - **Qué cambió:** El anuncio del 6 de octubre describía una forma para que los agentes personales trabajaran con empresas. El borrador del 9 de octubre detalla los intercambios propuestos de identidad, permisos y sesiones que tendrían que implementar una empresa y un agente. - **Por qué importa:** Un cliente podría autorizar a un agente a realizar tareas de cuenta mientras la empresa identifica al agente y limita su acceso. El borrador conecta ese control con la navegación web, las API y las conversaciones, aunque cada empresa elige qué canales y permisos ofrecer. - **Qué observar:** Quienes lo implementen ya tienen interfaces concretas que examinar, junto con reglas de pagos, notificaciones y archivos adjuntos aún pendientes. Sierra planea talleres de diseño y una implementación de referencia durante el próximo mes; por ahora, ninguno demuestra que exista una interoperabilidad amplia. ## El descubrimiento comienza en el dominio de la empresa Según la [especificación del borrador](https://personalagentprotocol.org/docs/spec), una empresa participante publica `/.well-known/poppy.json` mediante HTTPS. Ese documento indica su organización y emisor de OAuth, los métodos de inicio de sesión compatibles y cualquier endpoint de sesión web, API de OpenAPI o MCP, o endpoint de conversación con el agente de la empresa que ofrezca. No es necesario ofrecer todas las rutas. El agente usaría el archivo para descubrir las opciones disponibles en vez de considerar el sitio web como su única entrada. El archivo por sí solo no autoriza a un agente. El dominio de la organización debe coincidir con el dominio que pidió el agente. Este también debe comprobar los metadatos del servidor OAuth: el emisor debe coincidir con el archivo, y su lista de `poppy_domains` debe incluir el dominio de la organización. Esas comprobaciones buscan impedir que un dominio ajeno reclame el emisor de otra empresa y reciba tokens. El agente personal se identifica mediante una URL HTTPS de `client_id` que sirve sus metadatos de cliente, incluidas las claves públicas de firma y las direcciones de redirección permitidas. La empresa puede exigir el registro previo, bloquear o revocar un ID de agente y limitar la creación de sesiones. Son controles que el borrador concede a la empresa; no obliga a aceptar todos los agentes. ## Una sesión de invitado puede convertirse en una sesión de cuenta El agente personal asigna a su usuario un ID estable y opaco, específico para cada empresa, e inicia una sesión con una aserción firmada. La empresa devuelve un token de sesión sin iniciar sesión. Así puede reconocer al mismo agente y usuario entre sesiones sin considerar que la persona ha iniciado sesión. El borrador prohíbe derivar ese ID de usuario de un nombre, correo electrónico o número de teléfono, incluso mediante un hash con clave. Para acceder a una cuenta, la empresa anuncia los métodos de inicio de sesión que admite. El inicio directo usa una página de autorización OAuth y PKCE en el navegador del usuario. El inicio mediante dispositivo pide al usuario que visite la página de la empresa con un enlace y un código. El inicio mediado permite que el agente envíe las credenciales que le dio el usuario a un endpoint específico de la empresa; es una opción separada y voluntaria, con reglas explícitas para gestionar credenciales y limitar la frecuencia. El borrador reconoce un límite de confianza: una empresa no siempre puede verificar que haya sido la persona, y no el agente, quien completó una página de inicio directo. Los permisos se expresan como ámbitos. Poppy define ámbitos amplios de `poppy:read` y `poppy:write` , aunque permite que una empresa ofrezca ámbitos personalizados más limitados. La empresa no puede conceder más de lo que pidió el agente ni más de lo que permite un método concreto de inicio de sesión. Un token de cuenta, emitido tras iniciar sesión, permite al agente obtener tokens posteriores de sesión iniciada dentro de los ámbitos aprobados. Si una tarea necesita más acceso, el usuario debe volver a iniciar sesión para esos ámbitos. La diferencia entre los dos tokens importa. El token de sesión dura poco y se usa para llamadas a API y conversaciones. El token de cuenta es una credencial OAuth de actualización de mayor duración que solo se usa en los endpoints de tokens y revocación de la empresa. El borrador dice que el agente debe mantenerlo fuera del contexto del modelo, mensajes, registros y URL. Al cerrar sesión se revoca el token de cuenta y se cierran las sesiones vinculadas; la empresa también puede terminar esas sesiones. Los tokens de sesión emitidos anteriormente podrían seguir siendo válidos, por lo que el borrador aconseja comprobar el estado de sesión en cada solicitud o usar tokens con una duración mucho menor. ## Una sesión, tres rutas posibles Poppy propone una única sesión de empresa para la actividad del usuario a través del agente personal. Para llamadas OpenAPI y conversaciones con el agente de la empresa, el agente envía un token de sesión en el encabezado de autorización. Por lo general, el borrador vincula esos tokens a una clave que conserva el agente mediante pruebas DPoP, que la empresa verifica en cada solicitud. MCP es una excepción explícita: su autorización usa un token bearer restringido al servidor MCP indicado, y el borrador solo permite esa forma bearer para API MCP. Son requisitos del protocolo, no una conclusión de que una implementación sea segura. La navegación web se incorpora a la misma sesión de otra manera. Si una empresa publica un endpoint de sesión de navegador, el navegador del agente envía una aserción firmada de corta duración y recibe la cookie de sesión de la empresa. El sitio web aplica entonces el estado actual de inicio de sesión y los ámbitos de la sesión. Sin ese endpoint, el agente navega como un visitante normal que no ha iniciado sesión. La [cuenta del lanzamiento de Sierra](https://sierra.ai/blog/introducing-personal-agent-protocol) describió una visita entre canales; el borrador especifica credenciales distintas para el navegador y el tráfico de API dentro de esa sesión compartida. La empresa puede incluir descripciones OpenAPI, servidores MCP y un endpoint de conversación en su archivo de descubrimiento. El borrador describe un formato de conversación Poppy para hablar con un agente de la empresa e incorporar a una persona cuando sea necesario. Cada API conserva su propio esquema. La empresa decide qué rutas expone y puede limitar lo que hace un agente incluso durante una sesión iniciada. ## Qué aún no resuelve el borrador La página de [temas pendientes](https://personalagentprotocol.org/docs/open-topics) del protocolo enumera tres omisiones importantes: pagos, notificaciones push cuando no hay una solicitud abierta y archivos adjuntos como recibos, etiquetas, imágenes o formularios. La página dice que la lista está incompleta. Los ejemplos del borrador usan empresas ficticias y credenciales de marcador de posición. La publicación de Sierra del 9 de octubre describe una [demostración en una conferencia con Muse de Meta y Rocket](https://sierra.ai/kr/blog/poppy). Es el relato de Sierra sobre una demostración preparada, no una auditoría independiente de un despliegue en producción. Sierra dice que organizará talleres de diseño y publicará una implementación de referencia durante el próximo mes. Por ahora, Poppy es una propuesta publicada con detalles de implementación y una lista creciente de socios de diseño. Su alcance práctico dependerá de qué empresas y desarrolladores de agentes personales implementen versiones compatibles y del acceso que realmente ofrezcan. ## Fuentes y lecturas adicionales - [Especificación del Protocolo de Agentes Personales, borrador 0.1](https://personalagentprotocol.org/docs/spec), actualizada el 9 de octubre de 2026. Fuente principal de las reglas de descubrimiento, identidad, inicio de sesión, ámbitos, tokens, sesiones y canales. Permite explícitamente cambios incompatibles antes de una versión estable; sus ejemplos son ficticios. - [Temas pendientes de Poppy](https://personalagentprotocol.org/docs/open-topics), actualizado el 9 de octubre de 2026. Lista principal de pagos, notificaciones push y archivos adjuntos que quedan fuera del borrador actual; la página advierte que pueden surgir otras carencias. - [Anuncio de Sierra del 9 de octubre](https://sierra.ai/kr/blog/poppy). Establece la fecha de publicación, los 35 socios de diseño adicionales, una demostración en una conferencia según Sierra y los talleres/implementación de referencia previstos. Son declaraciones de Sierra, no pruebas de despliegue. - [Introducción de Sierra del 6 de octubre](https://sierra.ai/blog/introducing-personal-agent-protocol). Muestra la propuesta del anuncio inicial y qué cambió con el borrador técnico posterior. ## Sources - [Especificación del Protocolo de Agentes Personales (borrador 0.1)](https://personalagentprotocol.org/docs/spec) — Texto principal de las reglas de descubrimiento, identidad, sesiones, inicio de sesión, ámbitos, tokens, navegador, API y conversaciones; advierte expresamente que puede haber cambios incompatibles y que los ejemplos son ficticios. - [Temas pendientes de Poppy](https://personalagentprotocol.org/docs/open-topics) — Nombra los pagos, las notificaciones push y los archivos adjuntos como omisiones importantes; la lista no está completa. - [Compartir un borrador del Protocolo de Agentes Personales](https://sierra.ai/kr/blog/poppy) — Relato de Sierra sobre la publicación, los 35 socios de diseño adicionales, la demostración en Summit y los talleres/implementación de referencia previstos; no es evidencia independiente de despliegue. - [Presentación del Protocolo de Agentes Personales](https://sierra.ai/blog/introducing-personal-agent-protocol) — Anuncio inicial y modelo previsto de control del usuario y la empresa, utilizado para identificar el avance del 9 de octubre.