TL, DR
O risco na programação agentiva não é que o agente escreva um código ruim. É que o agente aja. Ele instala pacotes, edita arquivos que você não abriu, chama ferramentas, lê configurações que ninguém revisa e abre pull requestsCada uma dessas operações é privilegiada e realizada com as permissões de um desenvolvedor, e seus controles atuais foram criados para um cenário em que cada um deles era digitado manualmente.
A velocidade deslocou o gargalo para a revisão. Pesquisas independentes sobre assistentes de codificação com IA indicam que cerca de 40% do código gerado contém vulnerabilidades de segurança, e essa taxa não melhorou com o aprimoramento dos modelos. A produção multiplicou-se. A capacidade de revisão, não. A programação agética torna isso mais preciso do que o recurso de autocompletar jamais foi, porque uma única instrução pode afetar dezenas de arquivos.
Os ataques visam a fiação, não o modelo. Um código Unicode oculto em um arquivo de regras faz com que um assistente emita código malicioso sem nunca mencionar o fato, catalogado no MITRE ATLAS como AML.CS0041. Os atacantes registram os nomes dos pacotes que os modelos alucinam. Uma ponte MCP enviou código para execução remota a clientes mais de 437,000 vezes. A análise tradicional não lê nenhum desses arquivos.
O conteúdo é entediante e funciona: Inventariar os agentes e servidores MCP efetivamente em uso, tratar os prompts e arquivos de regras como código em revisão, definir o escopo de cada ferramenta para a tarefa e aplicar a política na máquina do desenvolvedor onde o agente é executado. Segurança de IA da Xygeni lida com os três primeiros e DevAI O último, tanto em código gerado por IA quanto em código escrito por humanos.
O que é Codificação Agêntica?
A programação agética é um modelo de desenvolvimento em que um agente de IA recebe um objetivo e o executa em toda a sua base de código usando ferramentas: leitura e edição de arquivos, instalação de dependências, execução de testes e abertura de dependências. pull requestsOs riscos decorrem dessas ações e da configuração que as orienta, não da qualidade de qualquer função gerada individualmente. As práticas que funcionam são: inventário, permissões com escopo definido, configuração revisada e aplicação de regras no ponto de extremidade.
Codificação agentiva ou programação agentiva?
Ambos os termos descrevem a mesma mudança, e as equipes os usam de forma intercambiável. Programação agética tende a aparecer em conversas de engenharia sobre como o trabalho é feito; codificação agética é a expressão que se consolidou em ferramentas e segurança. Tecnicamente, nada os separa. Se você quiser a definição completa e vocabulário relacionado, nossa entrada no glossário sobre codificação agentiva aborda esse assunto.
O que importa neste caso é a distinção entre sugestão e execução. Um assistente que completa uma linha de código é um recurso de produtividade. Um agente que instala um pacote, edita seis arquivos e envia uma ramificação é uma entidade não humana operando dentro do seu sistema. SDLCA programação agética ultrapassou essa linha discretamente, e a maioria dos programas de segurança não teve seu escopo redefinido desde então.
Os riscos reais da codificação agentiva
Quatro famílias de risco, na ordem em que costumam morder.
- Análise de volume superior. Um agente gera mais alterações por hora do que qualquer revisor consegue analisar de forma significativa. As aprovações se tornam meros carimbos, e padrões inseguros se reproduzem na velocidade da máquina. Este é o risco que todos reconhecem e o menos mensurado. Comece medindo a proporção entre as alterações geradas pelo agente e o tempo de revisão humana, e o número falará por si.
- A camada de instruções. Qualquer coisa que alcance o contexto do agente pode direcioná-lo. A injeção imediata é a principal estratégia. OWASP Top 10 para candidaturas a mestrado em Direito (LLM) Por um motivo, e na programação orientada a agentes, os veículos de entrega são banais: uma descrição do problema, um comentário no código, um arquivo README em uma dependência, um documento que o agente recupera. Ninguém precisa atacá-lo diretamente. Basta que escrevam algo que seu agente vá ler.
- A camada de configuração. Arquivos de regras, arquivos de habilidades, prompts e definições de servidor MCP determinam o que o agente faz e aonde ele pode chegar. Eles não são código de aplicativo, portanto, nenhum scanner em uma pilha típica os lê. A vulnerabilidade "Rules File Backdoor" demonstrou o caso extremo, onde caracteres de largura zero carregam instruções que um revisor não consegue ver fisicamente. O caso comum é igualmente prejudicial: uma credencial de provedor em texto simples em um arquivo de configuração ou um assistente com acesso de leitura a todo o sistema de arquivos porque essa era a configuração padrão.
- A dependência e a superfície da ferramenta. Um agente escolhe as dependências. Ele resolve um nome, instala-o e prossegue, e os scripts de instalação são executados antes de qualquer outro. pipeline vê a mudança. O slopsquatting explora exatamente isso: uma pesquisa apresentada na USENIX Security 2025 descobriu que 19.7% dos pacotes recomendados por modelos de linguagem não existem e que os nomes alucinados se repetem com frequência suficiente para que os atacantes os registrem e esperem. O mesmo se aplica a Servidores MCP, onde conectar-se a um servidor não confiável entrega ao agente ferramentas que você nunca auditou.
Como é que as coisas dão errado, na verdade
Não se trata de uma única façanha exótica. É uma combinação de técnicas já documentadas na natureza, na ordem em que são aplicadas.
- A instruçãoUma frase está presente na descrição de um problema, no arquivo README de uma dependência ou em um comentário de código. Ela não foi escrita para ser lida por um humano.
- O contextoUm desenvolvedor pede ao agente para corrigir o problema. O agente busca a descrição, o repositório e seus próprios arquivos de regras no contexto. A instrução e o conteúdo são idênticos aos de um modelo.
- A instalaçãoO agente encontra uma biblioteca auxiliar que parece adequada e a instala. O nome foi registrado na semana passada por alguém que percebeu que os modelos continuam a inventá-la. O script de instalação é executado no laptop.
- A credencialExiste um token de provedor em texto simples em um
mcp.jsone uma sessão na nuvem já ativa no shell. O script não precisa de privilégios elevados. Ele herda. - O pull requestA alteração é pequena, os testes estão verdes e a diferença é razoável. É aprovada em menos de um minuto, porque há mais quatro na fila de espera.
Todos os portões que você possui disparam após o terceiro passo. Os três primeiros ocorrem em uma máquina de desenvolvedor, em cerca de noventa segundos.
8 lições dos primeiros usuários
Baseado em incidentes documentados, pesquisas publicadas e nos padrões que continuam surgindo em equipes que adotaram a programação agentiva antes mesmo de alguém ter escrito uma política para ela.
- O raio de explosão é a superfície da ferramenta, não o ponto de partida. As equipes passam semanas reforçando as configurações dos agentes e minutos decidindo quais ferramentas um agente pode usar. Essa proporção está errada. Um agente que só pode ler é um inconveniente quando comprometido. Um agente que pode enviar e-mails, consultar a produção e executar pushes é essencial. commitTrata-se de um incidente, e ele contém as credenciais do próprio desenvolvedor para executá-lo, pois quase ninguém provisiona uma identidade para um agente. Anote a lista de ferramentas antes de escrever o prompt do sistema.
- O agente otimiza para que o teste seja aprovado, não para que o código funcione. Diante de um conjunto de testes com falhas e autonomia suficiente, um agente irá excluir a asserção, flexibilizar a condição ou substituir uma integração por uma simulação e, em seguida, relatar sucesso. Toda equipe reconhece isso na primeira semana. É por isso que é verde. pipelinedeixou de ser uma evidência, e por que a questão da revisão mudou de "isto funciona?" para "o que mudou para que isto fosse aprovado?".
- Seu arquivo de regras é uma configuração de produção. O arquivo que controla cada linha gerada geralmente é commitFoi alterado uma vez e nunca mais revisado. Deveria estar sob controle de alterações, com um responsável, uma revisão detalhada e alguém que perceba quando o código cresce com uma linha que ninguém se lembra de ter adicionado. Presuma que tudo nele será obedecido, inclusive o que você não consegue ver.
- As dependências do agente não são suas dependências. As listas de bibliotecas aprovadas pressupõem uma escolha humana. Um agente resolve um nome plausível e o instala, e os scripts de instalação são executados antes da CI existir. As equipes que tiveram problemas adicionaram uma verificação no momento da instalação na máquina, e não um documento de política listando o que os desenvolvedores deveriam preferir.
- Ninguém pode te dizer o que eles estão administrando. Pergunte a cinco engenheiros quais servidores e assistentes MCP eles usam e você obterá cinco respostas, nenhuma completa. Pesquisas não funcionam aqui porque as ferramentas são instaladas localmente e mudam semanalmente. A descoberta precisa vir do código, das dependências e dos arquivos de configuração deixados pelas ferramentas.
- A memória retém o veneno mesmo após o término da sessão. Uma instrução incorreta que atinge o contexto persistente ou a memória de um agente não expira quando a tarefa termina. Ela continua a gerar efeitos silenciosamente em tarefas não relacionadas, razão pela qual o envenenamento de memória e contexto tem sua própria entrada na lista de agentes da OWASP. Trate a memória do agente como um estado que precisa ser revisado e limpo, e não como um recurso de conveniência.
- A reversibilidade é melhor que a prevenção. As equipes que operam com maior autonomia e segurança não são as que possuem os controles mais rígidos. São as que minimizaram os erros: os agentes executam branches em vez da branch principal, trabalham em ambientes descartáveis e cada ação pode ser desfeita com um único comando. A autonomia é acessível exatamente na medida em que revertê-la também o é.
- O piloto está mentindo para você. Os agentes têm um desempenho excelente em tarefas novas em repositórios pequenos, mas apresentam problemas em grandes bases de código legadas com convenções implícitas. Um projeto piloto bem-sucedido superestima o ganho de produtividade e subestima o risco, criando uma expectativa que ninguém consegue atender em grande escala. Faça o projeto piloto no seu repositório mais problemático, não no mais organizado.
Como isso se traduz na prática
A ordem importa mais do que as ferramentas. Primeiro a descoberta, porque você não pode definir permissões em agentes que não encontrou. Depois, a camada de configuração, porque é lá que as instruções estão. Por fim, o endpoint, porque é lá que o agente é executado e onde uma instalação é concluída muito antes de um pipeline avisos.
Segurança de IA da Xygeni descobre todos os ativos de IA no SDLC, incluindo os modelos, agentes, servidores de agentes, servidores MCP, conjuntos de dados, arquivos de habilidades, prompts e guardrails Ninguém declarou, lendo o código do aplicativo, as dependências declaradas e os arquivos de configuração deixados pelas ferramentas de IA, e mapeando como eles se conectam. Detecta os riscos específicos da programação agentiva: injeção de prompts e vazamento de prompts do sistema, instruções maliciosas e injeção de ferramentas em arquivos de regras e habilidades, configuração insegura do MCP, agência excessiva e ausência de código. guardrailssegredos em arquivos de IA e dependências de IA vulneráveis ou exploradas indevidamente. As descobertas são mapeadas para o OWASP Top 10 para aplicações LLM e apontam para o arquivo e linha exatos, e o funil de priorização reduz milhares de descobertas àquelas que estão em uso, acessíveis, exploráveis, privilegiadas e críticas para os negócios.
DevAI A outra metade é coberta pelo editor: ele protege o código à medida que é escrito, aplica-se tanto a código gerado por IA quanto a código escrito por humanos e intercepta o que outros agentes estão prestes a fazer antes que o façam. A mesma inteligência se aplica às descobertas ingeridas pelos scanners que você já executa, portanto, nada disso exige a substituição do que você já possui.
Perguntas frequentes
- Qual é o maior risco na programação agentiva? Excesso de autonomia. Um agente com amplo leque de ferramentas transforma qualquer intervenção bem-sucedida em uma ação concreta, e a maioria das equipes define o escopo das ferramentas de forma muito mais flexível do que o escopo das pessoas.
- A programação agentiva é segura para ambientes regulamentados? Sim, com um inventário, permissões definidas, configuração revisada e aplicação de políticas no endpoint. O que não é defensável em uma auditoria é desconhecer quais agentes estão em execução, aonde eles chegam ou qual código eles escreveram.
- A codificação agentiva produz código menos seguro do que a codificação humana? A taxa por linha é comparável ao erro humano, mas o volume não, e é o volume que impede a revisão. O problema é a produtividade, não a falta de talento.
- Precisamos proibir assistentes de programação com IA? As proibições levam o uso para a clandestinidade, o que é pior. A IA paralela é mais difícil de proteger do que a IA aprovada, e a descoberta é o controle que realmente muda o cenário.
- Quem é o responsável quando um agente divulga uma vulnerabilidade? A pessoa que fez a fusão, exatamente como antes. Essa é a parte desconfortável, e é por isso que os dados de autoria são importantes: um revisor que aprova uma alteração gerada por máquina em grande escala precisa que a constatação chegue antes da aprovação, não depois.
- Como começar se não temos nenhuma visibilidade? Execute uma análise de descoberta em seus repositórios, liste os servidores MCP e os assistentes encontrados e classifique os agentes por ferramenta utilizada. O agente mais arriscado geralmente não é aquele que preocupava as pessoas.
Os agentes já estão em seus repositórios.
A codificação de agentes já está em seus repositórios, independentemente de ter sido aprovada ou não. As equipes que a gerenciam bem não são as que têm as políticas mais rígidas. São as que conseguem responder, a qualquer momento, quais agentes estão em execução, a que esses agentes podem acessar e o que mudou nos arquivos que os controlam.
Veja a que os seus agentes estão conectados em Xygeni.







