Sierra Personal Agent Protocol adiciona 35 parceiros, mas as empresas mantêm o controle
A Sierra publicou o rascunho de seu Personal Agent Protocol com 35 novos parceiros de design, transformando o Poppy de uma proposta em um esforço sério de padronização. O Sierra Personal Agent Protocol agora conta com contribuições de OpenAI, Bank of America, Mastercard, PayPal, Visa, Cloudflare e outras grandes empresas.
O anúncio é relevante porque agentes pessoais frequentemente entram em sistemas empresariais por interfaces projetadas para pessoas. Eles navegam por páginas, preenchem formulários e, às vezes, usam credenciais com amplo acesso à conta. O Poppy propõe um caminho intermediário no qual as empresas reconhecem os agentes, os usuários aprovam permissões e uma única sessão pode atravessar sites, APIs e agentes corporativos.
Esse caminho intermediário também cria o conflito central. Agentes pessoais precisam de acesso amplo e consistente para serem úteis, enquanto as empresas querem controlar identidade, permissões, canais e relações com os clientes. A Sierra reuniu um grupo excepcionalmente amplo para negociar essa fronteira. Ainda não demonstrou que essas empresas implantarão o protocolo resultante.
Sierra Personal Agent Protocol adiciona 35 parceiros de design
O Poppy avançou de um anúncio inicial para um rascunho técnico público, mas a participação ainda significa contribuição para o design, e não adoção em produção.
A Sierra lançou o rascunho do Poppy em 9 de outubro de 2026. A empresa também nomeou 35 parceiros de design adicionais abrangendo finanças, varejo, viagens, seguros, mídia, identidade, comunicações e IA.
O novo grupo inclui Adyen, Atomic, Bank of America, BBVA, Chime, Cigna, Cloudflare, Comcast, DIRECTV, ElevenLabs, FOX, Gap Inc., GEICO e Hertz. Também inclui Insurify, Klaviyo, Liberty Mutual, Mastercard, Nordstrom, Notion, Okta, OneSignal, OpenAI, PayPal, Plaid e SiriusXM.
Synchrony, Target, United Airlines, Venmo, Visa, Wells Fargo, Zapier, Zendesk e 1Password completam o grupo adicional. Essas organizações se juntam às empresas envolvidas no anúncio anterior, incluindo Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe e Walmart.
A distinção entre o grupo original e as 35 adições é importante. A Sierra não anunciou 35 participantes no total. Anunciou outras 35 empresas após apresentar o projeto com a Meta e diversos parceiros de tecnologia empresarial em 6 de outubro.
Segundo a Sierra, as novas empresas contribuirão com feedback baseado em seus requisitos de negócio. A lista reúne organizações que normalmente ocupam posições diferentes em uma transação.
Bancos e redes de pagamento gerenciam identidade, fraude, autorização e liquidação. Varejistas controlam estoque, checkout, devoluções e contas de clientes. Provedores de identidade administram a autenticação. Empresas de IA desenvolvem os agentes pessoais que solicitariam acesso.
Seus interesses se sobrepõem, mas não são idênticos. Um desenvolvedor de agentes se beneficia quando uma integração alcança muitas empresas. Um banco se beneficia quando cada ação permanece atribuível, limitada e reversível. Um varejista quer tráfego de agentes sem perder o controle sobre as políticas de serviço ou a relação com o cliente.
É por isso que a lista de parceiros é mais do que uma coleção de logotipos conhecidos. Ela dá à Sierra acesso às partes que precisam concordar sobre os limites entre descoberta, acesso delegado e ações no mundo real.
No entanto, um parceiro de design não é automaticamente um implementador. A Sierra não publicou números de uso em produção, integrações concluídas ou volumes de transações do Poppy. O anúncio estabelece participação no processo de design, e não suporte operacional em todas as empresas nomeadas.
A Sierra afirma que realizará workshops de design e publicará uma implementação de referência no próximo mês. Essas entregas fornecerão um teste mais forte do que a contagem de parceiros. Desenvolvedores precisam de código funcional, ambientes de teste e regras estáveis de conformidade antes de poderem avaliar os custos de implementação.
Portanto, a versão atual muda a credibilidade do protocolo, não sua maturidade. O Poppy agora tem uma especificação pública e um grande conjunto de empresas interessadas. Ele continua sendo o Draft 0.1, com importantes decisões técnicas e de governança ainda em aberto.
Poppy faz da permissão o produto
A principal contribuição do Poppy não é mais um formato de mensagens entre agentes. É um modelo compartilhado de sessão e permissões para agentes que atuam dentro de sistemas controlados por empresas.
A especificação Draft 0.1 define um agente pessoal como software que atua em nome de um usuário. Ela define uma empresa como a organização que permite a esse agente interagir com seus serviços.
Uma empresa participante publica um documento de descoberta em /.well-known/poppy.json. Esse documento identifica a organização e lista suas opções de autenticação, APIs, acesso ao site, agente corporativo e extensões compatíveis.
O padrão se assemelha a outros mecanismos conhecidos de descoberta na web. Em vez de exigir que um desenvolvedor de agentes localize instruções de integração separadas, o Poppy oferece ao agente um único endereço inicial previsível.
A descoberta é apenas a primeira camada. O agente pessoal abre uma sessão para um usuário específico e se identifica perante a empresa. Esse design permite que a empresa diferencie a atividade automatizada de uma pessoa usando o site diretamente.
Uma sessão pode começar sem acesso à conta. Por exemplo, um agente pode verificar se um produto está disponível ou perguntar sobre uma política de devolução como visitante. O usuário faz login quando a tarefa exige informações pessoais da conta ou uma alteração nela.
O Poppy define login direto, login por dispositivo e login mediado. O login direto mantém a autenticação na própria página da empresa. O login por dispositivo permite que o usuário aprove o acesso em outro dispositivo seguindo um link e inserindo um código.
O login mediado permite que um agente envie credenciais para um endpoint definido pela empresa quando ela permite esse método. Essa opção oferece compatibilidade, mas também cria uma das questões de segurança mais sensíveis do rascunho.
Depois de autorizado, o agente recebe acesso delimitado por escopo. O escopo amplo poppy:read abrange a visualização de informações da conta, enquanto poppy:write cobre alterações como trocas ou atualizações de reservas. As empresas podem definir escopos adicionais para atividades mais restritas.
Esses escopos criam uma escala de permissões entre dois extremos insatisfatórios. Uma empresa não precisa bloquear todos os agentes. Um usuário também não precisa conceder a um agente todas as capacidades disponíveis por meio da conta.
A sessão acompanha o usuário pelas interfaces compatíveis. O agente pode transitar entre páginas web, endpoints OpenAPI, servidores MCP e conversas com um agente corporativo. Uma pergunta antes do login e uma alteração posterior na conta podem continuar fazendo parte de uma única visita.
Essa continuidade é importante para ambos os lados. Os usuários evitam explicar repetidamente o mesmo objetivo. As empresas recebem um registro mais coerente de como a sessão avançou pelos canais.
O Poppy também define maneiras de incluir pessoas em uma conversa entre agentes. As mensagens indicam se foram criadas por uma IA ou por um humano. Um agente pessoal pode solicitar um representante humano, enquanto o usuário pode entrar em uma conversa direta sem ler a troca anterior entre os agentes.
Considere um voo cancelado. Um agente pessoal poderia descobrir as interfaces compatíveis de uma companhia aérea, iniciar uma sessão e buscar alternativas sem acesso à conta. O usuário poderia então fazer login, aprovar o acesso à reserva e confirmar um voo substituto.
Um varejista poderia aplicar uma política diferente. Poderia permitir que um agente iniciasse uma devolução, bloqueando ao mesmo tempo alterações nos dados de pagamento salvos. A empresa, e não o agente pessoal, determina quais operações cada permissão libera.
Esse mecanismo explica o apelo do protocolo para as empresas. O Poppy não pede que elas entreguem suas políticas a um agente externo. Ele oferece uma forma padronizada de expor essas políticas e aplicá-las por diversos canais técnicos.
As empresas, não os agentes pessoais, mantêm a vantagem
O protocolo promete escolha ao usuário, mas sua arquitetura dá às empresas participantes controle substancial sobre quais agentes entram e o que podem realizar.
A Sierra apresenta o Poppy como um compromisso entre acesso de agentes e supervisão das empresas. Os usuários escolhem um agente pessoal e aprovam suas permissões de conta. As empresas decidem quais interfaces, métodos de login, escopos e ações oferecem suporte.
Essa divisão parece equilibrada em alto nível. Seu resultado prático dependerá de como as empresas configurarem suas implementações.
Uma empresa pode publicar apenas seu site, somente APIs selecionadas ou um agente corporativo com uma gama limitada de tarefas. Pode oferecer suporte a acesso de leitura sem acesso de escrita. Pode exigir login direto para ações sensíveis e rejeitar agentes que não reconhece.
Portanto, o protocolo padroniza a negociação mais do que o acesso universal. Publicar um arquivo Poppy não exigiria que uma empresa expusesse todas as operações do cliente. Isso informaria aos agentes quais portas existem e quais condições se aplicam.
Esse modelo aborda diretamente um conflito custoso na web atual. As empresas frequentemente tentam detectar automação porque um agente usando uma interface humana pode parecer abuso. Desenvolvedores de agentes então adaptam seus navegadores para continuarem funcionando apesar desses controles.
Nenhum dos lados obtém informações confiáveis desse embate. A empresa pode não saber qual serviço opera o agente ou qual usuário ele representa. O agente pode não saber se uma ação que falhou reflete uma política, autenticação ou uma alteração de interface.
O Poppy substitui parte dessa ambiguidade por identidade e política explícitas. Uma empresa pode reconhecer a identidade de cliente do agente pessoal, associá-la a um usuário e emitir tokens limitados aos escopos aprovados.
Esse arranjo deve facilitar a distinção entre agentes legítimos e automação anônima. Ele não elimina fraude, contas comprometidas, injeção de prompt ou desenvolvedores maliciosos de agentes. Cria evidências mais estruturadas para a aplicação de controles de segurança.
Os usuários ganham escolhas mais claras, mas essas escolhas continuam limitadas pela política da empresa. Uma pessoa não pode conceder a um agente uma capacidade que a empresa nunca expõe. Da mesma forma, uma empresa participante não pode obrigar outra a aceitar seu agente preferido.
Essa é a principal troca envolvida no Sierra Personal Agent Protocol. Descoberta e autorização consistentes podem ampliar o acesso legítimo de agentes. O mesmo design também formaliza o direito de cada empresa de limitar esse acesso.
O equilíbrio pode incentivar a adoção entre organizações reguladas. Bank of America, BBVA, Wells Fargo, Cigna e várias seguradoras enfrentam obrigações que tornam inviável uma automação irrestrita. Elas precisam de auditabilidade e de distinções claras entre ler dados e alterar uma conta.
Empresas de pagamentos têm incentivos semelhantes. Mastercard, Visa, PayPal, Venmo, Adyen, Plaid e Synchrony precisam saber qual parte iniciou uma ação. Também precisam de controles que persistam quando uma interface de IA estiver entre o cliente e a transação.
Para os criadores de agentes pessoais, o compromisso continua atraente se reduzir integrações personalizadas. Um formato de descoberta e um modelo de autorização podem ser valiosos, mesmo quando cada empresa expõe operações de negócio diferentes.
O risco maior é a fragmentação dentro do padrão. As empresas podem definir escopos e extensões personalizados, enquanto cada API mantém seu próprio esquema. Duas organizações podem ambas oferecer suporte ao Poppy e ainda assim exigir trabalhos de implementação muito diferentes.
O Poppy pode padronizar como um agente chega, se identifica e solicita acesso. Ele não pode padronizar automaticamente cada pedido de hipoteca, sinistro de seguro, alteração de voo ou devolução no varejo.
Essa limitação não torna o projeto irrelevante. Ela esclarece onde começa o trabalho difícil. O protocolo pode estabelecer uma porta de entrada comum, enquanto setores e empresas individuais ainda definem o que acontece internamente.
Os Padrões de Agentes Existentes São Insumos, Não Rivais
Poppy é mais crível como uma camada de orquestração que utiliza padrões existentes, e não como substituto de MCP, A2A, OpenAPI ou protocolos de comércio.
Os padrões para agentes hoje abrangem vários limites distintos. Tratá-los como uma disputa em que o vencedor leva tudo obscurece o problema que cada um resolve.
A Anthropic apresentou o Model Context Protocol como uma conexão padronizada entre aplicações de IA e ferramentas ou dados externos. Um servidor MCP pode expor recursos que um cliente de IA descobre e invoca.
O Google desenvolveu originalmente o protocolo A2A para comunicação e colaboração entre agentes independentes. O A2A concentra-se na troca de tarefas, mensagens, artefatos e informações de status entre agentes, além das fronteiras entre fornecedores.
Poppy aborda uma relação mais ampla entre usuário e empresa. Ele cobre descoberta de empresas, identidade do agente pessoal, sessões de usuário, autorização, navegação na web, APIs, conversas entre empresa e agente, e transferências para humanos.
A distinção aparece na arquitetura do Poppy. Uma empresa pode listar um servidor MCP como uma API disponível. Ela também pode listar uma descrição OpenAPI, disponibilizar seu site normal ou expor um agente da empresa.
Portanto, o MCP é uma rota dentro de uma sessão Poppy. O Poppy fornece a identidade, a autorização do usuário e a continuidade entre canais que uma interface de ferramenta, por si só, não define plenamente.
O A2A tem uma relação semelhante. Um agente da empresa e um agente pessoal precisam de uma forma de se comunicar, mas sua conversa é apenas uma parte da visita. O agente pessoal também pode navegar em uma página ou chamar uma API convencional.
Os padrões de comércio criam outra camada. O Universal Commerce Protocol da Shopify e do Google concentra-se em atividades comerciais, como descoberta de produtos, checkout e gestão de pedidos.
A Sierra descreve explicitamente o UCP como complementar. O Poppy pode estabelecer quem o agente representa e o que o usuário autorizou. Um protocolo de comércio pode então definir as operações específicas do domínio envolvidas na compra ou na gestão de um pedido.
Essa abordagem em camadas é prática porque as empresas já possuem pilhas tecnológicas variadas. Um varejista pode expor um fluxo de comércio UCP, um servidor MCP de atendimento ao cliente e páginas web convencionais. O Poppy busca conectar essas superfícies a uma única sessão reconhecida.
A abordagem também evita forçar todos os processos de negócio a conversas de agentes em linguagem natural. APIs estruturadas continuam mais eficientes e previsíveis para muitas operações. O acesso à web pode cobrir sistemas antigos que não têm APIs modernas.
A Sierra afirma que o protocolo se baseia em OAuth, HTTPS, JSON Web Tokens, OpenAPI e MCP. Essas escolhas reduzem a barreira conceitual para equipes familiarizadas com as ferramentas existentes de segurança web e APIs.
O uso de componentes estabelecidos não garante interoperabilidade. O perfil ao redor deles precisa ser suficientemente preciso para que duas implementações independentes se comportem de forma consistente. Ambiguidades sobre públicos de tokens, aplicação de escopos, tentativas e estados de falha ainda podem produzir sistemas incompatíveis.
A implementação de referência do protocolo será importante por esse motivo. Os desenvolvedores precisam de mais do que requisitos escritos. Eles precisam de exemplos testáveis para registro de agentes, validação de descoberta, troca de tokens, sessões de navegador e transferências de conversas.
O mesmo se aplica à conformidade. Se cada empresa interpretar recursos opcionais de forma diferente, os agentes pessoais ainda precisarão de lógica específica para cada organização. Um padrão útil deve identificar quais comportamentos são exigidos para compatibilidade básica.
O amplo grupo de parceiros do Poppy pode ajudar a resolver esses detalhes. Também pode retardar o acordo, porque os participantes representam plataformas concorrentes, ambientes regulatórios e relações com clientes.
O melhor resultado não é um protocolo substituir todos os outros. É uma pilha em que cada camada tem uma responsabilidade clara. O Poppy terá êxito se tornar previsíveis a identidade, a permissão e a continuidade de sessão em toda essa pilha.
O Rascunho Deixa em Aberto Questões Difíceis de Segurança
O Poppy fornece uma estrutura de segurança, mas o Draft 0.1 não elimina os riscos criados quando um software pode agir por meio da conta de um cliente.
A especificação alerta que qualquer parte do Draft 0.1 pode mudar antes de uma versão estável. Esse aviso importa porque erros de autorização nessa camada podem afetar compras, reservas, solicitações financeiras e dados pessoais.
O Poppy usa tokens de sessão de curta duração e vincula solicitações à identidade do agente. Também descreve proteções de prova de posse, nas quais o solicitante prova que detém a chave associada a um token.
Esses controles podem reduzir a repetição de tokens e ajudar as empresas a atribuir atividades automatizadas. Sua eficácia ainda depende de implementações corretas, armazenamento seguro de chaves e validação consistente em cada interface exposta.
As sessões entre canais aumentam a conveniência, mas ampliam a superfície de aplicação. Uma empresa deve aplicar o mesmo estado de conta e os mesmos limites de permissão em suas APIs, endpoints de navegador e conversas com agentes.
Um escopo aplicado em uma API, mas ignorado por uma página web, criaria uma forma de contorná-lo. Um agente da empresa que execute uma ação fora das permissões da sessão criaria outra.
O login mediado merece análise especialmente cuidadosa. Nesse modelo, o agente pessoal lida com as credenciais antes de transmiti-las à empresa. A especificação exige que os agentes protejam campos secretos e evitem exibi-los ou registrá-los em logs.
Esse requisito é útil, mas não pode provar que todos os agentes lidam com credenciais de forma segura. Empresas podem decidir que o login mediado cria uma exposição inaceitável para contas sensíveis.
O login direto oferece uma separação mais clara porque os usuários se autenticam na própria página da empresa. O login por dispositivo pode proporcionar uma separação semelhante quando o agente pessoal opera em outro dispositivo.
O desenho das permissões apresenta outro problema. Os amplos escopos read e write são simples, mas os serviços reais contêm ações com consequências muito diferentes.
Alterar uma preferência de newsletter e alterar um endereço de correspondência são ambas ações de escrita. Devolver uma jaqueta e transferir dinheiro também são ações de escrita. As empresas precisarão de escopos personalizados mais restritos ou de aprovação adicional para operações de alto impacto.
Escopos personalizados melhoram o controle, mas ameaçam a interoperabilidade. Os agentes precisam entender o que cada escopo significa antes de explicá-lo aos usuários. Ações semelhantes podem receber nomes diferentes entre empresas.
A compreensão do usuário é igualmente importante. As pessoas aprovam rotineiramente solicitações de acesso sem examinar seus detalhes. A adição de agentes eleva os riscos, pois uma aprovação pode sustentar ações autônomas repetidas.
Uma interface confiável deve explicar qual agente está solicitando acesso, qual conta ele usará, o que pode ler e o que pode alterar. Ela também deve facilitar a revogação.
O rascunho oferece suporte à revogação e descreve tokens de conta de longa duração para iniciar sessões posteriores. Essa conveniência cria uma relação persistente entre a conta do usuário e o agente pessoal.
Empresas e provedores de agentes precisarão manter registros claros dessas relações. Os usuários devem poder inspecionar conexões ativas, escopos concedidos, ações recentes e datas de expiração.
A injeção de prompt continua fora do controle direto do protocolo. Um agente pode receber instruções maliciosas de uma página web, mensagem ou documento externo. Uma autenticação válida não garante que a decisão resultante do agente corresponda à intenção do usuário.
Essa preocupação é especialmente relevante quando um agente combina informações de várias fontes. Um bom gerenciamento de conhecimento pessoal pode melhorar o contexto, mas mais contexto também exige limites mais fortes em torno da divulgação e da ação.
A confirmação humana pode reduzir o risco em compras, reservas e alterações de conta. No entanto, exigir confirmação para cada pequena etapa prejudicaria a eficiência prometida pelos agentes pessoais.
Portanto, o protocolo precisa de mais do que uma troca segura de tokens. As implementações precisam de aprovação baseada em risco, registros de transações, processos de recuperação e responsabilidade clara quando um agente comete um erro custoso.
Parceiros de design dos setores bancário, de pagamentos, identidade, seguros e segurança em nuvem podem ajudar a testar essas questões sob pressão. Seus nomes, por si só, não as respondem.
Uma revisão independente de segurança será outro sinal importante. Modelos públicos de ameaça, testes de interoperabilidade e falhas documentadas ofereceriam mais evidências do que declarações sobre confiança ou controle.
O Poppy deve ser avaliado pela consistência de seus controles em condições adversariais. Uma demonstração bem-sucedida é útil. Uma falha recuperável costuma ser mais informativa.
Três Sinais Decidirão o Futuro do Poppy
Código funcional, implantações reais em empresas e testes independentes de segurança determinarão se o Poppy se tornará infraestrutura ou continuará sendo um rascunho ambicioso.
O primeiro sinal é a implementação de referência prometida pela Sierra. A empresa diz que planeja publicar uma após workshops de design ao longo do próximo mês.
Uma versão útil deve incluir ambos os lados da interação. Os desenvolvedores precisam de um agente pessoal de exemplo, um serviço de empresa participante, documentos de descoberta, fluxos de autenticação e testes para aplicação de escopos.
A implementação também deve demonstrar falhas. Tokens expirados, acesso revogado, escopos insuficientes, mensagens duplicadas, transferências para humanos e streams interrompidos são condições normais em sistemas de produção.
Código claro e testes de conformidade reforçariam o argumento da Sierra de que as empresas podem implementar o protocolo com ferramentas conhecidas. Um atraso ou uma demonstração restrita e roteirizada enfraqueceria essa alegação.
O segundo sinal é a adoção por parceiros nomeados. Um arquivo poppy.json público em um domínio controlado por um parceiro teria mais peso do que outro anúncio de design.
As primeiras implantações não precisam oferecer suporte a todas as ações. Um varejista poderia começar com perguntas sobre produtos e status de devoluções. Uma companhia aérea poderia expor informações de horários antes de permitir alterações em reservas.
O que importa é se agentes pessoais independentes podem descobrir e usar esses recursos sem uma integração privada. Se o acesso ainda exigir contratos personalizados e comportamentos não documentados, o padrão não terá proporcionado portabilidade.
OpenAI e Meta são especialmente importantes no lado dos agentes pessoais. Sua participação cria a possibilidade de ampla distribuição. Nenhum dos nomes garante que um produto voltado ao consumidor oferecerá suporte ao Poppy.
Bancos, empresas de pagamentos, varejistas e provedores de viagens importam no lado das empresas. Suas escolhas de implantação revelarão quais modelos de autenticação e permissão resistem a revisões regulatórias e de fraude.
O terceiro sinal é a evidência de que o modelo de segurança funciona além de demonstrações controladas. Procure modelos públicos de ameaça, auditorias de terceiros, eventos de interoperabilidade e correções documentadas após os testes.
Um protocolo que permite ações em contas atrairá escrutínio. Isso é saudável. Pesquisadores devem poder testar validação de descoberta, vinculação de tokens, escopos personalizados, sessões de navegador, tratamento de credenciais e defesas contra personificação de agentes.
Esses três sinais se reforçam mutuamente. O código de referência torna os testes possíveis. As implantações reais expõem problemas operacionais. A revisão independente identifica fraquezas antes que elas se espalhem por muitos serviços.
A lista de parceiros dá ao Sierra Personal Agent Protocol uma posição inicial forte. Ela abrange os setores mais afetados quando agentes pessoais deixam de responder perguntas para concluir transações.
Ainda assim, os padrões têm sucesso por meio da implementação repetida, não do impulso gerado por anúncios. As empresas precisam expor capacidades úteis. Os desenvolvedores de agentes precisam oferecer suporte consistente ao protocolo. Os usuários precisam compreender e confiar nas permissões que concedem.
Para os desenvolvedores, a ação imediata é analisar o rascunho e comparar seu modelo de sessão com a arquitetura de autenticação existente. O feedback mais útil abordará incompatibilidades concretas, estados de falha ausentes ou requisitos de segurança pouco claros.
Compradores corporativos devem perguntar aos fornecedores se a participação significa feedback de design, um piloto ou uma implantação comprometida. Esses termos representam níveis de suporte muito diferentes.
Usuários de agentes pessoais devem observar onde o controle realmente aparece. Eles conseguem ver conexões ativas, limitar ações, revisar o histórico e revogar o acesso sem precisar navegar por vários produtos?
Poppy está tentando substituir uma disputa instável entre bloqueio e disfarce de agentes por cooperação explícita. É um objetivo válido. O próximo mês deve mostrar se a Sierra e seus parceiros conseguem transformar esse objetivo em código que outros possam implementar com segurança.
