Edição Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Rascunho do Poppy mostra como os agentes pessoais poderiam aceder a contas empresariais

> O rascunho do Poppy publicado pela Sierra a 9 de outubro define regras propostas de descoberta, início de sessão e sessões para agentes pessoais que trabalham com empresas. Os controlos de segurança e as lacunas por resolver são mais importantes do que a lista alargada de parceiros de conceçã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.

A Sierra publicou [o rascunho 0.1 do Personal Agent Protocol](https://personalagentprotocol.org/docs/spec), ou Poppy, a 9 de outubro, três dias depois de [anunciar o projeto com a Meta e outros parceiros](https://sierra.ai/blog/introducing-personal-agent-protocol). 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](https://sierra.ai/kr/blog/poppy). 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](https://personalagentprotocol.org/docs/spec), 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](https://sierra.ai/blog/introducing-personal-agent-protocol) 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](https://personalagentprotocol.org/docs/open-topics) 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](https://sierra.ai/kr/blog/poppy). 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](https://personalagentprotocol.org/docs/spec), 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](https://personalagentprotocol.org/docs/open-topics), 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](https://sierra.ai/kr/blog/poppy). 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](https://sierra.ai/blog/introducing-personal-agent-protocol). Mostra o que o anúncio inicial propunha e a diferença introduzida pelo rascunho técnico posterior.

## Sources

- [Especificação do Personal Agent Protocol (rascunho 0.1)](https://personalagentprotocol.org/docs/spec) — Texto principal das regras de descoberta, identidade, sessão, início de sessão, âmbitos, tokens, navegador, API e conversas; avisa explicitamente sobre futuras alterações incompatíveis e exemplos fictícios.
- [Tópicos em aberto do Poppy](https://personalagentprotocol.org/docs/open-topics) — Identifica pagamentos, notificações push e anexos como omissões importantes; a lista não está completa.
- [Partilha de um rascunho do Personal Agent Protocol](https://sierra.ai/kr/blog/poppy) — Relato da Sierra sobre a publicação, mais 35 parceiros de conceção, a demonstração no Summit e as oficinas/implementação de referência planeadas; não é prova independente de implementação.
- [Apresentação do Personal Agent Protocol](https://sierra.ai/blog/introducing-personal-agent-protocol) — Anúncio inicial e modelo de controlo pretendido para utilizadores e empresas, usados para identificar a evolução de 9 de outubro.