Voltar as noticias
ATC/1.0 — Especificação Formal para Cartões de Confiança de Agentes
MCP ProtocolAltaEN

ATC/1.0 — Especificação Formal para Cartões de Confiança de Agentes

Dev.to - MCP·9 de agosto de 2026

Há algumas semanas, notei algo desconfortável. Depois que publiquei meu conceito de ATC (Cartão de Confiança do Agente) no dev.to em 13 de julho de 2026 — o primeiro uso público que consigo encontrar desse nome exato com a arquitetura CA + Ed25519 + pontuação de confiança — propostas com o mesmo nome começaram a aparecer no Microsoft AutoGen, OpenAI Cookbook, Continue e outros lugares. Não vou acusar ninguém de copiar — a convergência coincidental na infraestrutura de confiança do agente é plausível, porque o problema é real e óbvio.

Mas aqui está a questão: não importa quem pensou nisso primeiro. O que importa é quem publica uma especificação formal, versionada e testável primeiro.

Então, hoje estou publicando ATC/1.0 — uma especificação aberta para Cartões de Confiança do Agente com:

  • 10 controles (8 obrigatórios, 2 opcionais)
  • JSON Schema para o envelope
  • Implementação de referência em Node.js (usando node:crypto + canonicalize)
  • 5 vetores de teste (mínimo válido, adulterado, expirado, CA errada, amostras de capacidade)
  • Assinaturas RFC 8032 Ed25519
  • RFC 8785 JCS JSON canônico

Está publicado sob uma licença dupla: a especificação em si é aberta (termos W3C CG-FSA para contribuintes), a implementação de referência é MNNC-1.0 (proprietária da AliceLabs) e os vetores de teste são domínio público (CC0).

Se você está construindo um tempo de execução de agente, um servidor MCP, um cliente A2A ou um mercado de agentes — implemente o ATC/1.0. Os testes de conformidade estão no repositório. A implementação de referência passa por todos eles.

Por que publicar uma especificação em vez de apenas defender prioridade

Três razões.

1. Debates de prioridade são impossíveis de vencer em público

Posso provar que minha publicação de 13 de julho é o primeiro uso público de "Cartão de Confiança do Agente (ATC)" com a arquitetura completa. Não posso provar se alguém que publicou trabalhos semelhantes depois viu meu artigo primeiro. A Internet não registra a intenção. Então, uma reivindicação de prioridade se torna um jogo de "eu disse / eles disseram" — e esse jogo é impossível de vencer em público.

Uma especificação, por outro lado, é um fato. Ela existe, é versionada, tem vetores de teste. Você pode executá-la. Isso é muito mais difícil de contestar do que uma reivindicação cronológica.

2. Padrões vencem pela adoção, não pela prioridade

O SSL não venceu porque o Netscape inventou o HTTPS. O SSL venceu porque todos os navegadores o implementaram. O grupo de trabalho do TLS não discutiu sobre quem pensou primeiro na fixação de certificados — eles publicaram a RFC 7469 e deixaram a adoção decidir.

Se o ATC/1.0 se tornar a especificação que Microsoft AutoGen, OpenAI, Cline, Continue e tempos de execução de agentes independentes implementarem, a questão da prioridade se torna irrelevante. A especificação é a resposta.

3. O mercado está convergindo — alguém tem que publicar primeiro

No último mês, vi:

  • Cartão Agente A2A (Google, maio de 2026) — descritor de capacidade, sem confiança criptográfica
  • AgentCards (acadêmico, junho de 2026) — credenciais de identidade + capacidade
  • OpenA2A AIP (Internet-Draft, 22 de julho de 2026) — Ed25519 + confiança comportamental + DID + log de transparência
  • OATI (tópico do GitHub, 29 de julho de 2026) — escopo mais amplo: identidade + autoridade delegada + política + recibos assinados
  • ATC (Edison Flores, 13 de julho de 2026) — primeiro uso público do nome com CA + Ed25519 + revogação + capacidades + pagamento

Todos esses estão convergindo para o mesmo problema de ângulos diferentes. Isso não é uma ameaça — isso é validação de mercado. A janela está aberta. Alguém tem que publicar a especificação formal.

O que o ATC/1.0 especifica

Os 10 controles

# ID Nome Obrigatório?
1 ATC-001 Identidade ✅ Obrigatório
2 ATC-002 Atestação (Ed25519 + vinculação CA) ✅ Obrigatório
3 ATC-003 Capacidades (sistema de arquivos / rede / shell / credenciais / processo) ✅ Obrigatório
4 ATC-004 Prova (saída do pipeline de auditoria) ✅ Obrigatório
5 ATC-005 Risco (pontuação de confiança 0-10 + nível de risco + autoridade de decisão) ✅ Obrigatório
6 ATC-006 Assinatura (Ed25519 sobre a forma canônica JCS RFC 8785) ✅ Obrigatório
7 ATC-007 Revogação (OCSP / CRL / lista simple_json) ✅ Obrigatório
8 ATC-008 Expiração (issued_at + expires_at + max_ttl_days) ✅ Obrigatório
9 ATC-009 Delegação (cartão pai → cartão filho com restrição de capacidade) Opcional
10 ATC-010 Confiança em Tempo de Execução (sinais comportamentais, detecção de desvio) Opcional

O núcleo criptográfico

O ATC/1.0 exige:

  • Ed25519 (RFC 8032) para assinaturas — rápido, determinístico, bem suportado na biblioteca padrão de todas as linguagens
  • RFC 8785 JCS para JSON canônico — o único padrão real para codificação JSON determinística
  • SHA-256 para o hash do payload (registrado em signed_payload_hash para que os verificadores possam detectar adulterações antes de verificar a assinatura)

O processo de assinatura é um pouco sutil por causa de um dilema: o campo signed_payload_hash faz parte do envelope, mas não pode ser parte do payload assinado (você não pode hash algo que inclui seu próprio hash). A especificação resolve isso definindo tanto signature = "" QUANTO signed_payload_hash = "" antes de canonizar — então computando o hash, depois assinando, e então armazenando ambos os valores.

O manifesto de capacidade

O ATC-003 declara o que um agente está autorizado a fazer em 5 categorias:

  • Sistema de Arquivos (leitura: nenhum/diretorio_próprio/diretorio_temporário/diretorio_inicial/sistema/todos; escrita: mesmo enum)
  • Rede (egress: nenhum/lista_permitida/todos; ingress: nenhum/portas_vinculadas/todos)
  • Shell (execução: nenhum/sandboxed/sem restrições; spawn: mesmo)
  • Credenciais (leitura_env: nenhum/lista_permitida/todos; leitura_arquivos: mesmo)
  • Processo (subprocesso: nenhum/sandboxed/sem restrições; sinais: nenhum/próprio/todos)

Isso mapeia diretamente o que a Folha de Dicas MCP da OWASP exige em declarações de capacidade. O ATC/1.0 é o formato concreto para isso.

Semântica da pontuação de confiança

O ATC-005 carrega uma trust_score de 0 (não confiável) a 10 (altamente confiável), além de um risk_level derivado:

  • 8-10 → baixo
  • 5-7 → médio
  • 2-4 → alto
  • 0-1 → crítico

Crucialmente, o ATC-005 exige decision_authority: "consumer" — o que significa que o ATC carrega uma recomendação, mas o tempo de execução que hospeda o agente consumidor toma a decisão final de confiança. Esta é uma escolha de design deliberada. A CA não substitui a política de segurança do tempo de execução.

Revogação

O ATC-007 suporta três métodos de verificação de revogação:

  • ocsp — OCSP RFC 6960, para implantações de alta segurança
  • crl — Lista de Revogação de Certificados RFC 5280
  • simple_json — uma lista JSON assinada pela CA, para implantações de baixa fricção (isso é o que o Mercado
Contexto Triplo Up

A especificação ATC/1.0 é crucial para empresas que desenvolvem infraestruturas de agentes, pois estabelece um padrão formal que pode ser adotado amplamente. Isso pode facilitar a interoperabilidade e a confiança entre diferentes sistemas de agentes, impactando positivamente a segurança e a eficiência operacional.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.