Agent Name Service da Linux Foundation: identidade de agentes de IA ancorada em DNS e quando adotá-la

O Agent Name Service (ANS) da Linux Foundation é um padrão aberto que dá aos agentes de IA nomes versionados e ancorados em DNS, certificados de identidade emitidos após validação de domínio e entradas em logs públicos de transparência. Por que um líder de TI deveria se importar? Agentes de IA agora chamam outros agentes, solicitam dados e disparam transações que atravessam as fronteiras entre organizações. Ninguém sabe dizer ainda se o ANS se tornará o esquema dominante.

O que é o Agent Name Service e por que ele está na Linux Foundation?

Em 10 de novembro de 2026, a Linux Foundation acolheu o Agent Name Service como padrão aberto para identidade confiável, verificação e descoberta de agentes de IA usando a infraestrutura de DNS já existente. A especificação completa reúne sete documentos que cobrem nomenclatura ancorada em domínio, registro e versionamento, publicação em DNS, auditoria de logs públicos, monitoramento de integridade e autenticação entre agentes. O comitê técnico diretor do projeto passa agora a desenvolvê-lo de forma aberta.

Desde que a intenção de lançamento foi anunciada em junho de 2026, 11 organizações contribuíram com o padrão ou o adotaram, entre elas Cisco, Cloudflare, DigiCert, GoDaddy, Infoblox, Salesforce e OWASP.

O ANS nasceu na GoDaddy. A equipe decidiu construir a descoberta de agentes sobre o DNS, que segundo a GoDaddy processa mais de cem milhões de requisições por segundo, e estabelecer confiança por meio da mesma PKI que protege toda conexão HTTPS. A implementação reaproveita a infraestrutura de DNS da GoDaddy e um serviço de certificados que gerencia mais de 100 milhões de certificados SSL e TLS ativos.

Para compradores corporativos, o que realmente conta é a mudança de governança. Uma especificação pública sob uma fundação neutra oferece uma base mais firme para redigir políticas. O CEO da Linux Foundation, Jim Zemlin, foi direto: agentes de IA autônomos estão realizando transações em sistemas globais, mas não conseguem ter sucesso sem identidade verificável.

Por que a identidade de agentes de IA virou um problema de governança de TI

A pressão já é visível dentro das organizações. Uma pesquisa da Cloud Security Alliance com 418 profissionais de TI e segurança, encomendada pela Token Security e publicada em abril de 2026, constatou que 82% das organizações haviam descoberto agentes de IA rodando em sua infraestrutura sem que ninguém soubesse. A mesma pesquisa revelou que 65% haviam sofrido um incidente de segurança relacionado a agentes nos 12 meses anteriores. Entre as organizações que tiveram esse tipo de incidente, 61% relataram exposição de dados e 35% relataram perdas financeiras. Esses dois números são proporções dos 65% que tiveram incidente, não de todos os respondentes.

Leia a pesquisa com duas ressalvas em mente. Ela foi encomendada por um fornecedor e mede mais a visibilidade interna do que a identidade externa. Ainda assim, mostra que a proliferação de agentes é um problema operacional atual, e não hipotético.

O lado externo fica mais fácil de visualizar com o cenário descrito no rascunho ANS v2 do IETF. O agente de pagamentos de uma empresa recebe a instrução de transferir US$ 50.000 para o agente de faturamento de um fornecedor, e esse agente de faturamento apresenta a URL de um site protegida por um certificado TLS. Esse certificado informa ao agente de pagamentos que alguém controla o domínio. Para um sistema prestes a enviar dinheiro por conta própria, o controle de domínio é uma evidência frágil.

Como o ANS funciona: nomes versionados, certificados validados e logs de transparência

O ANS parte de mecanismos que qualquer pessoa que opera infraestrutura web já conhece e acrescenta níveis de verificação por cima deles.

Nomes ans:// versionados

Cada agente recebe um nome versionado no estilo DNS, como ans://v1.0.0.my-agent.example.com. Leia da direita para a esquerda. O domínio (example.com) vincula o agente a uma organização, o rótulo (my-agent) identifica o agente e o prefixo (v1.0.0) fixa uma versão semântica. Uma URL comum não tem nada parecido com essa última parte. Com o ANS, uma mudança no agente pode aparecer como uma mudança no seu nome.

O rascunho ANS v2 limita o ANSName completo a 400 octetos, o que deixa folga para o transporte seguro em cabeçalhos HTTP, campos TLS e colunas de banco de dados. Seus sistemas atuais podem armazenar e transmitir esses nomes sem tratamento especial.

Certificados de identidade após validação DNS/ACME

Um certificado de identidade ANS só é emitido após a validação de domínio via DNS/ACME. Do ponto de vista operacional, nada disso é novo. O porém, ao qual voltaremos nas ressalvas, é que a identidade de um agente nunca pode ser mais forte do que o controle de domínio que a sustenta.

Log público de transparência

Cada registro também gera uma entrada em um log público de transparência, de modo que qualquer parte pode verificar de forma independente a identidade, as capacidades e o histórico de um agente sem precisar confiar em um intermediário.

Níveis de verificação Bronze, Silver e Gold

O rascunho ANS v2 define três níveis de verificação, Bronze (PKI), Silver (PKI mais DANE) e Gold (PKI mais DANE mais log de transparência), para que os clientes possam escolher níveis de garantia adequados ao risco de cada transação. O DANE vincula informações de certificado a registros DNS e depende do DNSSEC. Guarde essa dependência; ela volta mais adiante.

A coluna da direita é uma recomendação nossa e não faz parte da especificação. Defina seus próprios limites.

Como o ANS se relaciona com o DNS-AID e o AGNTCY Directory

O ANS não é o único projeto de agentes baseado em DNS na Linux Foundation. O DNS-AID, um projeto separado voltado à descoberta descentralizada de agentes, foi lançado com os membros iniciais Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Infoblox, Internet Systems Consortium e WWT.

Os dois projetos respondem a perguntas diferentes. O rascunho do DNS-AID afirma que os consumidores devem tratar os registros DNS-AID como um transporte verificável de metadados, e não como um sinal de confiança por si só, e que os julgamentos de confiança devem ser feitos fora de banda, combinando esses registros com sistemas de reputação, atestação ou políticas organizacionais. O ANS é um candidato a essa camada de identidade. Ele funciona ao lado do DNS-AID; não o substitui.

O projeto AGNTCY Directory mostra por que o ANS vem despertando interesse. Um épico em aberto nesse projeto acompanha a verificação de declarações de identidade ans:// e observa que todos os outros esquemas exigem que o publicador hospede material de chave, como um arquivo JWKS, um registro TXT ou um documento DID, e quase ninguém faz isso, então nada é verificado. Um registro ANS já gera um certificado de identidade, um ponteiro DNS e uma entrada no log de transparência. Em outras palavras, a evidência existe por padrão, em vez de depender de trabalho extra dos publicadores.

O campo ainda está concorrido. Em junho de 2026, o The New Stack contou pelo menos quatro iniciativas baseadas em DNS, incluindo o DNS-AID da Infoblox, e a Infoblox agora também apoia o ANS. Uma proposta concorrente, o DNSid, é um Internet-Draft individual de um único autor, sem adoção por nenhum grupo de trabalho, e sua versão atual expira em 31 de dezembro de 2026.

Quando registrar seus próprios agentes: a escada Anchor-Version-Tier da Optijara

O nome descreve a sequência: ancorar (Anchor) cada agente a um domínio que você vai manter, versioná-lo (Version) em sintonia com seus lançamentos e atribuir a cada caso de uso um nível de verificação (Tier). Cada degrau depende do anterior, então a ordem importa. Este é um modelo de planejamento, não um relato de resultados de clientes.

1. Inventarie e classifique. Liste todos os agentes que você executa e marque cada um como somente interno, voltado a parceiros, público ou transacional. Considerando quantas organizações encontram agentes que desconheciam, espere surpresas aqui.
2. Comece pelos agentes externos e de alto impacto. Registre primeiro os agentes que são chamados pelos agentes de outras organizações, além de tudo o que envolva pagamentos, compartilhamento de dados ou ações contratuais. Agentes somente internos podem esperar, já que seus controles atuais de identidade e acesso já os cobrem.
3. Anchor: escolha o domínio de propósito. Use um domínio de marca que você manterá por anos, não um domínio de campanha. Trate a expiração de um domínio de marca como um evento de segurança, porque a autoridade de registro revoga os registros quando a validação de domínio falha.
4. Version: associe nomes a lançamentos. Vincule a versão semântica de cada nome ans:// ao seu processo de lançamento. Qualquer mudança relevante em prompts, ferramentas, modelos ou permissões deve gerar uma nova versão e uma nova entrada no log.
5. Faça um piloto fora da produção. Execute primeiro o registro e a verificação em um ambiente de testes e leia a ressalva sobre maturidade abaixo antes que qualquer decisão de confiança em produção dependa do ANS.
6. Tier: defina níveis de garantia e responsáveis. Decida o nível-alvo para cada caso de uso e nomeie responsáveis pela renovação de certificados, pelos registros DNS e pelo monitoramento do log de transparência. Torne essas mesmas pessoas responsáveis pelos segredos que cada agente guarda. Saber quem é um agente não limita em nada o que ele pode acessar, e padrões como um proxy de credenciais que mantém chaves de API fora dos agentes de IA cuidam dessa camada separada.

Como usar identidades ANS em compras e em listas de permissão em tempo de execução

Em compras

O ANS dá às equipes de compras um vocabulário concreto para a identidade de agentes. Perguntas que vale a pena fazer aos fornecedores:

• Seus agentes têm nomes ans:// e qual domínio os ancora?
• Qual nível de verificação vocês conseguem suportar hoje: Bronze, Silver ou Gold?
• A zona de ancoragem é assinada com DNSSEC, de modo que as verificações DANE tenham valor?
• Como as versões dos agentes se relacionam com os lançamentos do produto e os registros de alterações?
• Quem na sua organização é responsável pela renovação de domínios e pelo acesso ao registrador?

Os contratos devem exigir aviso prévio antes de mudanças de versão de agentes que alterem capacidades e antes de qualquer troca de domínio de ancoragem ou de registrador. São esses os eventos que mudam aquilo que você de fato aprovou.

Uma matriz de decisão de fornecedores

Para organizar as respostas dos fornecedores, usamos uma matriz simples baseada em três sinais. Assim como o mapeamento de níveis, ela reflete nossa visão e não faz parte da especificação.

Um fornecedor que esteja na primeira coluna nos três sinais é candidato a fluxos de pagamento ou de dados regulados. Qualquer resposta na coluna da direita deve manter os agentes desse fornecedor em interações de baixo risco, no nível Bronze, até que a situação mude. Respostas mistas geralmente indicam um piloto com critérios de saída claros.

Em tempo de execução

Em tempo de execução, o degrau Tier vira uma regra de aplicação. Inclua agentes na lista de permissão pelo ANSName versionado completo mais as verificações de certificado, nunca apenas pela URL ou pelo domínio. Se você ignorar a versão, um agente significativamente alterado herda a aprovação que você deu a uma versão anterior. Exija Gold, incluindo a verificação do log de transparência, para ações de alto risco como pagamentos, e aceite Bronze apenas para consultas de baixo risco. Isso segue a própria intenção do rascunho de que os clientes ajustem a garantia ao risco da transação.

A verificação Gold não vai deter um agente corretamente identificado que comece a se comportar mal. Combine seus requisitos de Gold com uma forma testada de interromper um agente rapidamente e revise o que um kill switch de IA interrompe e o que o seu runbook de agentes ainda precisa ter.

Combine as verificações do ANS com seus próprios controles de política e reputação. O princípio fora de banda do rascunho do DNS-AID também se aplica aqui: a evidência de identidade alimenta uma decisão, mas não é a decisão. Monitore os logs de transparência em busca de registros inesperados sob seus próprios domínios e fique atento a registros em domínios parecidos com os seus, já que quem detém um domínio semelhante pode registrar nele um agente totalmente verificado.

Se a sua preocupação são assistentes de IA acessando suas próprias propriedades web, e não chamadas entre agentes, você precisa de outro conjunto de controles; veja nosso guia sobre como permitir, limitar ou bloquear assistentes de IA no seu site.

Ressalvas e críticas a considerar antes de se comprometer

Confiança herdada do DNS

A análise da Cloud Security Alliance aponta o DNSSEC como a dependência em que o ANS mais se apoia para tornar evidentes adulterações nos vínculos entre nomes e chaves. Duas décadas após sua introdução, o DNSSEC é validado em cerca de um terço dos caminhos de resolução, mas assinado criptograficamente em apenas cerca de sete por cento das zonas. Assim, as garantias Silver e Gold dependem de a contraparte ter feito um trabalho de DNSSEC que muitas organizações nunca priorizaram. Verifique suas próprias zonas antes de prometer aos parceiros um nível que você não consegue entregar.

Maturidade

Na revisão da Cloud Security Alliance de junho de 2026, o projeto ainda estava em fase anterior à versão 1.0, e sua implementação de referência usava criptografia simulada para demonstração, e não uma PKI de nível de produção. Criptografia simulada serve para aprender. Não serve para dinheiro. A governança da fundação pode acelerar o amadurecimento, mas confira o status atual diretamente na organização do projeto no GitHub em vez de presumi-lo.

Incentivos dos registradores

Um comentário no CircleID resume o debate sem rodeios: todo agente precisa de um nome, e o setor de domínios gostaria de vendê-lo. É uma lente justa. Registradores e autoridades certificadoras de fato se beneficiam quando cada agente precisa de um domínio e de um certificado. Nada disso torna o design errado. Mas significa que você deve avaliar custos de registro, condições de renovação e portabilidade pelos próprios méritos, sem presumir que algum registrador seja o único caminho.

Domínios semelhantes e impostores verificados

A verificação vincula um agente a um domínio. Ela não consegue dizer se o domínio pertence a quem você imagina. O ANS não resolve o typosquatting, e um agente totalmente verificado em um domínio semelhante continua sendo um impostor. O monitoramento de marca e as verificações na integração de contrapartes continuam sendo responsabilidade sua.

A visão equilibrada

Os pontos positivos são reais. A especificação é pública e distribuída em sete documentos. Onze organizações dos setores de redes, segurança, certificados e SaaS contribuíram com ela ou a adotaram. Na nossa visão, esse apoio somado à governança neutra dá ao ANS uma posição de partida mais forte do que propostas de um único fornecedor ou de um único autor. Como vários esquemas baseados em DNS ainda competem entre si, coloque as verificações de identidade de agentes atrás de uma camada interna de abstração quando isso for barato, para que uma mudança no esquema vencedor não obrigue você a reescrever todas as integrações. O argumento é por uma adoção em etapas, não por evitar o padrão.