De OpenClaw a Agentor: Construindo AI Agents Seguros em Rust

Fomos contratados para auditar a seguranca de um framework open-source de AI agents. O cliente queria a garantia de que sua infraestrutura de agentes -- que manipulava dados sensiveis atraves de multiplos provedores de LLM -- atendia aos padroes exigidos para um deployment enterprise. O que comecou como um trabalho de seguranca rotineiro se tornou o catalisador para construir algo completamente novo. O framework tinha boas intencoes, era popular no GitHub e ativamente mantido. Mas quanto mais aprofundavamos, mais claro ficava: os problemas nao eram bugs para corrigir. Eram decisoes de arquitetura incrustadas nos alicerces.

O que encontramos: Os limites dos frameworks de agentes baseados em Python

O framework que auditamos seguia um padrao comum no ecossistema de agentes baseados em Python. Os agentes executavam ferramentas gerando subprocessos ou chamando funcoes diretamente dentro do mesmo processo Python. Nao havia sandboxing: uma ferramenta com um bug ou uma injecao de prompt maliciosa podia acessar o filesystem, fazer requisicoes de rede ou ler variaveis de ambiente contendo API keys. Em um de nossos testes, demonstramos que um prompt cuidadosamente construido podia fazer com que um agente exfiltrasse credenciais armazenadas em memoria por outro agente rodando no mesmo processo.

O overhead do runtime agravava os problemas de seguranca. O Global Interpreter Lock do Python significava que a orquestracao multi-agente era fundamentalmente single-threaded. Os tempos de cold start variavam de 2 a 5 segundos dependendo da arvore de dependencias. O consumo de memoria para um unico agente com um conjunto modesto de ferramentas ficava em torno de 200-400MB: gerenciavel para uma demo, proibitivo quando voce roda dezenas de agentes em producao. E cada reinicializacao do agente recarregava toda a cadeia de dependencias porque o Python nao tem conceito de compilacao ahead-of-time para esse tipo de carga de trabalho.

As implicacoes de conformidade regulatoria foram a preocupacao final. A tipagem dinamica significava que os dados fluindo pela pipeline do agente nao tinham garantias em tempo de compilacao sobre sua forma ou conteudo. Informacoes pessoais identificaveis podiam passar por middleware de logging sem ser detectadas porque nao havia enforcement a nivel de tipos. Atingir a conformidade GDPR exigia envolver cada ponto de acesso a dados em verificacoes de runtime: verificacoes faceis de esquecer, impossiveis de aplicar sistematicamente e invisiveis para a analise estatica. Para uma organizacao certificada ISO 27001 como a nossa, recomendar esse framework para uso em producao nao era uma opcao.

A decisao: Construir do zero em Rust

Nosso primeiro instinto foi contribuir com patches upstream. Redigimos uma proposta para uma camada de sandbox, isolamento de memoria entre agentes e um sistema de passagem de mensagens tipado. Mas quanto mais definiamos o escopo das mudancas, mais claro ficava que nao estavamos propondo melhorias: estavamos propondo uma reescrita. A arquitetura de plugins do framework pressupunha acesso direto a memoria entre componentes. O modelo de execucao de ferramentas era construido em torno do sistema de imports do Python. Adicionar isolamento depois do fato quebraria cada extensao existente e anularia o proposito do ecossistema.

Escolhemos Rust por razoes que iam alem de seguir uma tendencia. Nossa equipe havia passado dois anos escrevendo smart contracts para a blockchain Stellar usando Soroban: contratos em Rust que compilam para WASM e executam em um ambiente sandboxed. Entendiamos o modelo de ownership do Rust, seu ecossistema async e, criticamente, sua capacidade de compilar para WebAssembly. Cada propriedade que precisavamos para um framework seguro de agentes -- seguranca de memoria sem garbage collection, abstracoes de custo zero, limpeza deterministica de recursos e um alvo de compilacao WASM -- Rust fornecia nativamente.

A decisao nao foi tomada de animo leve. Rust tem uma curva de aprendizado mais ingreme que Python, o ecossistema para tooling de IA e mais jovem e a velocidade de desenvolvimento nas primeiras semanas foi mais lenta. Mas estavamos construindo infraestrutura que iria rodar em producao por anos, manipulando dados sensiveis em industrias regulamentadas. O investimento inicial em corretude renderia dividendos a cada dia que o sistema rodasse sem um incidente de seguranca.

Arquitetura do Agentor: 13 crates, uma missao

O Agentor e estruturado como um workspace Rust com 13 crates, cada um com uma unica responsabilidade e limites bem definidos. Nao e um monolito dividido em pastas: cada crate compila independentemente, tem sua propria suite de testes e expoe uma API publica atraves do sistema de modulos do Rust. As dependencias entre crates sao explicitas e aplicadas pelo compilador. Se um crate nao precisa de acesso ao filesystem, simplesmente nao depende de std::fs, e nenhuma astucio em runtime pode mudar isso.

• agentor-core -- Gerenciamento do ciclo de vida do agente, roteamento de mensagens e as definicoes de traits que cada outro crate implementa. E a espinha dorsal: define o que e um agente, como os agentes se comunicam e como o sistema orquestra fluxos de trabalho multi-agente.
• agentor-runtime -- O runtime async baseado em Tokio que gerencia a execucao dos agentes, limites de recursos e shutdown graceful. Gerencia backpressure, priorizacao de tarefas e garante que nenhum agente possa privar outros de CPU ou memoria.
• agentor-providers -- Camada de abstracao de provedores LLM com suporte para OpenAI, Anthropic e modelos locais atraves de um trait unificado. Trocar de provedor requer mudar um valor de configuracao, nao reescrever codigo.
• agentor-tools -- Framework de definicao e execucao de ferramentas com type checking em tempo de compilacao. Cada ferramenta declara seus inputs, outputs e permissoes necessarias como tipos Rust.
• agentor-mcp -- Implementacao completa do Model Context Protocol, permitindo que agentes Agentor interoperem com qualquer sistema compativel com MCP.
• agentor-sandbox -- A camada de isolamento WASM. Cada execucao de ferramenta acontece dentro de uma instancia WASM sandboxed com grants de capability explicitos.
• agentor-cli -- Interface de linha de comando para criar, executar e gerenciar projetos de agentes. Scaffolda novos projetos, roda servidores de desenvolvimento local e gerencia deployments.
• agentor-codegen -- Pipeline de geracao de codigo com transformacoes AST-aware, coordenacao multi-arquivo e verificacao de compilacao integrada.
• agentor-config -- Gerenciamento de configuracao com defaults sensiveis ao ambiente, tratamento de segredos e validacao.
• agentor-telemetry -- Logging estruturado, tracing distribuido e coleta de metricas com compatibilidade OpenTelemetry.
• agentor-auth -- Autenticacao e autorizacao para comunicacao agente-a-agente e agente-a-servico.
• agentor-storage -- Gerenciamento de estado persistente com backends plugaveis (SQLite, PostgreSQL, in-memory).
• agentor-testing -- Utilitarios de teste, providers mock e snapshot testing para comportamentos de agentes.

WASM Sandbox: Seguranca por design

A camada de sandbox e a decisao arquitetural que diferencia o Agentor de toda alternativa baseada em Python. Quando um agente invoca uma ferramenta -- seja ler um arquivo, fazer uma requisicao HTTP ou executar codigo gerado -- essa ferramenta roda dentro de uma instancia WASM isolada. A instancia nao tem acesso ao filesystem do host, nao tem capacidades de rede e nao compartilha memoria com outras ferramentas ou com o processo host. O acesso a qualquer recurso deve ser explicitamente concedido atraves de um sistema de capabilities definido no momento do deployment.

Cada instancia WASM roda com limites de memoria configuraveis e timeouts de execucao. Se uma ferramenta tenta alocar mais memoria do que o permitido, a instancia e terminada: nao o agente, nao o runtime, apenas aquela invocacao individual da ferramenta. Se uma ferramenta excede seu timeout de execucao, ela e eliminada de forma limpa com output diagnostico completo. Isso e fundamentalmente diferente da abordagem do Python de gerar subprocessos e esperar que se comportem bem. No Agentor nao ha esperanca: as restricoes sao aplicadas pelo runtime WASM no nivel de instrucao.

O impacto pratico e significativo. No framework que auditamos, um ataque de injecao de prompt que fizesse uma ferramenta executar codigo arbitrario podia comprometer todo o sistema. No Agentor, o mesmo ataque fica contido em uma instancia WASM sandboxed sem capabilities: pode computar, mas nao pode se comunicar, persistir ou acessar nada fora do seu sandbox. O raio de impacto de qualquer incidente de seguranca se reduz de 'comprometimento total do sistema' para 'uma invocacao de ferramenta retornou um erro.'

Otimizado para geracao de codigo

Este e o nucleo de por que o Agentor existe e o que o torna diferente de frameworks que tratam a geracao de codigo como apenas mais uma ferramenta. O Agentor foi construido do zero para ser o runtime da geracao de codigo impulsionada por IA: nao geracao de texto que por acaso produz codigo, mas uma pipeline estruturada que entende codigo como um artefato de primeira classe com sintaxe, semantica e dependencias.

A pipeline comeca com desenvolvimento dirigido por especificacoes. Antes de um agente gerar uma unica linha de codigo, ele produz uma especificacao estruturada: os arquivos a serem criados ou modificados, as interfaces que devem implementar, as dependencias que requerem e os testes que validarao a corretude. Essa especificacao nao e uma sugestao: e um contrato que a pipeline de geracao aplica. Se o codigo gerado nao corresponde a spec, a pipeline o rejeita antes de chegar ao filesystem.

A coordenacao de output multi-arquivo e onde a maioria das ferramentas de geracao de codigo falha. Gerar uma unica funcao e simples. Gerar um modulo com cinco arquivos que se importam mutuamente, implementam interfaces compartilhadas e devem compilar juntos e uma ordem de grandeza mais dificil. O crate codegen do Agentor mantem um grafo de dependencias de todos os arquivos em um batch de geracao, garante que os imports se resolvam corretamente entre arquivos e valida que o output completo compile como uma unidade antes de escrever qualquer coisa em disco.

As transformacoes AST-aware substituem a substituicao de texto ingenue que a maioria dos frameworks usa. Quando o Agentor modifica codigo existente, ele analisa o fonte em uma arvore sintatica abstrata, aplica transformacoes no nivel semantico e regenera o fonte. Isso significa que adicionar um metodo a uma classe nao quebra a formatacao, inserir um import nao duplica um existente e renomear uma funcao atualiza todos os sites de chamada. A diferenca entre substituicao de texto e transformacao AST e a diferenca entre uma ferramenta de buscar e substituir e um compilador: um deles entende o codigo.

A pipeline de testes integrada fecha o ciclo. Cada ciclo de geracao segue a mesma sequencia: gerar, compilar, testar, iterar. Se o codigo gerado nao compila, o Agentor captura os erros do compilador, os envia de volta ao LLM com o contexto relevante e solicita uma versao corrigida, automaticamente, sem intervencao humana. Se o codigo compila mas os testes falham, o output dos testes segue o mesmo loop de feedback. Esse ciclo de gerar-compilar-testar-iterar tipicamente converge em 2-3 iteracoes, e cada iteracao se beneficia da arquitetura zero-copy do Rust que minimiza o overhead de passar codebases grandes entre estagios da pipeline.

Protocolo MCP: Interoperabilidade universal de IA

O Model Context Protocol esta se tornando o padrao de interoperabilidade para sistemas de IA, e o Agentor o implementa como cidadao de primeira classe atraves do crate agentor-mcp. Qualquer agente Agentor pode expor suas capabilities como ferramentas MCP, consumir ferramentas de servidores MCP externos e participar de fluxos de trabalho multi-sistema sem codigo de integracao custom. Isso significa que um agente de geracao de codigo do Agentor pode usar ferramentas fornecidas por um plugin de IDE, um sistema CI/CD ou um servico de deployment na nuvem, tudo atraves do mesmo protocolo, com as mesmas garantias de seguranca aplicadas pela camada de sandbox.

O suporte ao MCP tambem significa que as organizacoes podem adotar o Agentor incrementalmente. Fluxos de trabalho de IA existentes construidos sobre outros frameworks podem chamar agentes Agentor atraves do MCP sem substituir sua infraestrutura atual. A medida que as equipes ganham confianca nas caracteristicas de seguranca e performance, podem migrar cargas de trabalho adicionais no seu proprio ritmo. Nao e necessaria uma migracao big-bang: o Agentor foi projetado para coexistir.

Conformidade sem compromissos

Como empresa certificada ISO 27001, construimos o Agentor com a conformidade regulatoria como restricao de design, nao como um acrescimo posterior. Cada decisao arquitetural foi avaliada contra os requisitos dos frameworks regulatorios dentro dos quais nossos clientes operam.

• GDPR -- O fluxo de dados atraves da pipeline do agente e rastreado no nivel de tipos. Os campos PII sao marcados com o sistema de tipos do Rust, e qualquer tentativa de logar, serializar ou transmitir PII sem redacao explicita e detectada em tempo de compilacao. O sandbox garante que as ferramentas nao possam acessar dados para os quais nao receberam permissao explicita.
• ISO 27001 -- Controles de acesso, logging de auditoria e contencao de incidentes nao sao modulos opcionais: estao integrados no runtime. Cada acao do agente e logada com integridade criptografica, cada invocacao de ferramenta e registrada com seus grants de capability, e eventos de seguranca disparam contencao automatica atraves da camada de sandbox.
• DPGA (Digital Public Goods Alliance) -- O Agentor e projetado para atender aos padroes open-source para bens publicos digitais, com governanca transparente, documentacao acessivel e deployment independente de plataforma atraves de WASM.

O contraste com o framework que auditamos e marcante. Atingir a conformidade GDPR naquele sistema baseado em Python exigia adicionar middleware de runtime em cada fronteira de dados, sem enforcement do compilador e sem garantia de completude. No Agentor, a conformidade e estrutural: se o codigo compila, as regras de tratamento de dados sao aplicadas.

Performance: Rust vs Python

Somos cuidadosos com benchmarks porque podem ser enganosos. Esses numeros vem da nossa suite de testes interna rodando o mesmo fluxo de trabalho do agente -- uma tarefa de geracao de codigo que le uma especificacao, gera tres arquivos, os compila, executa testes e itera uma vez -- no mesmo hardware.

• Tempo de cold start -- Agentor: 38ms. O framework Python: 3.2 segundos. Isso importa quando voce roda agentes on-demand em ambientes serverless onde cada cold start e um usuario esperando.
• Footprint de memoria -- Agente Agentor com conjunto completo de ferramentas: 42MB. Agente Python equivalente: 380MB. Uma reducao de 9x que se traduz diretamente em economia de custos de infraestrutura quando operando em escala.
• Agentes concorrentes -- Agentor em uma maquina de 4 cores: mais de 200 agentes rodando simultaneamente com scaling linear de throughput. O framework Python: 12-15 agentes antes que o GIL se torne o gargalo.
• Suite de testes -- 483 testes, zero blocos unsafe, zero usos de unwrap() em codigo de producao. Cada caminho de erro e tratado explicitamente.
• Overhead do sandbox WASM -- Adicionar isolamento sandbox a uma invocacao de ferramenta custa aproximadamente 1.2ms por invocacao. A garantia de seguranca de isolamento completo por menos de dois milissegundos de latencia e um trade-off que aceitamos sem hesitacao.

O numero mais significativo nao e nenhum benchmark individual: e o tempo total de wall-clock para um ciclo completo de geracao de codigo. O Agentor completa o loop de gerar-compilar-testar-iterar em aproximadamente 40% do tempo que o framework Python leva, principalmente porque o overhead entre estagios da pipeline e medido em microssegundos em vez de centenas de milissegundos. Quando voce roda milhares desses ciclos por dia, essa diferenca se acumula em horas de tempo economizado e custos de API LLM significativamente menores devido a menos tokens desperdicados.

O que vem a seguir

O Agentor esta em desenvolvimento ativo, e nosso roadmap reflete as prioridades que ouvimos dos early adopters e do nosso proprio uso interno.

• Integracao com language server -- Integracao profunda com VS Code e outros IDEs atraves do Language Server Protocol, permitindo que os agentes de geracao de codigo do Agentor operem como assistentes de codificacao inteligentes com contexto completo do projeto.
• Orquestracao distribuida de agentes -- Execucao multi-no de agentes com distribuicao automatica de trabalho, tolerancia a falhas e replicacao de estado para deployments de escala enterprise.
• Editor visual de pipelines -- Uma ferramenta baseada em navegador para projetar fluxos de agentes visualmente, com composicao drag-and-drop de ferramentas, provedores e padroes de orquestracao.
• Suporte estendido de linguagens -- As transformacoes AST-aware atualmente suportam Rust, TypeScript e Python. Estamos adicionando Go, Java e C# para cobrir as linguagens enterprise mais comuns.
• Release open-source -- Estamos preparando o Agentor para lancamento publico sob uma licenca open-source permissiva. Os crates core, documentacao e projetos de exemplo estarao disponiveis no GitHub.

O que comecou como uma auditoria de seguranca se tornou a base de como construimos sistemas alimentados por IA na Xcapit. O Agentor nao e apenas um framework que vendemos para clientes: e o framework que usamos internamente para nosso proprio desenvolvimento de AI agents, nossos fluxos de geracao de codigo e nossos deployments criticos de conformidade. Cada melhoria que fazemos e testada em batalha em nosso proprio ambiente de producao antes de chegar a qualquer outra pessoa.

A licao dessa jornada e uma que continuamos reaprendendo em engenharia de software: quando a base esta errada, nenhuma quantidade de patches vai conserta-la. As vezes a decisao responsavel e comecar do zero com as restricoes certas, a linguagem certa e a arquitetura certa. O Agentor e nossa resposta a pergunta que nao conseguimos resolver com patches: como voce constroi AI agents que sejam seguros o suficiente, rapidos o suficiente e confiaveis o suficiente para os sistemas que mais importam?