A Sierra publicou o rascunho 0.1 do Personal Agent Protocol, ou Poppy, a 9 de outubro, três dias depois de anunciar o projeto com a Meta e outros parceiros. O novo documento transforma a promessa geral do lançamento em regras propostas para encontrar a interface de agente de uma empresa, identificar um agente pessoal, iniciar sessão por um cliente e manter uma visita através de um site, APIs e um agente empresarial.

Continua a ser um rascunho. A especificação diz que qualquer parte pode mudar antes de uma versão estável, incluindo de formas incompatíveis. A Sierra também indicou mais 35 parceiros de conceção. Participar no processo de conceção não demonstra que essas empresas tenham implementado interfaces Poppy.

A grande mudança

  • O que mudou: O anúncio de 6 de outubro descrevia uma forma de os agentes pessoais trabalharem com empresas. O rascunho de 9 de outubro detalha as trocas propostas de identidade, permissões e sessão que uma empresa e um agente teriam de implementar.
  • Porque é importante: Um cliente poderia autorizar um agente a tratar de tarefas da conta, enquanto a empresa identifica o agente e limita o seu acesso. O rascunho associa esse controlo à navegação no site, às APIs e às conversas, embora seja a empresa a escolher os canais e permissões que oferece.
  • O que acompanhar: Os implementadores já dispõem de interfaces concretas para analisar, juntamente com regras ainda por resolver sobre pagamentos, notificações e anexos. A Sierra planeia oficinas de conceção e uma implementação de referência no próximo mês; nenhuma delas constitui ainda prova de ampla interoperabilidade.

A descoberta começa no domínio da empresa

Segundo a especificação preliminar, uma empresa participante publica /.well-known/poppy.json por HTTPS. Esse documento identifica a organização e o emissor OAuth, os métodos de início de sessão suportados e qualquer ponto de acesso a sessões do site, APIs OpenAPI ou MCP, ou ponto de conversa com o agente empresarial que disponibilize. A empresa não tem de oferecer todas as opções. O agente usaria o ficheiro para descobrir o que está disponível, em vez de tratar o site como única porta de entrada.

O ficheiro, por si só, não pode autorizar um agente. O domínio da organização tem de corresponder ao domínio solicitado pelo agente. Este também tem de verificar os metadados do servidor OAuth: o emissor tem de corresponder ao ficheiro e a lista poppy_domains tem de incluir o domínio da organização. Estas verificações destinam-se a impedir que um domínio sem relação reivindique o emissor de outra empresa e receba tokens.

O agente pessoal identifica-se através de um URL HTTPS de client_id que disponibiliza os metadados do cliente, incluindo chaves públicas de assinatura e endereços de redirecionamento permitidos. A empresa pode exigir registo prévio, bloquear ou revogar um ID de agente e limitar a criação de sessões. São controlos concedidos à empresa pelo rascunho; este não exige que todas as empresas aceitem todos os agentes.

Uma sessão de convidado pode tornar-se numa sessão de conta

O agente pessoal atribui ao utilizador um ID estável e opaco, específico de cada empresa, e inicia uma sessão com uma declaração assinada. A empresa devolve um token de sessão sem início de sessão. Isto permite-lhe reconhecer o mesmo agente e utilizador entre sessões sem considerar que a pessoa iniciou sessão. O rascunho proíbe derivar esse ID do nome, endereço de correio eletrónico ou número de telefone, mesmo através de um hash com chave.

Para aceder à conta, a empresa anuncia os métodos de início de sessão suportados. O início de sessão direto usa uma página de autorização OAuth e PKCE no navegador do utilizador. No início de sessão por dispositivo, o utilizador visita a página da empresa através de uma ligação e de um código. O início de sessão mediado permite ao agente enviar credenciais fornecidas pelo utilizador para um ponto de acesso específico da empresa; é uma opção separada e facultativa, com regras explícitas para o tratamento de credenciais e limites de frequência. O rascunho reconhece um limite de confiança: uma empresa nem sempre consegue verificar se foi uma pessoa, e não o agente, que concluiu a página de início de sessão direto.

As permissões são expressas como âmbitos. O Poppy define âmbitos amplos de poppy:read e poppy:write, mas permite à empresa oferecer âmbitos personalizados mais restritos. A empresa não pode conceder mais do que o agente pediu nem mais do que um método de início de sessão específico permite. Um token de conta, emitido após o início de sessão, permite ao agente obter tokens de sessão autenticados posteriores dentro dos âmbitos aprovados. Se uma tarefa precisar de mais acesso, o utilizador tem de iniciar sessão novamente para esses âmbitos.

A distinção entre os dois tokens é importante. Um token de sessão tem curta duração e é usado em chamadas API e conversas. Um token de conta é uma credencial OAuth de atualização, mais duradoura, usada apenas nos pontos de acesso de tokens e revogação da empresa. O rascunho diz que o agente tem de o manter fora do contexto do modelo, das mensagens, dos registos e dos URLs. Terminar sessão revoga o token de conta e termina as sessões associadas; a empresa também pode terminar essas sessões. Os tokens de sessão emitidos anteriormente podem continuar válidos, pelo que o rascunho aconselha as empresas a verificar o estado da sessão em cada pedido ou a usar durações de token muito mais curtas.

Uma sessão, três opções de acesso

O Poppy propõe uma única sessão da empresa para a atividade de um utilizador através do agente pessoal. Para chamadas OpenAPI e conversas com um agente empresarial, o agente envia um token de sessão no cabeçalho de autorização. Normalmente, o rascunho associa esses tokens a uma chave detida pelo agente, com provas DPoP verificadas pela empresa em cada pedido. O MCP é uma exceção explícita: a autorização usa um token bearer limitado ao servidor MCP indicado, e o rascunho só permite essa forma bearer em APIs MCP. São requisitos do protocolo, não uma conclusão de que uma implementação é segura.

A navegação no site entra na mesma sessão de outra forma. Se a empresa publicar um ponto de acesso a sessões do navegador, o navegador do agente envia uma declaração assinada de curta duração e recebe o cookie de sessão da própria empresa. O site aplica então o estado atual de início de sessão e os âmbitos da sessão. Sem esse ponto de acesso, o agente navega como visitante comum sem sessão iniciada. A conta de lançamento da Sierra descreveu uma visita através de canais; o rascunho especifica credenciais diferentes para o tráfego do navegador e da API nessa sessão partilhada.

A empresa pode incluir descrições OpenAPI, servidores MCP e um ponto de acesso a conversas no ficheiro de descoberta. O rascunho descreve um formato de conversa Poppy para falar com um agente empresarial e chamar uma pessoa quando necessário. O esquema de cada API continua a ser definido por essa API. A empresa decide que opções disponibiliza e pode restringir as ações do agente mesmo numa sessão autenticada.

O que o rascunho ainda não resolveu

A página de tópicos em aberto do protocolo enumera três omissões importantes: pagamentos, notificações push quando não há um pedido aberto e anexos, como recibos, etiquetas, imagens ou formulários. A página diz que a lista está incompleta. Os exemplos do rascunho usam empresas fictícias e credenciais substitutas.

A publicação da Sierra de 9 de outubro descreve uma demonstração numa conferência com o Muse da Meta e o Rocket. Trata-se do relato da Sierra sobre uma demonstração encenada, não de uma auditoria independente de uma implementação em produção. A Sierra diz que organizará oficinas de conceção e publicará uma implementação de referência no próximo mês. Por agora, o Poppy é uma proposta publicada com detalhes de implementação e uma lista crescente de parceiros de conceção. O seu alcance prático depende das empresas e dos criadores de agentes pessoais que implementarem versões compatíveis e do acesso que efetivamente oferecerem.

Fontes e leitura adicional

  • Especificação do Personal Agent Protocol, rascunho 0.1, atualizada a 9 de outubro de 2026. Fonte primária para as regras de descoberta, identidade, início de sessão, âmbitos, tokens, sessões e canais. Permite explicitamente alterações incompatíveis antes de uma versão estável; os exemplos são fictícios.
  • Tópicos em aberto do Poppy, atualizada a 9 de outubro de 2026. Lista primária de pagamentos, notificações push e anexos excluídos do rascunho atual; a página diz que podem surgir outras lacunas.
  • Anúncio da Sierra de 9 de outubro. Regista a data de publicação, mais 35 parceiros de conceção, uma demonstração em conferência relatada e oficinas/implementação de referência planeadas. São declarações da Sierra, não provas de implementação.
  • Apresentação da Sierra de 6 de outubro. Mostra o que o anúncio inicial propunha e a diferença introduzida pelo rascunho técnico posterior.