Se anunció un proyecto de estándar, no una especificación terminada
El 6 de octubre de 2026, Meta y Sierra anunciaron que desarrollan Personal Agent Protocol con socios del sector. El objetivo es dar a los agentes personales de IA una forma uniforme de trabajar con empresas y permitir que estas vean que actúa un agente, a quién representa y qué operaciones puede realizar. Es un anuncio de desarrollo: el texto de la versión 0.1 aún no se ha publicado. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026]
Según el diseño descrito, el agente descubre primero las funciones disponibles en la web de la empresa e inicia una sesión para el usuario. El modo de invitado podría bastar para consultar existencias o la política de devoluciones. Las tareas de cuenta requerirían que el cliente iniciara sesión en la página de la empresa o usara credenciales configuradas previamente y eligiera permisos de lectura o escritura. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026]
La sesión utilizaría OAuth y se conservaría al pasar entre la web convencional, las API y el agente conversacional de la empresa. Sierra planea publicar la versión 0.1 más adelante en octubre, celebrar talleres y después liberar una implementación de referencia. Los permisos precisos, las notificaciones y los pagos son extensiones posibles, no funciones disponibles. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [2 · IETF RFC 6749 · marco de autorización OAuth 2.0]
Qué cambiaría para un comercio electrónico
El proyecto busca sustituir la automatización opaca del navegador por una delegación explícita. En vez de que un agente pulse los mismos controles que una persona, el comercio podría declarar los canales compatibles y distinguir la consulta del catálogo de las acciones sobre una cuenta. Es una base para controlar pedidos, devoluciones y servicio, pero todavía no garantiza interoperabilidad. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026]
Dividir únicamente entre lectura y escritura es demasiado amplio para una tienda real. Los permisos deben separarse por operación: ver pedidos, crear una cesta, cambiar una dirección, cancelar un pedido no enviado, abrir una devolución o confirmar una compra. La práctica actual de OAuth exige los privilegios mínimos y tokens restringidos a recursos y acciones concretos. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]
Una sesión continua entre web, API y agente empresarial puede conservar el contexto, pero amplía la superficie de error. El comercio necesitará un registro único de quién autorizó, a qué agente, durante cuánto tiempo, qué se modificó y cómo revertirlo. El anuncio todavía no define el formato de auditoría ni el proceso de impugnación. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]
Cómo preparar un piloto sin exponer pedidos reales demasiado pronto
El primer paso seguro es un entorno aislado y de solo lectura: existencias, estado de entrega y reglas de devolución sin datos personales ni cambios de pedido. La escritura debe usar permisos separados, vigencia corta, revocación inmediata y nueva confirmación para dinero, direcciones, cancelaciones y devoluciones. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]
Un token de corta duración no basta. Las recomendaciones de OAuth aconsejan vincularlo al emisor, limitarlo a un servidor concreto e impedir su reutilización. En un ecosistema abierto de agentes son especialmente importantes la autenticación del cliente, la protección de redirecciones y que el agente no reciba la contraseña del comprador. [2 · IETF RFC 6749 · marco de autorización OAuth 2.0] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]
El piloto debe medir finalización sin ayuda humana, cambios erróneos, cancelaciones, contactos con soporte, tiempo de revocación e intentos de superar el alcance autorizado, no solo el volumen de sesiones. Hasta que exista la versión 0.1, la integración debería limitarse a observación y prototipo, sin acceso de agentes desconocidos a pedidos de producción. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]
Fuentes
- Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026 — Descripción oficial del proyecto, las funciones del consumidor y la empresa, los canales, OAuth, el calendario de la versión 0.1 y posibles extensiones futuras.
- IETF RFC 6749 · marco de autorización OAuth 2.0 — Base normativa de la autorización delegada: tokens restringidos, ámbitos y separación entre cliente, servidor de autorización y servidor de recursos.
- IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0 — Práctica vigente para despliegues dinámicos de OAuth, incluido el mínimo privilegio, la restricción de audiencia y la protección frente a la reutilización de tokens.
Comentario experto
El valor principal del proyecto no está en la inteligencia del agente, sino en la frontera de la relación entre comprador y comercio. Cuando un programa actúa por una persona, la empresa debe separar la intención del cliente de la decisión propia del modelo. La propuesta intenta hacer explícita la representación: el agente declara a quién representa y la empresa controla las acciones permitidas. Por ahora es una intención arquitectónica porque falta la versión 0.1. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026]
OAuth es una base razonable. Ya separa propietario del recurso, cliente, servidor de autorización y recurso protegido, y permite tokens más estrechos que la autorización original. Pero OAuth por sí solo no aporta interoperabilidad. Su especificación básica advierte que los numerosos componentes opcionales producen implementaciones distintas; el nuevo protocolo deberá precisar registro, descubrimiento y significado de los permisos. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [2 · IETF RFC 6749 · marco de autorización OAuth 2.0]
El mínimo privilegio decidirá si el diseño sirve para el comercio. “Escritura” no debe cubrir de igual modo añadir a la cesta, cambiar una dirección y confirmar un pago. El primer error es barato de revertir; el segundo arriesga la entrega y el tercero crea una disputa financiera. La guía actual de OAuth pide restringir tokens a recursos y acciones; la futura especificación debe convertirlo en una interfaz comprensible. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]
El efecto competitivo dependerá de la apertura de la implementación. Las grandes plataformas pueden incorporar antes el descubrimiento y los permisos; los pequeños comercios probablemente recibirán soporte mediante plataformas comerciales y proveedores de pagos. Pruebas públicas de conformidad y código de referencia reducirían integraciones únicas. Perfiles divergentes crearían otra familia de conectores incompatibles. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [2 · IETF RFC 6749 · marco de autorización OAuth 2.0]
La relación con el cliente necesita una traza verificable de la delegación: qué pidió la persona, qué eligió el agente, qué permiso comprobó el comercio y cómo se revierte el resultado. Es crucial en devoluciones y servicio posventa, donde el contexto cambia después del pago. El anuncio promete continuidad entre canales, pero no define el registro, la responsabilidad por errores ni el mecanismo de corrección. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]
La propuesta podrá evaluarse tras la versión 0.1 y la implementación de referencia. Las métricas son implementaciones independientes compatibles, tareas sin intervención humana, errores de alcance, velocidad de revocación, incidentes con tokens e impugnaciones resueltas. Los pagos no forman parte de un lanzamiento: solo son una posible extensión. Hasta entonces, Personal Agent Protocol es una propuesta prometedora, no un estándar operativo del sector. [1 · Sierra · anuncio de Personal Agent Protocol · 6 de octubre de 2026] [3 · IETF RFC 9700 · práctica actual de seguridad para OAuth 2.0]