Agentes de código no endpoint: visibilidade, controle e auditoria para governar o novo risco de desenvolvimento

Nos últimos meses apareceu um ator silencioso dentro de muitos equipamentos de engenharia: não é um humano, nem um serviço tradicional, mas um assistente de programação capaz de ler arquivos, executar comandos na shell, ligar a APIs externas e conectar com integrações de terceiros. Estes "agentes" de código — um exemplo destacado é o Claude Code de Anthropic — são executados na máquina do desenvolvedor com as mesmas permissões que este e, portanto, operam fora do perímetro das ferramentas de segurança que tradicionalmente protegem a rede ou os gateways.

Esta mudança não é trivial. Muitos controles de segurança estão pensados para ver e agir quando o tráfego sai do dispositivo: os SIEM, os monitores de rede e os gateways inspeccionam comunicações em trânsito. Mas um agente local já pode ter lido segredos, modificado arquivos ou executado uma sequência de comandos antes de qualquer pacote atravessar a rede. A ação ocorre no endpoint e, salvo que essa camada também esteja observada, fica fora de alcance. Para entender melhor por que isso importa convém lembrar que esses agentes costumam “vivir do sistema”: reutilizam binários e credenciais já presentes na máquina em vez de trazer os seus, o que dificulta sua detecção com as técnicas clássicas de filtragem. Organizações e equipamentos de segurança têm tempo alertando sobre esta forma de operar, que na terminologia de segurança é conhecida como “living off the land”; para referências técnicas úteis pode ser consultada a documentação do MITRE ATT&CK sobre técnicas relacionadas: MITRE ATT&CK – LOLBins / System Binary Proxy Execution.

O que pode ser feito quando um agente executa comandos com as permissões de um desenvolvedor e não deixa rastro nos logs que a equipe de segurança já recolhe? Uma solução que aparece neste contexto é colocar uma camada de confiança e controle diretamente no dispositivo do desenvolvedor, junto ao próprio agente. Beyond Identity chamou este componente Ceros: uma “capa de confiança” que se instala no endpoint e que pretende oferecer três coisas chave: visibilidade em tempo real, bloqueio ou mitigação de ações não autorizadas, e um rastro de auditoria criptográficamente verificável.

A proposta de Ceros é pragmática: a adoção de controles no ambiente do desenvolvedor deve ser invisível para não quebrar a produtividade. Do ponto de vista da equipe de engenharia, a interação com o agente deve continuar igual, mas por trás da cena Ceros captura o contexto do dispositivo (versão do sistema, estado de proteção, criptografia de disco, Secure Boot e outros indicadores de postura), recolhe a genealogia de processos que iniciou a sessão e o ata a uma identidade humana verificada, assinando as evidências com chaves ligadas ao hardware do equipamento.

Na consola administrativa de Ceros aparece pela primeira vez para muitos equipamentos algo que antes era uma caixa negra: as conversas completas entre cada desenvolvedor e seu agente, e - o mais relevante - as chamadas a ferramentas que foram executadas durante essas conversas. Quando um pedido aparentemente inocua desencadeia a execução de um comando de shell ou a leitura de um ficheiro, a plataforma mostra-o com o comando exato, seus argumentos e a saída resultante. Essa visibilidade das “herramientas invocadas” transforma a percepção do risco: deixa de ser uma suspeita e passa a ser evidência concreta.

Junto às sessões, Ceros expõe os conectores externos que os agentes usaram: os chamados MCP servers, que são as pontes para bases de dados, APIs internas, plataformas de mensagens ou serviços na nuvem. Em muitas organizações, a lista de integrações que os desenvolvedores têm conectado por sua conta supera o que as equipes de segurança acreditavam permitido; a falta de revisão desses caminhos de acesso constitui um vetor de risco em si mesmo.

Visibilidade sem governança é apenas detecção. Por isso, Ceros incorpora uma camada de políticas que são avaliadas em tempo real antes de uma ação ser executada. Entre as opções que pagam dividendos rapidamente estão as regras de allowlist para MCP servers: só é permitida a ligação a servidores aprovados e o resto é bloqueado no ponto de origem. Também podem ser criados controlos por ferramenta: limitar o uso de Bash, permitir leituras de arquivos apenas dentro de rotas de projeto ou inspeccionar os argumentos de uma chamada para permitir ou recusar. Além disso, as políticas de postura de dispositivo exigem condições mínimas - por exemplo criptografia de disco ou proteção endpoint ativa - para permitir que o agente seja executado; e, se o estado da equipe mudar durante uma sessão, a plataforma pode reavaliar e agir conforme definido.

Do ponto de vista de cumprimento, a diferença mais relevante é o rastro de testes. O registo de atividade gerado pelo Ceros não é um ficheiro de log que um administrador possa editar a posteriori: cada entrada é assinado com uma chave ligada ao hardware antes de sair do dispositivo, criando uma cadeia de evidência com selo temporário e atribuição humana. Para equipes que devem responder a auditorias sob marcos como SOC 2, FedRAMP, HIPAA ou PCI-DSS, dispor de registros imutáveis e com contexto forense – identidade do usuário, árvore de processos, assinaturas binárias, postura do dispositivo e detalhes das ações – facilita demonstrar controles efetivos. Se quiser rever fontes oficiais sobre requisitos de auditoria e controlo, consulte os recursos do BCE AICPA sobre SOC, a web FedRAMP, documentação da HHS sobre HIPAA e a página do PCI Security Standards Council.

Além de bloquear ou permitir, a plataforma permite gerenciar de forma centralizada o que integrações estão disponíveis: os administradores podem implantar servidores MCP aprovados aos agentes de todos os desenvolvedores de uma consola, evitando configurações manuais e garantindo que os equipamentos trabalhem apenas com as ferramentas oficiais. Combinada com a allowlist, esta capacidade torna a governança em algo operacional e automático, sem adicionar fricção ao fluxo de trabalho do desenvolvedor.

Tudo isto é resumido num painel que oferece uma visão agregada do risco associado a agentes em toda a organização: quantos dispositivos estão envolvidos, quais instâncias do agente estão ativas e onde existem lacunas de adoção que poderiam indicar que agentes são executados fora do controle. Para equipes de segurança que devem priorizar esforços, essa telemetria é o ponto de partida para tomar decisões informadas.

Não se trata de demonizar as ferramentas de assistência: os assistentes de programação oferecem produtividade real. O desafio é que seu modelo de operação exige repensar a arquitetura de segurança: Se a ação ocorrer no endpoint, é onde deve ser medido e governado. A recomendação prática para os equipamentos que já usam ou planejam implantar agentes é começar pela visibilidade: só quando se sabe quais ações são executadas e por quem é possível projetar políticas que mitiguem risco sem parar os desenvolvedores.

Se você quiser conhecer mais sobre as soluções do fabricante mencionadas neste artigo, você pode visitar a web do Beyond Identity em beyondidentity.ai, e a página de implantação do agente em agent.beyondidentity.com. Para entender o fenômeno mais amplo de agentes e extensões de modelos, a indústria também está se movendo para quadros e práticas de segurança adaptadas a esses novos fluxos; a OpenAI documentou abordagens de extensibilidade em relação a novos fluxos. seu blog, e análise de técnicas de abuso e mitigação aparecem em recursos como os do MITRE.

Em resumo, os assistentes de programação no endpoint são uma nova camada de risco e oportunidade. A estratégia efetiva passa por instrumentar o dispositivo: registrar, controlar e assinar o que acontece no momento em que acontece, não reconstruíndo depois. Só assim as equipas de segurança podem integrar estes agentes dentro de controlos auditáveis e adequados aos requisitos regulamentares e empresariais.