● Padrões agênticos · o panorama, mapeado
A delegação só funciona em escala quando é comprovável — quando um agente consegue mostrar o que tem permissão para fazer antes de agir e quem fez o quê, sob a autoridade de quem depois. Estes são os padrões que tornam isso real, o que cada um cobre e como eles se encaixam.
Uma página, um argumento — leia de cima a baixo
Primeiro
O que operamos
O Proof Pair — a especificação aberta que operamos: mandato na entrada, recibo na saída.
Depois
Como lemos o campo
O Agentic Pulse — a narrativa medida contra a realidade, cada número com fonte.
O que revela
Uma faixa que estamos abrindo
Claim Provenance — uma pergunta desocupada que achamos importante, colocada em público como convite.
Dentro de
O mapa inteiro
O panorama e o mercado — cada trilho, e onde a faixa ainda está vazia.
● Nossa especificação de trabalho aberta · v0 · no ar
Mandato na entrada, recibo na saída — delegação comprovável nas duas pontas. Um mandato é autoridade que você pode verificar antes do ato: uma credencial verificável de um humano para um agente — com escopo, prazo de validade e revogável. Um recibo é atribuição que você pode verificar depois dele: um registro assinado e encadeado por hash que vincula a ação ao agente e ao mandato que a autorizou. Uma única especificação, porque todo recibo referencia seu mandato. É isso que operamos, especificado para que você também possa operar.
Leia a especificação — the-aios.org/proof-pair → · aberta, CC-BY 4.0, qualquer pessoa pode implementar
Depois — como lemos o campoÉ isso que operamos. Para situá-lo com honestidade, começamos lendo a economia de agentes como ela realmente é — a história que ela conta, medida contra o que ela consegue mostrar.
Agentic Pulse · narrativa vs. realidade medida
O pulso lê a distância entre a narrativa agêntica — a rodada de captação, o whitepaper, a projeção — e a realidade medida: volume real, status de produção, se a coisa consegue provar quem agiu. O fenômeno que ele revela é o que o campo chama de agent-washing (vender como agente o que não se sustenta como tal). É um diagnóstico, não um placar. Cada número remete a uma fonte nomeada. Onde um valor não tem fonte, aparece [TBD-verify] — nunca um número inventado.
~38% → ~20%
dos executivos confiam em agentes para análises de rotina — mas o número cai para ~20% no momento em que o agente toca uma transação.
Em breve — Sell Trust (2026).
$4.6T
o dimensionamento canônico da economia agêntica — uma projeção top-down da Foundation Capital sobre os salários endereçáveis do trabalho do conhecimento, explicitamente NÃO receita medida. “Um mapa para o ouro, vendido no começo da trilha.”
Foundation Capital — projeção top-down.
Pagamentos de agentes
NarrativaNarrativa de valuation na casa dos bilhões (moldura de ~US$ 7 bi).
Realidade medida~US$ 28.000/dia em volume real e medido.
Consegue provar quem agiu?[TBD-verify]
Fonte: Em breve — Sell Trust (2026). Protocolo deliberadamente não nomeado na fonte.
Autenticação de ferramentas
NarrativaPosicionados como infraestrutura de ferramentas de agentes em produção.
Realidade medida~8.000 servidores varridos; ~40% não tinham nenhuma autenticação.
Consegue provar quem agiu?Entre os servidores que TINHAM autenticação, praticamente nenhum consegue provar quem está do outro lado — “uma chave, sim; uma identidade, não.”
Fonte: arXiv:2605.22333 — “A First Measurement Study on Authentication Security in Real-World Remote MCP Servers” (2026).
Identidade / autorização de agentes
NarrativaEm trilha de rascunho no IETF; posicionado como o padrão de autenticação de agentes.
Realidade medida0 implantações em produção (em 2026-07-06); rascunho IETF rev-09.
Consegue provar quem agiu?Raiz ancorada no DNS do provedor — não em chaves de posse da pessoa.
Fonte: Rascunho público do IETF — AAuth (Dick Hardt); rev-09 em 2026-07-06, atualizar a data se avançar antes da publicação.
Identidade de agentes
NarrativaCaptando com a tese de identidade de agentes; afiliada à Anthropic.
Realidade medidaEstágio de whitepaper; nenhuma produção demonstrada — “captou com um whitepaper.”
Consegue provar quem agiu?[TBD-verify]
Fonte: Avaliação do AIOS Observatory — estágio de whitepaper; nenhuma produção demonstrada até meados de 2026.
● Dinheiro real, para contraste — o piso honesto (não é washing)
O índice também aponta para quem constrói com honestidade. Assim é a receita real e medida de agentes — o piso pelo qual a narrativa deveria ser avaliada, não apenas o teto pelo qual é vendida.
Trabalho de agentes (dinheiro real)
Realidade medida~US$ 100 mi de receita, com preço por “resolução”.
Consegue provar quem agiu?[TBD-verify]
Fonte: Preços públicos / imprensa da empresa.
Trabalho de agentes (dinheiro real)
Realidade medidaUS$ 2,25 a cada 15 minutos (preço público).
Consegue provar quem agiu?[TBD-verify]
Fonte: Preços públicos (Cognition / Devin).
O que revela — uma faixa abertaLer o campo dessa forma revela onde estão as lacunas. Uma delas ainda não tem ninguém ocupando — e não é uma faixa a conquistar, é uma pergunta a abrir.
● Uma faixa aberta · uma pergunta que achamos importante, oferecida, não reivindicada
A prova responde isto é real? Ela não tem resposta para devo desconfiar — e quem, exatamente, está por trás da dúvida? Numa época em que a IA torna a desconfiança coordenada, plausível e incansável mais barata do que nunca, temos uma camada de fatos para o que as coisas são. Não temos nada para quem fabrica dúvida sobre elas.
A primitiva que falta: uma resposta verificável para quem está de fato por trás desta afirmação, desde quando, em coordenação com quem — a detecção de inautenticidade coordenada como infraestrutura pública, não como a caixa-preta privada de confiança e segurança de uma plataforma. Proveniência apontada para quem acusa, não para quem é acusado. Proveniência para a própria suspeita.
Estamos registrando esta pergunta aberta em público — como convite, não como reivindicação. Uma faixa desocupada que achamos importante, nomeada em público para que as pessoas que deveriam construí-la possam encontrá-la — a mesma postura de anfitrião do Proof Pair. A especificação ainda não foi escrita. A de mais ninguém também não, e preferimos ajudar a abrir a faixa a cercá-la. Considere isto uma porta aberta.
Dentro de — o mapa inteiroEssa é a faixa que estamos abrindo. Aqui está o campo inteiro em que ela se insere — cada trilho puxando na mesma direção, e onde a faixa ainda aparece vazia.
● O panorama — 14 trilhos, uma direção
Quem é este agente, e quem responde por ele?
Ethereum
Registros on-chain para identidade, reputação e validação de agentes — trilhos públicos de ancoragem que qualquer framework de agentes pode referenciar. Os registros de identidade e de reputação estão implantados na mainnet do Ethereum; o de validação ainda não, e a própria EIP continua em Draft.
Como se encaixa: DIDs de agentes podem ser registrados em seu registro de identidade, e checkpoints da cadeia de recibos podem ser publicados em seu registro de validação (o caminho de ancoragem planejado para a v0.1 do Proof Pair).
Fonte: EIP-8004 (status: Draft) + repositório oficial de contratos · verificado em 2026-11-02
W3C
O substrato de identidade: identificadores descentralizados mais afirmações verificáveis criptograficamente — o modelo de dados por baixo de todo sistema de credenciais sério. VC Data Model 2.0 e DID Core 1.0 são W3C Recommendations; DID 1.1 é uma Candidate Recommendation.
Como se encaixa: Todo ator no Proof Pair é um DID; um mandato é uma Verifiable Credential. Esta é a camada sobre a qual todo o panorama se apoia.
Fonte: W3C Recommendation — VC Data Model 2.0 (15 de maio de 2025) · verificado em 2026-11-02
O que ele pode fazer, por quem, até quando — e isso pode ser revogado?
IETF (OAuth WG)
Credenciais verificáveis como JWTs, com divulgação seletiva por afirmação e vinculação criptográfica ao portador (KB-JWT). O formato base agora é o RFC 9901; o perfil de VC está em avaliação no IESG.
Como se encaixa: O único formato normativo do mandato no Proof Pair v0 — um agente prova “posso gastar ≤ US$ X para a organização Y” sem revelar todo o seu conjunto de permissões.
Fonte: IETF Datatracker — draft-ietf-oauth-sd-jwt-vc (IESG Evaluation) · verificado em 2026-11-02
OpenID Foundation
Os transportes de emissão e apresentação de credenciais verificáveis — como as credenciais circulam entre emissores, portadores e verificadores via HTTP. Ambas são especificações Final 1.0 (OID4VP em julho de 2025, OID4VCI em setembro de 2025); a adoção ainda está crescendo.
Como se encaixa: Os bindings perfilados do Proof Pair para emitir mandatos e apresentá-los a verificadores HTTP. Carteiras de agentes headless são portadores conformes.
Fonte: OpenID Foundation — OID4VCI 1.0 (Final) · verificado em 2026-11-02
DIF
Mensageria criptografada e independente de transporte entre partes identificadas por DID, com mediadores que enfileiram mensagens para agentes offline. A v2.1 é uma DIF Ratified Specification.
Como se encaixa: O transporte agente-a-agente e de caixa postal: como um agente headless recebe e apresenta mandatos enquanto sua máquina está desligada.
Fonte: DIF — DIDComm Messaging v2.1 (Ratificada) · verificado em 2026-11-02
W3C
Revogação de credenciais em escala — uma forma compacta e que preserva a privacidade para verificadores checarem se uma credencial ainda é válida. W3C Recommendation desde maio de 2025.
Como se encaixa: O único mecanismo normativo de revogação do Proof Pair: um agente comprometido precisa poder ser parado em segundos, não em horas de CRL.
Fonte: W3C Recommendation — Bitstring Status List (15 de maio de 2025) · verificado em 2026-11-02
Ele consegue pagar, e o pagamento pode ser vinculado ao que a pessoa aprovou?
Google → FIDO Alliance
Artefatos assinados de intenção do usuário para o comércio de agentes: Intent Mandates (o que o usuário autorizou o agente a buscar) e Cart Mandates (a transação específica aprovada). O Google o doou à FIDO Alliance em abril de 2026, onde seu Payments Technical Working Group o desenvolve; a versão mais recente é a v0.2.
Como se encaixa: Um mandato do Proof Pair se compila em um Intent/Cart Mandate do AP2 para pagamentos. A diferença: a cadeia de confiança do AP2 termina em uma conta de processador; a do Proof Pair termina em uma raiz humana ou institucional verificável — que é o que a delegação regulada e entre instituições exige.
Fonte: FIDO Alliance — Google doa o AP2 (abr. 2026) · verificado em 2026-11-02
Mastercard
Uma cadeia de credenciais assinadas (SD-JWT em camadas) que prova que a compra de um agente ficou dentro dos limites definidos pela pessoa — valor, comerciante, itens. Publicada em março de 2026 como rascunho aberto (v0.1), mantida pela Mastercard e aberta a contribuições de múltiplas partes.
Como se encaixa: Construída sobre SD-JWT, a mesma família de formato de um mandato do Proof Pair, de modo que os dois podem ser expressos nos termos um do outro. Ela responde à metade de pagamentos da pergunta que o mandato responde de forma geral: a pessoa autorizou isto, dentro destes limites?
Fonte: Especificação Verifiable Intent — README (Rascunho v0.1) · verificado em 2026-11-02
x402 Foundation (Linux Foundation) · incubado pela Coinbase
Pagamento dentro da própria requisição HTTP, usando o status 402 Payment Required, reservado há muito tempo: um cliente ou agente paga por um recurso e o recebe em uma única troca. Lançado pela Coinbase em 2025; hoje governado por um projeto da Linux Foundation com 40 organizações-membro no lançamento, em julho de 2026.
Como se encaixa: Liquida o pagamento; não diz nada sobre quem o autorizou. Essa é a metade que um mandato fornece — a prova de que este gasto foi delegado, por quem, dentro de qual limite.
Fonte: Linux Foundation — lançamento operacional da x402 Foundation (14 de jul. de 2026) · verificado em 2026-11-02
Quem fez o quê, sob a autoridade de quem — e qualquer pessoa consegue verificar?
Coalition for Content Provenance
Manifestos de proveniência assinados e somente de acréscimo para conteúdo de mídia — quem fez isto, com o quê, alterado como. A especificação está na versão 2.5 (outubro de 2026).
Como se encaixa: A fonte do padrão para a cadeia de recibos: a mesma disciplina de manifesto assinado e à prova de adulteração, aplicada a ações de agentes em vez de arquivos de mídia.
Fonte: C2PA — Especificação Técnica 2.5 · verificado em 2026-11-02
Ele consegue provar uma afirmação sem revelar os dados por trás dela?
Privacy & Scaling Explorations · Ethereum Foundation
Prova que você pertence a um grupo sem revelar qual membro você é, com um nullifier que impede o mesmo membro de sinalizar duas vezes. Na quarta versão principal (v4, 2024; versão mais recente em outubro de 2026).
Como se encaixa: Pertencimento sem identidade: um agente poderia mostrar que age em nome de algum membro verificado de uma organização sem revelar qual — a borda da faixa de identidade que preserva a privacidade.
Fonte: Documentação e releases do Semaphore (v4.14.5, out. 2026) · verificado em 2026-11-02
W3C
Divulgação seletiva para credenciais verificáveis com provas derivadas não vinculáveis: o portador revela apenas alguns campos, e duas apresentações da mesma credencial não podem ser correlacionadas. Uma W3C Candidate Recommendation (setembro de 2026).
Como se encaixa: A propriedade de privacidade que o SD-JWT sozinho não oferece: o mesmo mandato apresentado a dois verificadores não pode ser rastreado até um único agente.
Fonte: W3C Candidate Recommendation Draft — vc-di-bbs (10 de set. de 2026) · verificado em 2026-11-02
Campo aberto · EZKL entre os provadores mais usados
Provas de conhecimento zero de que um determinado modelo produziu uma determinada saída, sem revelar os pesos nem as entradas. O ferramental existe e as provas podem ser verificadas on-chain, em um navegador ou em um dispositivo; o custo de gerar provas ainda é alto e ainda não há padrão.
Como se encaixa: Para os recibos, a diferença entre “um agente fez isto” e “este modelo, sob este mandato, fez isto” — comprovável para alguém que não consegue ver o modelo.
Fonte: EZKL — provador zkML aberto (v23.0.5, fev. 2026) · verificado em 2026-11-02
O que o campo diz que é a lacuna.
Anthropic
O enquadramento de segurança publicado em 2026: Zero Trust para agentes significa identidades com raiz criptográfica e permissões com escopo por tarefa — porque os controles de acesso tradicionais não impedem um agente de usar mal permissões que ele detém legitimamente.
Como se encaixa: Nomeia a lacuna que o Proof Pair preenche. A identidade responde quem. Um mandato responde o que este agente pode fazer, por quem, até quando. Um recibo responde quem fez o quê, sob a autoridade de quem.
Fonte: Anthropic — Zero Trust for AI agents (27 de maio de 2026) · verificado em 2026-11-02
● O panorama de identidade de agentes, mapeado
A maioria das comparações de identidade de agentes coloca whitepapers contra whitepapers. Esta é calibrada contra uma implementação de ponta a ponta comprovada — um sistema em funcionamento no qual um agente recebe uma credencial com escopo e vinculada ao dono, apresenta-a a uma contraparte de outra organização sem relação prévia e tem essa credencial verificada criptograficamente na comunicação, com divulgação seletiva e revogação explícita, hoje. O critério aqui é implementado, não proposto.
● A faixa, enunciada primeiro
Esta é a combinação específica que o campo não entregou — uma identidade de agente que seja, ao mesmo tempo, tudo isto:
Nenhuma solução do campo entrega tudo o que está acima. O mapa abaixo mostra onde cada uma para.
● Seis soluções — o que fazem, onde param
Uma distinção crucial atravessa o campo: a maioria delas não são rivais — são pontos de integração. Quatro das seis operam em camadas abaixo ou ao lado da autoridade do agente (onde os agentes rodam, como o tráfego é controlado, quem emite dentro de uma empresa). Só uma ocupa a mesma camada.
Dick Hardt · rascunho IETF
O que fazAutorização delegada para agentes. A tentativa mais direta de resolver o mesmo problema: permitir que um principal conceda autoridade com escopo a um agente. Inclui um padrão de consentimento assíncrono realmente bom (aprovação pendente / adiada).
Onde paraA raiz de confiança está ancorada no DNS do provedor, não em chaves que a pessoa detém — então a autoridade termina em um provedor, não em um humano. Um rascunho em trilha de padronização que, até o momento, não tem implantações em produção. Não é verificável offline.
Rival direto — mesma camada. Mas com raiz em DNS e ainda pré-produção.
tokens de delegação / capacidade · [TBD-verify: confirmar nome completo]
O que fazUm esquema de tokens de capacidade para delegar permissões restritas, com uma regra forte de apenas atenuar: cada salto em uma cadeia de delegação só pode estreitar a autoridade, nunca ampliá-la.
Onde paraResolve a subdelegação com elegância, mas não carrega uma raiz na pessoa, ancoragem governamental nem verificação entre organizações sem infraestrutura compartilhada. Adjacente à faixa, não dentro dela.
Fonte de uma boa ideia — vale adotar a invariante de atenuação; o protocolo não é o mesmo produto.
O que fazIdentidade corporativa para agentes dentro de uma organização / tenant — emitir, listar e governar os próprios agentes de uma organização em escala, com ferramental de ciclo de vida maduro.
Onde paraLimitada à organização que emite. É um emissor intraorganizacional, não um tecido de confiança entre organizações; dois agentes de empresas diferentes não ganham verificabilidade mútua com ele.
Ponto de integração (um emissor com o qual interoperar), com modelos de ciclo de vida com os quais vale aprender. Item a acompanhar: se combinado com um produto de credenciais verificadas para portabilidade entre organizações, a fronteira pode mudar. [TBD-verify: status de GA]
O que fazUma camada de aplicação de políticas para o tráfego de agentes — avalia expressões de política ricas no gateway e permite / nega chamadas. Cloud-native, com boa distribuição.
Onde paraAplica políticas; não estabelece quem é o agente nem de onde veio sua autoridade. Ele precisa de uma autoridade para aplicar.
Ponto de integração — uma credencial com raiz na pessoa é um token padrão que entra em seu motor de políticas com adaptação mínima. Compor, não competir.
O que fazUm runtime de agentes — onde agentes são construídos e executados.
Onde paraExecuta agentes; não diz nada sobre identidade portátil e verificável nem sobre autoridade entre organizações.
Ponto de integração — a camada abaixo da identidade, não um rival dela.
O que fazUm runtime / substrato de agentes — infraestrutura para operar agentes.
Onde paraSubstrato operacional, não uma camada de identidade ou de autoridade.
Ponto de integração — não é um rival.
A contagem: quatro pontos de integração (dois runtimes, uma camada de aplicação de políticas, um emissor intraorganizacional), uma fonte de técnica a adotar e um único rival de verdade na mesma camada — o AAuth — que tem raiz em DNS e ainda não chegou à produção.
● Onde fica a abordagem com raiz na pessoa
Diante desse mapa, a faixa continua aberta. Uma credencial de agente com raiz na pessoa — vinculada ao dono, revogável, com divulgação seletiva, entre organizações, verificável offline e ancorável a uma identidade do mundo real — é a única combinação que ninguém mais monta. O humano detém a chave da qual a autoridade descende: o AAuth tem raiz no DNS, os emissores corporativos têm raiz em um tenant, os runtimes não têm raiz nenhuma. A verificação offline é exclusiva desta abordagem em todo o mapa. Isso não é dizer que todos os outros estão errados — eles resolvem problemas diferentes, e a camada de autoridade que fica acima de todos eles, com raiz em uma pessoa, está desocupada.
● O limite honesto — onde a raiz na pessoa realmente importa
Um mapa de mercado que só lista pontos fortes não tem credibilidade. Uma raiz de confiança de posse da pessoa tem demanda real apenas onde o contexto exige que um humano tenha autorizado algo — atos de governo, mandatos juridicamente vinculantes, transações de cidadãos, consentimento regulado. Onde a autoridade é puramente de máquina para máquina e nenhum humano precisa estar comprovadamente por trás dela, uma raiz de provedor ou um emissor organizacional costuma bastar, e sai mais barato. Então este é tanto o mercado quanto a sua borda: o valor é maior exatamente onde a lei, uma instituição ou a responsabilização exigem que uma pessoa real responda pela ação do agente — e a abordagem deliberadamente não tenta ser o padrão para toda chamada automatizada entre dois serviços. Esse mesmo limite foi alcançado de forma independente por duas análises separadas; a convergência independente sobre a fronteira honesta de um sistema é um sinal de credibilidade, não uma fraqueza.
● Compor, não competir
A posição que buscamos é ser a camada de autoridade sobre a qual todos os outros podem construir — adotando as melhores ideias sem adotar protocolos inteiros: atenuação a cada salto (a subdelegação só pode estreitar a autoridade, nunca ampliá-la), consentimento assíncrono (aprovação adiada / pendente como fluxo de primeira classe) e modelos de ciclo de vida dos emissores corporativos. Um mandato com raiz na pessoa é a fonte da verdade que se traduz nos protocolos de autorização que o ecossistema já usa — aproveitando os trilhos existentes em vez de brigar com eles. A prova de “compor, não competir” é uma integração, não um argumento.
Alinhamento com padrões: construído sobre os padrões abertos para os quais a categoria está convergindo, e interoperando com eles — ERC-8004, AP2, W3C Verifiable Credentials, SD-JWT e OID4VC — para que a composabilidade venha de projeto, não seja um remendo.
● Perguntas em aberto para a categoria
Um mapa de um campo vivo, desenhado com honestidade, pela equipe que mede a categoria em vez de fazer marketing para ela. Comparado com uma implementação de ponta a ponta em funcionamento em meados de 2026; rascunhos de padrões e status de produtos evoluem — afirmações sensíveis ao tempo são verificadas de novo antes da publicação.