A Pilha Agentica tem Quatro Camadas. A maioria das implantações está perdendo Três

Identidade, reputação, mandato e pagamento precisam viver on-chain. Em muitas implantações de produção, ainda não o fazem, e isso é um problema arquitetônico, não um detalhe de conformidade posterior.

Eu passo muito tempo analisando como as implantações de agentes de produção são realmente conectadas, e o padrão costuma ser o mesmo: o modelo é capaz, e a estrutura de orquestração é razoável, mas a camada de autenticação ainda é uma chave API compartilhada que não é rotacionada há meses.

A infraestrutura de agentes autônomos não acompanhou o ritmo dos modelos que rodam sobre ela. O stack agentico tem quatro componentes que precisam ser nativos da cadeia: identidade, reputação, mandato e pagamento. Na maioria das implantações de produção que vejo, eles ainda são acrescentados depois, se é que existem.

E isso é ainda mais importante em finanças reguladas do que em qualquer outro lugar. Um agente que pode transacionar valores mobiliários tokenizados, aprovar ações de tesouraria ou alocar entre posições precisa ser capaz de mostrar o que foi autorizado a fazer, quem o autorizou, dentro de quais limites e onde o registro on-chain dessa autoridade reside. A maioria das implantações não consegue responder isso de forma clara hoje. Sem esse registro, o próprio agente é o risco de auditoria e conformidade.

Por que chaves API compartilhadas são o primitivo errado

O modelo de autenticação que a maioria das implantações de agentes herda do SaaS é um segredo compartilhado passado em um cabeçalho. Ele autentica o serviço que chama, mas não diz nada sobre o agente específico que está fazendo a chamada, ou o que esse agente tem permissão para fazer, e não deixa nenhum registro que sobreviva à auditoria em uma forma que um regulador possa inspecionar. Cada ação do agente é atribuível apenas a quem possui a chave, o que na prática significa que a atribuição colapsa quando há mais de um agente ou mais de um operador.

A alternativa é a liquidação baseada em assinatura por solicitação. Cada solicitação é assinada pela própria carteira do agente e liquidada criptograficamente no ponto da chamada. É para isso que x402 foi construído, com autenticação e pagamento tratados juntos. Isso fornece às instituições um registro de qual carteira atuou, quando atuou e pelo que pagou, um livro‑razão que pode sobreviver ao escrutínio de auditoria.

A lacuna de identidade

ERC-8004 define identidade on-chain para agentes sem confiança: um registro onde um agente é registrado com uma carteira controladora, um endpoint de serviço e uma referência de modelo. No momento, esse agente é apenas um processo opaco rodando dentro da infraestrutura de um fornecedor. A entrada no registro o torna um ator on-chain de primeira classe com origem verificável — que um contrato inteligente ou painel de conformidade pode verificar diretamente, sem confiar em um intermediário.

A camada de reputação se baseia nisso. Sinais de feedback escritos no registro ERC-8004 são imutáveis, com carimbo de tempo e atribuíveis. Qualquer sistema que queira tomar decisões de confiança sobre um agente pode ler esse registro diretamente. Ao contrário de uma pontuação gerenciada pelo fornecedor ou de uma classificação no Discord, a confiança aqui é uma propriedade da rede, e não de quem controla o banco de dados.

Ambas as camadas são implementáveis hoje sem engenharia exótica. A maioria das implantações não as possui porque o caminho de implementação de menor resistência ainda é tratar os agentes como contas de serviço, em vez de atores de primeira classe. Um atalho razoável em um protótipo torna‑se dívida arquitetural que se acumula na produção.

O problema do mandato é onde finanças reguladas divergem de tudo o mais

Identidade e reputação dizem quem é um agente e como ele se comportou. Elas não estabelecem o que o agente está autorizado a fazer. Em muitos casos de uso de agentes, controles na camada de aplicação podem cobrir essa lacuna. Para agentes que operam com ativos regulados, a questão da autorização torna‑se uma questão legal. A resposta precisa existir em uma forma que possa satisfazer um regulador.

ERC-8226, o Padrão de Mandato de Agente Regulamentado (RAMS), projetado para fechar essa lacuna. O RAMS define uma camada de delegação de conformidade que fica entre a identidade do agente e as estruturas de conformidade ao nível de token. Um principal verificado por KYC concede ao agente um mandato com escopo definido, jurisdição, limites de valor e data de expiração. Na prática, funciona como uma procuração on-chain que pode ser verificada antes da liquidação. O contrato de token regulado então verifica esse mandato de forma atômica dentro de seu hook de conformidade pré‑transferência antes que qualquer liquidação ocorra.

Duas interfaces carregam o design. `ComplianceProvider` é implementada por qualquer operador de KYC ou atestado e garante a elegibilidade do principal para um determinado escopo. `IAgentMandate` é o registro que grava concessões, extensões, revogações, execuções e congelamentos de nível regulatório. A aplicação ocorre através de `recordExecution`, que verifica os limites do mandato ativo no momento da transferência e reverte se a transação os violar.

Essa arquitetura fica entre a identidade ERC-8004 e as estruturas de conformidade de token como ERC-7943, em vez de substituir qualquer uma delas. Identidade indica que o agente existe e é verificável; conformidade de token, que o principal é elegível para possuir esse ativo específico. O RAMS adiciona a parte que nenhuma delas cobre: autoridade desse principal, para esse escopo, dentro desses limites, até essa data. A camada de delegação legalmente executável que atualmente vive apenas em PDFs e planilhas de back‑office migra para on-chain, onde pode realmente ser aplicada no momento da transferência.

A separação entre preparação e execução não é atrito

Uma decisão de design merece uma defesa direta: separar a preparação da transação da assinatura e transmissão. Ela é eliminada em muitos sistemas que tentam tornar os agentes mais integrados.

O instinto é fundir isso em um único passo porque parece mais eficiente. Mas a lacuna entre preparação e transmissão é exatamente onde a supervisão institucional pertence. É onde um oficial de conformidade revisa o que um agente está prestes a fazer antes que a cadeia tome conhecimento, onde a verificação de mandato RAMS valida a carga preparada contra o escopo ativo, limites de valor e jurisdição antes que qualquer assinatura seja produzida, e onde um CFO aprova uma ação de tesouraria que um agente preparou mas ainda não comprometeu.

Muitas instituições que implantam agentes autônomos em escala significativa acabam reconstruindo essa separação quando descobrem que está ausente. Construí‑la como um primitivo arquitetural deliberado, em vez de um retrofit que leva um sistema apenas até sua primeira revisão de conformidade.

Como o stack se parece quando está completo

Quando as quatro camadas estão em vigor, elas se compõem de forma limpa. ERC-8004 ancora a identidade do agente e a reputação on-chain, e ERC-8226 adiciona a camada de mandato que delimita o que cada agente pode fazer e em nome de quem. x402 lida com a liquidação, assinando cada solicitação para que toda ação seja atribuível e auditável. Por baixo, estruturas de ativos regulados como ERC-7943 aplicam a conformidade no momento da transferência contra a elegibilidade do principal e o mandato ativo do agente.

Essas peças estão em diferentes níveis de maturidade, mas nenhuma delas é puramente teórica. ERC-8004 é um ERC de rascunho no Standards Track com primitivas de identidade e reputação implantáveis. ERC-7943 é um padrão final da Ethereum. ERC-8226 está no caminho de padrões, e as interfaces principais são estáveis o suficiente para trabalhos de implementação iniciais. x402 está ativo e já foi projetado em torno de pagamentos HTTP programáticos para humanos e agentes.

As equipes que acertarem isso podem construir esse stack agora ou esperar até que a pressão de auditoria e conformidade force o retrofit. As instituições que acertarem isso serão as que tratam as camadas de mandato e identidade como requisitos de infraestrutura desde o primeiro dia, da mesma forma que tratam KYC e custódia. Os reguladores podem ainda não ter exigido explicitamente cada parte. Equipes que constroem sistemas de produção neste espaço já sabem o quão caro é adicionar esses controles depois.