A prevenção é essencialmente um problema resolvido?

Impedir que novos problemas de segurança em código gerado por agentes sejam implantados é, arquiteturalmente, um problema resolvido. Prevenção é o ato de impedir que uma nova vulnerabilidade no código chegue à produção em qualquer momento do processo de desenvolvimento e lançamento, incluindo, entre outras coisas, impedir sua introdução em uma branch de funcionalidade. Há pontos distintos no ciclo de vida do desenvolvimento agêntico em que a segurança pode ser introduzida, cada um adequado a um tipo diferente de controle, e o mapeamento entre eles é bem compreendido. Aplicá-lo dentro de uma organização enquanto o ciclo de vida de desenvolvimento de software está mudando ativamente torna esse mapeamento difícil de aplicar.

Você não consegue resolver tudo com prompts

A versão idealizada da segurança no desenvolvimento agêntico é uma única instrução: dizer ao agente para escrever código seguro, colocá-la no prompt do sistema ou na configuração do harness e deixá-lo trabalhar.

Figura 1. A instrução que parece um controle.

A orientação na janela de contexto realmente muda o que um agente produz, e o efeito é significativo o bastante para servir de base, mas uma instrução não é uma restrição. Ela altera a probabilidade do que será escrito, mas não decide isso. Isso vale para uma regra de uma linha e também para uma skill cuidadosamente elaborada. Essa é uma característica de como esses modelos funcionam (considerando todas as entradas e fazendo julgamentos sobre sua prioridade relativa), independentemente da qualidade do seu prompt.

O código gerado por IA continua suscetível às mesmas classes de vulnerabilidades que o código escrito por humanos sempre teve. Uma instrução, por si só, não muda isso, e nenhuma elaboração de prompts mudará. Portanto, a pergunta útil é: para onde vai todo o resto?

“Shift in” é o novo “shift left”

Três custos aumentam à medida que a segurança se move para fora, afastando-se do momento em que o código é escrito.

Figura 2. Os três aumentam juntos à medida que a segurança se move para fora.

Tokens são o mais óbvio. O custo de uma análise determinística é um erro de arredondamento perto de uma chamada de modelo, e a diferença aumenta toda vez que você pede a um modelo para raciocinar sobre uma parte maior da base de código.

A atenção humana é o segundo. Um problema identificado enquanto o agente ainda está trabalhando nunca vira um ticket, nunca precisa ser triado e nunca interrompe alguém que está dividido entre várias tarefas.

O terceiro é acertar a correção. Um agente trabalhando nos loops internos ainda mantém o prompt e a especificação originais; portanto, quando corrige algo, consegue confirmar que o resultado está funcionalmente intacto e seguro, porque sabe o que o código deveria fazer. Leve a mesma descoberta para fora, e esse contexto desaparece. A correção precisa ser restabelecida externamente, por meio de testes unitários, testes de fumaça e testes de integração executados antes e durante a CI.

Um agente que estende uma funcionalidade existente também depende da suíte de testes nos loops internos, porque precisa saber que não quebrou algo que não viu. Mas depende menos dela, pois ainda mantém o prompt e consegue raciocinar sobre o que a mudança deveria fazer, em vez de inferir a intenção a partir do que por acaso passa. Quanto mais para fora uma correção se move, mais dessa carga recai apenas sobre a cobertura.

Esse é o argumento para levar a segurança para dentro. O motivo pelo qual isso não acontece por si só é que a pressão na direção oposta é mais forte.

Segurança é atrito

Nada disso é novo. Segurança custa tempo, e inserir tempo no fluxo de um desenvolvedor sempre foi a parte difícil desse trabalho. É por isso que a Snyk foi pioneira com sucesso no shift left em DevSecOps, começando há dez anos.

A era agêntica amplia isso, em vez de mudar sua natureza. As organizações estão financiando a adoção de IA com base em múltiplos de produtividade dos desenvolvedores. E, quando a expectativa é um salto de eficiência, qualquer coisa que desacelere o loop não é uma questão de trade-off. Ela é removida.

Portanto, a questão não é se devemos adicionar controles de segurança, mas onde cada um pode ficar sem custar mais do que economiza.

O ciclo de vida é uma pilha de loops

O modelo de loops de Laurie Voss é uma das descrições mais claras de como o software é construído hoje: um conjunto de loops aninhados, cada um encerrado por seu próprio sinal.

• O loop de execução conclui uma instrução e termina com o feedback do ambiente, seja um resultado de teste, uma resposta de API ou o conteúdo de um arquivo.

• O loop de tarefa conclui uma especificação.

• O loop de produto faz o lançamento.

• O loop de sistema melhora tudo ao longo de dias e semanas.

• O loop de supervisão é onde um humano define objetivos, aloca um orçamento e decide o que importa.

Figura 3. A pilha de loops, baseada em What the hell is a loop, anyway?

Dentro dos loops de execução e de tarefa, o trabalho ainda está em aberto, e uma descoberta ainda pode ser corrigida antes que o loop termine, sem intervenção humana. A partir do loop de produto, é necessário confiar significativamente na cobertura de testes; caso contrário, a revisão humana é necessária.

Duas ressalvas antes de avançarmos. Primeiro, a adoção é desigual: existe um espectro de adoção do desenvolvimento agêntico, até mesmo dentro das empresas. Muitas equipes não executam agentes em todos esses loops, e muitas ainda têm pessoas trabalhando bem dentro dos loops internos, em vez de apenas na supervisão. Os loops continuam válidos de qualquer forma, porque descrevem quando uma parte do trabalho é encerrada, não quem a encerrou.

E, segundo, se você retirar o vocabulário agêntico, grande parte disso é como o software vem sendo construído há muito tempo: você itera sobre uma mudança, conclui uma unidade de trabalho, faz o lançamento, melhora o sistema e alguém decide o que vale a pena fazer em seguida. O que mudou foi a velocidade e quem (ou o que) está no teclado.

Os riscos que você pode nomear antecipadamente

Alguns riscos são totalmente previsíveis: injeção de SQL, cross-site scripting, segredos embutidos no código, padrões criptográficos fracos e as configurações incorretas mais comuns de infraestrutura como código. Sabemos exatamente o que estamos procurando, e é possível dizer a um agente como evitar isso antes que ele escreva uma linha.

O controle é a orientação no contexto do agente: prompts do sistema, configuração do harness e skills que abrangem os riscos que uma equipe mais quer impedir que sejam produzidos. É o controle mais barato disponível, porque o custo é pago uma vez no espaço da janela de contexto, em vez de por problema verificado. Nada é executado e nada é avaliado; a orientação simplesmente está presente.

Parte disso já está em vigor sem que ninguém precise implantar nada. Os harnesses incluem prompts do sistema que carregam algumas dessas diretrizes por padrão. Por exemplo, a Anthropic documenta os prompts do sistema de cada um de seus modelos. Além disso, muitas organizações estão criando registros compartilhados de skills, às vezes com skills específicas de aplicações que descrevem como suas próprias equipes desenvolvem, o que significa que uma skill de segurança não é um novo tipo de artefato a ser distribuído. É mais uma entrada em algo que já existe.

O limite aqui é o contexto. Cada instrução compete com as que já estão na janela, e carregar toda a gama de classes de vulnerabilidades no contexto de um agente dilui a orientação que mais importa, em favor de riscos que raramente aparecem. É preciso racionar, o que significa que outra coisa terá de detectar o que ficar de fora. E o contexto é apenas metade da restrição. Mesmo com espaço ilimitado, alguns riscos não podem ser incluídos em uma instrução, porque, quando ela foi escrita, ninguém sabia que eles existiam.

Os problemas sobre os quais ninguém poderia ter informado o agente

Quando desenvolvedores ou agentes selecionam um pacote, muitas vezes escolhem a versão mais recente porque ela é atual e faz o que precisam. Se uma vulnerabilidade nessa versão tivesse sido divulgada naquela mesma semana, nenhum dos dois saberia. O modelo não foi treinado com base nela. Nenhuma skill poderia tê-la abrangido, porque a divulgação não existia quando a skill foi escrita. Esperar que a prevenção por instrução resolva isso não é uma exigência razoável para ninguém.

Depois há tudo o que você racionou na etapa anterior. A cauda longa de riscos que não pode entrar em um prompt do sistema ou em uma skill sem poluir o contexto, mas que é perfeitamente real e perfeitamente detectável. Da posição do agente, essas duas categorias de risco são o mesmo problema: nunca lhe disseram para ficar atento a elas.

Ambas precisam de um teste que seja executado de forma exaustiva, e não seletiva, seja acionado enquanto o trabalho ainda está aberto e retorne rápido o suficiente para que o agente ainda esteja presente para agir sobre o resultado. E ele não deve parar na descoberta. Se o agente puder corrigir o que o teste revelar e executá-lo novamente, o loop se encerra sem que um humano precise participar, o que é a única versão disso que sobrevive ao contato com uma equipe que mede produtividade.

Trusted Output Assurance (parte do Evo Agentic Development Security) faz isso por meio de hooks e da CLI. Uma análise é acionada conforme os arquivos são gravados e novamente quando o agente termina o trabalho planejado, para que problemas recém-introduzidos apareçam e sejam corrigidos antes que a especificação seja concluída — tudo dentro dos loops internos. Package health checks, secrets scanning, e malicious code defense são executados pelo mesmo caminho.

Um agente que corrige tudo o que recebe às vezes reescreve código funcional para satisfazer uma descoberta que nunca foi real. Esse é um dos motivos pelos quais essa etapa deve pertencer a mecanismos determinísticos, e não probabilísticos, e isso torna a taxa de falsos positivos algo a ser testado ao escolher o que será executado. Você também deve entender o que acontece quando o mecanismo e o agente discordam sobre uma descoberta detectada. A Snyk otimiza para os dois cenários. Um controle só conquista um lugar nos loops internos se estiver certo com frequência suficiente para agir sem supervisão. Quando a confiança é menor, a descoberta deve ficar mais para fora.

Um controle como esse vale exatamente o que vale sua adoção, e a adoção é onde a segurança nos loops internos sempre teve dificuldades, porque dependia de cada desenvolvedor configurá-la. Agora essa parte é simples. As organizações distribuem o Trusted Output Assurance via MDM para as máquinas dos desenvolvedores e o incorporam aos templates de sandbox, para que ele já esteja presente onde quer que o código esteja sendo gerado, e o que está sendo executado em cada máquina apareça centralmente, em vez de precisar ser presumido.

Com o que os mecanismos rápidos e determinísticos têm dificuldade

Falhas de autorização e de lógica de negócio são um problema diferente. Autorização quebrada no nível do objeto, IDOR, falhas de isolamento entre tenants e abusos em várias etapas. Essas classes são bem compreendidas, e mecanismos baseados em regras são realmente ruins para encontrá-las, porque a falha é semântica, e não sintática. Nada no código parece errado. O que está errado é a relação entre as coisas.

A análise baseada em LLM da base de código montada é o que funciona aqui. Na prática, hoje, isso significa que uma organização solicita a um modelo que procure esses problemas, manualmente ou como uma invocação de agente acionada em um pipeline, às vezes por meio de um fornecedor e às vezes apontando um modelo de fronteira diretamente para o repositório.

Execute a mesma revisão de segurança cinco vezes sobre o mesmo código, e quase metade do que o modelo encontra por conta própria aparecerá em apenas uma das cinco execuções. Isso é o Snyk VulnBench JS 1.0, medido em 300 execuções da mesma revisão.

Esses relatórios isolados não estão errados, e o VulnBench documenta muitos deles que parecem lacunas genuínas de cobertura, e não ruído. Mas uma única execução não é uma decisão. É preciso conquistar confiança com repetição, e é por isso que este é o primeiro ponto em que o custo por descoberta se torna uma rubrica real, e não um erro de arredondamento.

O que muda nessa etapa não é quanto tempo uma análise leva, mas o que ela precisa examinar. Cada controle anterior é incremental. Uma skill é acionada quando o agente recorre a um padrão. Uma análise cobre o único arquivo recém-escrito, em vez das dezenas alteradas ao longo de uma sessão. Cada um deles é absorvido pelo trabalho que já estava acontecendo. A análise semântica da base de código montada não pode ser, porque não há nada sobre o que raciocinar até que as peças estejam reunidas; portanto, ela é executada como uma etapa própria, e seu custo é adicionado ao loop, em vez de ser absorvido por ele. O tempo que esse loop já levou foi o agente trabalhando, não uma folga para esperar, e uma passagem completa pode facilmente dobrar sua duração. Isso pressupõe um resultado limpo: tudo o que for encontrado precisa ser corrigido, e a análise precisa ser executada novamente, de modo que o custo se acumula, em vez de apenas ser somado. É por isso que isso acontece depois que o agente já avançou.

Cada um desses ciclos também depende mais da suíte de testes. Até lá, o prompt já desapareceu, então a cobertura é a única coisa entre uma correção de segurança e uma funcionalidade quebrada, e cada nova execução pede que ela sustente isso novamente. Na maioria das organizações, a cobertura está longe do nível necessário para que uma correção seja implantada sem supervisão, então alguém acaba revisando-a.

É exatamente nessa direção que a Snyk está avançando com o futuro da AppSec agentiva. Espere mais novidades sobre isso em breve.

O que só aparece sob ataque (pré-produção)

A última categoria só aparece quando algo está em execução. Cadeias de exploração em várias etapas, abuso de workflows, injeção de prompt contra um agente implantado, caminhos de exfiltração de dados que existem apenas por causa da forma como três componentes acabam interagindo no seu ambiente.

O controle é o teste adversarial: pentest e red team de IA contra uma aplicação real. Os tipos de fraqueza investigados são conhecidos, mas o trabalho é exploratório. A aplicação é o ponto de partida, e os limites não são definidos antecipadamente, então o que vem à tona é aquilo que o sistema acaba permitindo.

É aqui que Evo Continuous Offensive Security se encaixa, e vale especificar o que está fazendo o trabalho, porque não se trata de um scanner com um modelo acoplado a ele. Um agente de pentest orquestrador executa subagentes especializados contra um alvo ativo. Um agente validador separado contesta o que os outros relatam e cria uma exploração funcional para provar o problema. Essa última parte é importante porque testes exploratórios orientados por modelos produzem descobertas que parecem plausíveis, a menos que algo as obrigue a se sustentar, e é por isso que cada descoberta vem acompanhada de uma prova de conceito executável, e não de uma hipótese.

Três desses subagentes (lógica de negócios, controle e autorização de acesso e encadeamento de explorações) trabalham nas mesmas categorias semânticas de que a etapa anterior precisa. Transformar esses e outros mecanismos semelhantes em produtos integrados aos workflows da etapa anterior, à medida que esses workflows se estabilizam, é um trabalho que já está em andamento.

Ele pode ser executado contra a pré-produção como um gate de lançamento ou imediatamente após um lançamento para orientar o que deve ser feito em seguida. Historicamente, esse era um exercício de conformidade anual ou semestral. As organizações agora o executam com muito mais frequência, o que é o instinto correto, porque os adversários não seguem um cronograma de auditoria.

Não há nada para atacar até que algo esteja em execução, e é exatamente por isso que isso não pode acontecer antes.

O que o agente sabia e quando podia agir

Cada controle acima depende das mesmas duas coisas: se o agente poderia ter recebido essa informação antes de escrever o código e se a resposta chega enquanto ele ainda mantém o prompt. Essas duas perguntas posicionam os quatro controles e explicam por que a sequência não é uma questão de preferência. Cada controle se encaixa em uma das quatro caixas abaixo.

Figura 4. Os quatro controles, na ordem determinada pelas duas respostas.

Por que isso é mais difícil na prática

O blueprint é simples. Operá-lo dentro de uma organização real não é, e os motivos têm muito pouco a ver com segurança.

A maioria das organizações ainda não tem um ciclo de vida de desenvolvimento agentivo estabelecido. As ferramentas, os harnesses e a arquitetura que estão padronizando ainda estão mudando, às vezes trimestre após trimestre. O cenário de fornecedores está avançando no mesmo ritmo, então, mesmo onde uma escolha foi feita, há uma hesitação real em se comprometer com qualquer coisa que se pareça com uma decisão sem volta. Tudo isso se manifesta como falta de clareza sobre responsabilidades, porque, quando o formato do ciclo de vida ainda está mudando, também está mudando a questão de quem é responsável por cada parte dele. Falhas de autorização e de lógica tendem a não pertencer a ninguém em particular até que um incidente as atribua a alguém.

Nada disso exige começar do zero, e esse é o ponto que vale preservar. Quase toda organização já tem um gate de segurança pré-implantação, e esse gate está fazendo um trabalho real. Ele não é algo para remover enquanto você descobre o restante. Esses pontos de integração se sobrepõem ao que já existe e podem ser adotados um de cada vez, na ordem que melhor corresponda ao ponto em que seu ciclo de vida realmente se estabilizou. Colocar a varredura determinística dentro do loop não exige que você tenha resolvido quem é responsável pelos testes adversariais.

O segundo costuma receber menos peso do que deveria. Nos loops internos, um controle que devolve o trabalho a uma pessoa já fracassou, assim como um que produz uma fila de pull requests criadas por IA para alguém revisar. Ambos pegam uma verificação de segurança e a transformam no backlog de outra pessoa, que é onde os controles são silenciosamente desativados.

Mais adiante, é mais difícil evitar uma pessoa. Na maioria das organizações, a cobertura de testes está muito longe do nível em que se pode confiar que uma correção autônoma seja implantada, então alguém a revisa, e esse é o estado honesto das coisas hoje, não uma falha das ferramentas. Os harnesses estão melhorando na execução da suíte sem prompt, e a cobertura também aumenta quando os agentes escrevem os testes, mas ninguém deve planejar como se qualquer uma dessas coisas já tivesse chegado. O que é mais um motivo para capturar o que puder enquanto o agente ainda mantém o prompt, porque esse é o único lugar em que não é preciso haver uma pessoa.

O primeiro e o terceiro são o que torna seguro começar tudo isso enquanto o terreno ainda está mudando. Um controle que você pode implementar em uma tarde, reconfigurar centralmente ou remover por completo é um controle que pode ser adotado antes de você definir como será o seu ciclo de vida. Neste momento, essa propriedade vale mais do que qualquer capacidade individual.

O próprio Trusted Output Assurance é distribuído por MDM e mantém sua configuração centralizada, então mudar o que é executado não significa editar políticas do Jamf ou do Intune nem reescrever scripts de implantação. O Continuous Offensive Security precisa das URLs da sua aplicação e de um conjunto de credenciais, portanto não há uma estrutura a construir antes que ele retorne qualquer resultado. Nenhum dos dois obriga você a adotar uma arquitetura que ainda não definiu.

Prevenção agora, remediação em seguida

A prevenção está resolvida no sentido que importa. Os pontos existem, os controles existem e já se sabe qual controle pertence a cada lugar. Mas implementá-la dá trabalho, e o (AI)SDLC ainda está evoluindo sob nossos pés.

A remediação é outra história. A varredura determinística dentro do loop impede que você adote um pacote com uma versão conhecida como vulnerável no momento em que o adota. Ela não faz nada em relação ao pacote que você adotou há oito meses (ou até oito anos) e que recebeu uma CVE na semana passada. Esse backlog cresce de duas direções ao mesmo tempo: anos de descobertas acumuladas que nunca foram corrigidas e um fluxo contínuo de novas divulgações atingindo código que já está em produção. Uma boa prevenção não o reduz, mas impede que ele piore.

Esse problema merece uma conversa própria. Enquanto isso, o lado da prevenção já está disponível, e o primeiro passo é menor do que parece: escolha o ponto mais estável do seu ciclo de vida e adicione o controle adequado.