Linux Foundation lança o Agent Name Service para a identidade de agentes de IA

A Linux Foundation anunciou em 10 de novembro de 2026 que o Agent Name Service (ANS) foi oficialmente lançado como projeto da fundação, levando identidade ancorada em domínios, descoberta e autenticação a agentes de IA por meio de uma especificação aberta e ferramentas de código aberto.

O ANS foi desenvolvido para permitir que um sistema identifique com qual agente registrado está interagindo antes de aplicar sua própria política de segurança. Ele vincula um nome versionado a um domínio controlado pelo operador do agente, usa o Domain Name System (DNS) para publicar informações de descoberta e registra eventos do ciclo de vida assinados em um registro de transparência. A abordagem reutiliza a infraestrutura existente da internet, em vez de exigir um registro proprietário único de agentes.

O lançamento transforma o anúncio de intenção da fundação, feito em 23 de junho de 2026, em um projeto sujeito a governança. A fundação informa que 11 organizações contribuíram para o ANS ou o adotaram desde então: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP e Trustmodel.ai.

Como funcionam o registro e a autenticação no ANS

A especificação de sete camadas abrange identidade, registro, nomenclatura versionada, publicação via DNS, transparência, monitoramento de integridade e autenticação de agentes. Um nome ANS vincula uma versão a um domínio, como em ans://v1.0.0.payments.example.com; uma nova versão exige um novo registro.

Durante o registro, o operador envia o host do agente, a versão, os endpoints e o material de certificados a uma Autoridade de Registro, que verifica o controle do domínio e as provas exigidas. O operador publica os registros DNS recebidos, e a autoridade os verifica antes da ativação. Em seguida, ela assina o evento do ciclo de vida e solicita ao Registro de Transparência que o sele, gerando artefatos públicos que vinculam o registro a certificados autorizados.

Os pares usam um perfil de descoberta compatível para localizar endpoints e o _ans-badge registro compartilhado para encontrar evidências de transparência. A descoberta, por si só, não autentica quem faz a chamada. A autenticação exige três verificações: o certificado está vinculado à identidade registrada, o registro continua válido e quem faz a chamada possui a chave privada correspondente.

A minuta de autenticação ANS-6 confere o mesmo status ao TLS mútuo (mTLS) e à prova de posse demonstrável (DPoP) na camada de aplicação. O mTLS é adequado a um percurso TLS de ponta a ponta, enquanto o DPoP vincula uma prova de uso único a uma solicitação HTTP e pode funcionar por gateways que encerram o TLS. Um verificador de nível de selo consulta o Registro de Transparência em busca de evidências atuais; o nível SCITT verifica localmente um recibo e um token de status, sem chamadas de rede a cada solicitação. O DPoP exige o vínculo SCITT.

Software e interoperabilidade inicial

O software disponível inclui uma implementação de referência em Go da Autoridade de Registro, do Registro de Transparência e de um verificador offline, além de SDKs para Go, Rust e Java, com APIs e cobertura de recursos diferentes. A ans-cli ferramenta é compatível com registro, descoberta, gerenciamento de certificados e consultas ao Registro de Transparência no macOS, Linux e Windows. O guia de início rápido local usa chaves de desenvolvimento e um noop verificador de DNS, o que significa que uma verificação de recibo bem-sucedida não testa o DNS público, a emissão de certificados de produção nem uma implantação em produção.

Em relação à interoperabilidade, a Linux Foundation informa que o Agent Directory Service da AGNTCY é compatível com a verificação de identidades ANS e que o ANS Finder implementa o Agentic Resource Discovery (ARD) e passa nos testes de conformidade do registro. A especificação própria do ARD trata da descoberta antes da invocação, e não da execução, e permite a existência de vários serviços de descoberta com diferentes políticas de confiança, classificação e acesso, em vez de prescrever um catálogo centralizado. Esse trabalho conecta evidências de identidade verificáveis à descoberta sem criar um diretório universal de agentes.

Minutas de especificações e limites de segurança

O comitê técnico diretor inicial tem cinco membros com direito a voto: Scott Courtney, Keith Perry e Connor Snitker, da GoDaddy; Ken Huang, da DistributedApps.AI; e Michael Kantor, da Hashgraph Online. O comitê define a direção técnica, enquanto os responsáveis pela manutenção dos repositórios analisam alterações, gerenciam lançamentos e tratam de relatos de segurança. Embora o comunicado de lançamento descreva a especificação como formalizada, a documentação do projeto classifica as especificações publicadas como minutas em desenvolvimento ativo; a ANS-6 está identificada como DRAFT v1.0, versão 0.2.0, datada de 3 de novembro de 2026.

O modelo de segurança estabelece identidade, não permissões. Autorização, delegação ao longo de uma cadeia de chamadas e pontuação de confiança estão fora do escopo da ANS-6, cabendo a cada aplicação decidir o que um agente autenticado pode fazer. Os resumos criptográficos de metadados selados não atestam o código em execução em uma máquina remota nem garantem o comportamento do agente, e os clientes ainda precisam de chaves confiáveis do registro, verificação correta de assinaturas e provas, verificações de atualidade e uma política para lidar com falhas. Selos públicos, recibos e tokens de status também podem ser reproduzidos se o verificador não verificar a posse.

Um recibo comprova o histórico do log, não a validade atual, e ainda pode ser usado para verificar informações mesmo depois que um agente é revogado; por isso, deve ser acompanhado de uma consulta ao status atual. A maturidade das integrações também varia. O trabalho com o NVIDIA OpenShell é classificado como uma prévia de pesquisa, e suas verificações de registro de destinos não implementam a vinculação do ANS-6 ao certificado real do par TLS.

O ANS agora conta com governança de uma fundação, minutas publicadas e implementações de referência. Seu valor prático para a segurança depende de as implantações aplicarem em conjunto a identidade, o status atual e a posse da chave, sem incluir na declaração de identidade a autorização nem avaliações sobre o comportamento do agente.