Os testes de segurança com IA podem substituir SAST, DAST e pentests?

A pergunta útil é onde um agente merece confiança. Confio nele para ampliar a cobertura de revisão, ligar indícios entre ficheiros, gerar testes direcionados e transformar um rasto confuso de scanner numa correção que um programador compreenda. Não confio nele para deduzir as regras de autorização de uma empresa a partir dos nomes das rotas, provar que todos os limites entre inquilinos se mantêm ou decidir que um fluxo financeiro estranho é abusivo sem que uma pessoa defina a regra. Trate o agente como um revisor ativo dentro de um programa de testes em camadas, não como o próprio programa.

Uma revisão por agente é um intérprete, não uma nova classe de teste

Um agente de IA muda a forma como a evidência é recolhida e compreendida. Não cria um novo tipo de evidência. Se lê o código-fonte sem executar a aplicação, faz uma forma flexível de revisão estática. Se envia pedidos para um alvo em execução, faz testes dinâmicos. Se explora objetivos, muda de tática e segue comportamentos inesperados, assemelha-se a um pentester, mas essa semelhança não lhe dá a autoridade nem o contexto de negócio de um testador.

Esta diferença importa quando um fornecedor afirma que o seu agente «substitui scanners». Pergunte o que o sistema consegue realmente observar. Recebe o repositório completo, código gerado, opções de compilação, política de infraestrutura e ficheiros de bloqueio de dependências? Consegue autenticar-se como vários utilizadores e verificar o estado da base de dados depois de cada pedido? Sabe quais ações são proibidas pela política, em vez de apenas ausentes da interface? Uma explicação bem apresentada não corrige dados em falta.

Os agentes são realmente bons a ligar sinais fracos. Uma regra convencional pode assinalar um parâmetro de pedido que chega a um construtor de consultas. Um agente pode inspecionar o invólucro, reparar que um ponto de chamada omite o predicado do inquilino, preparar um pedido de teste e explicar porque o auxiliar supostamente seguro não é seguro nesse caminho. Também pode descartar um candidato quando o valor passa por uma API verdadeiramente parametrizada. Isto melhora a triagem, não prova que a análise estática ou dinâmica ficou obsoleta.

O limite claro está entre revisão e verificação. A revisão pergunta: «Esta implementação parece insegura com base no material que consigo ver?» A verificação pergunta: «Nas condições indicadas, este ator consegue provocar um resultado proibido?» A IA ajuda em ambas, mas uma barreira de segurança deve registar qual alegação está a fazer. As equipas sofrem quando uma observação eloquente de revisão é promovida a exploração verificada, ou quando uma tentativa de exploração falhada é tratada como prova de segurança.

O comportamento do modelo acrescenta outra diferença: capacidade não é repetibilidade. Um agente pode descobrir um caminho subtil numa execução e não o encontrar depois de uma alteração do modelo, do prompt, do índice de recuperação ou da política de ferramentas. Preserve os prompts, permissões de ferramentas, ficheiros recuperados, pedidos gerados e identificador do modelo quando o resultado importa. Depois transforme descobertas confirmadas em testes cuja condição de aprovação não dependa de o modelo redescobrir a própria ideia.

O SAST continua responsável pela cobertura repetível do código-fonte

O SAST continua a ser a forma mais económica de aplicar verificações estáveis a cada alteração num código-base grande. Pode enumerar origens e destinos, impor APIs proibidas, inspecionar fluxos de dados e indicar a revisão exata que analisou. Uma regra determinística produz o mesmo resultado amanhã, algo essencial quando uma barreira de lançamento precisa de uma razão auditável para aprovar ou reprovar.

Um agente acrescenta contexto que um motor de regras muitas vezes não tem. Pode seguir invólucros específicos do projeto, ler comentários com ceticismo, comparar um manipulador com manipuladores próximos e propor uma consulta para um novo padrão. Pode detetar omissões suspeitas, como nove endpoints chamarem authorizeProject() enquanto um décimo carrega diretamente o registo. Também é útil quando código gerado ou uma framework desconhecida derrota um conjunto de regras padrão.

Mas a cobertura de código-fonte de um agente costuma ser mais difícil de provar. Janelas de contexto, classificação da recuperação, ficheiros ignorados, artefactos gerados e tempos limite das ferramentas podem deixar código por ler. Pedir «reveja este repositório em busca de injeção» não prova que todos os destinos foram alcançados. Um relatório SAST pode pelo menos indicar quais ficheiros, regras e revisão foram analisados. Um agente precisa de um registo de cobertura equivalente antes de assumir uma barreira obrigatória.

O NIST SP 800-218 faz aqui a recomendação sensata: use análise de código cedo e verifique manualmente funcionalidades e mitigações de segurança. O valor está na combinação. Regras estáveis encontram formas conhecidas de defeitos em cada commit. O agente investiga exceções, escreve testes de regressão focados e ajuda a ajustar regras quando o mesmo padrão se repete. Remover o SAST porque o agente encontrou vários bugs engenhosos troca amplitude mensurável por histórias impressionantes.

O SAST também vê código a que um teste em execução pode nunca chegar: caminhos de erro, sinalizadores de funcionalidades, utilitários de migração, endpoints administrativos inativos e ramificações específicas de plataforma. Não consegue dizer se o ambiente implementado ativa esses caminhos. Essa incerteza é motivo para acrescentar evidência em tempo de execução, não para descartar a cobertura estática.

Há limites para o que deve pertencer a uma regra SAST que bloqueia. Um padrão preciso para uma primitiva criptográfica proibida pode bloquear de imediato. Uma heurística ampla que pergunta se uma verificação de autorização «parece suficientemente próxima» deve normalmente criar uma tarefa de revisão até a equipa medir a sua precisão. Os agentes podem ajudar a transformar uma heurística em regra ao recolher exemplos verdadeiros, contraexemplos e as funções de invólucro comuns naquele código-base. Assim, a barreira mantém-se rigorosa sem ensinar os programadores a ignorá-la.

As correções geradas exigem o mesmo escrutínio que as descobertas. Um modelo pode silenciar um rasto de contaminação ao acrescentar validação na camada errada, capturar uma exceção e falhar de modo permissivo, ou substituir uma chamada perigosa alterando o comportamento. Execute a prova original contra o patch, execute os testes funcionais normais e reveja o novo controlo onde a confiança é estabelecida. Uma nova análise limpa prova apenas que a regra original já não corresponde.

O DAST prova comportamentos que o repositório não consegue revelar

O DAST observa a aplicação que está realmente em execução, incluindo regras de proxy, cabeçalhos, serialização, middleware de autenticação, predefinições da framework e erros de implementação. A revisão de código-fonte pode dizer que um endpoint parece protegido. Um teste dinâmico pode mostrar que a rota de produção ignora o middleware porque uma gateway reescreve o seu caminho.

É aqui que um agente pode tornar os testes dinâmicos muito menos rudimentares. Dê-lhe uma descrição da API, identidades de teste, âmbitos permitidos e um ambiente descartável, e ele pode criar sequências de pedidos em vez de disparar cargas genéricas. Pode transportar um identificador de recurso de uma resposta para a seguinte, renovar uma sessão, comparar duas funções e verificar se uma escrita alterou leituras posteriores. O DAST convencional tem frequentemente dificuldade com estes fluxos com estado.

O agente continua a precisar de limites de operação rigorosos. Um crawler não sabe se enviar um email, criar uma remessa ou invocar uma integração paga é seguro. Um ambiente de teste pode ainda ligar-se a serviços reais. Defina hosts permitidos, contas, taxas de pedidos, ações destrutivas e condições de paragem fora do prompt do modelo, depois imponha-os no executor. Uma frase a dizer «evite ações perigosas» não é um controlo.

Mantenha uma base dinâmica convencional para verificações bem conhecidas, como cabeçalhos de segurança, ficheiros expostos, entrada refletida, sondas de injeção comuns e configuração TLS. Estas verificações são económicas, comparáveis entre lançamentos e fáceis de acompanhar ao longo do tempo. Deixe o agente gastar o seu orçamento em caminhos autenticados e comportamentos encadeados. Se ambos os sistemas cobrirem a mesma sonda simples, mantenha o que tiver evidência mais clara e menor variação.

O DAST também pode dar uma falsa sensação de completude porque só relata o que alcançou. Registe a cobertura de rotas, identidades usadas, sinalizadores de funcionalidades e dados iniciais com o resultado. Uma análise limpa contra uma conta quase vazia prova muito pouco sobre uma aplicação cujos ramos perigosos só surgem depois de aprovação, convite, faturação ou importação de dados.

A configuração da autenticação merece a sua própria evidência. Registe como o teste obteve cada sessão, que segundos fatores ou verificações de dispositivo foram contornados no ambiente de teste e se os tokens têm as mesmas declarações e duração que os tokens de produção. Um token de administrador criado manualmente pode abrir uma cobertura útil, mas ignora exatamente as transições de sessão e privilégios que precisam de testes. Mantenha esses atalhos visíveis no relatório.

Os novos testes dinâmicos devem começar pela sequência de pedidos guardada, não por uma nova exploração autónoma. Repita a prova confirmada na compilação corrigida, confirme que o efeito proibido parou e só depois altere entradas próximas para detetar um filtro demasiado específico. Esta ordem separa «a correção bloqueia a exploração conhecida» da alegação mais ampla de que a classe de defeito foi eliminada.

Os testes de autorização precisam de identidades e resultados proibidos

Autorização não é «o endpoint devolveu 403 uma vez». Um teste útil indica quem atua, qual objeto pretende atingir, qual operação tenta realizar e que resultado deve continuar impossível. Um agente pode gerar as combinações, mas o proprietário do produto e o revisor de segurança têm de fornecer a política.

O OWASP ASVS diz que as aplicações devem impor o controlo de acesso numa camada de serviço confiável e aplicar o princípio do menor privilégio a funções e dados. Concordo com o requisito da camada de serviço, mas as equipas testam-no muitas vezes de forma demasiado estreita. Testam o manipulador HTTP visível e esquecem tarefas em segundo plano, exportações, índices de pesquisa, subscrições websocket e URLs diretos de armazenamento de objetos. A mesma política deve sobreviver a todos os caminhos até ao objeto.

Uma pequena matriz executável revela mais do que uma instrução vaga para «testar IDOR». O seguinte fragmento de shell pressupõe um ambiente descartável, dois tokens bearer e um documento pertencente ao utilizador A. Verifica tanto o estado como a ausência do marcador secreto de A na resposta de B:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

O resultado esperado é silêncio e código de saída zero. Uma falha de CI deve reter o estado, o corpo higienizado, a identidade que atuou, o proprietário do alvo, a rota e a revisão da compilação. Não retenha credenciais ativas nem dados de resposta não relacionados.

Agora altere uma dimensão de cada vez: leitura versus atualização, ID direto versus pesquisa, associação ativa versus revogada, rota normal versus exportação e token de utilizador versus token de serviço. O agente consegue produzir e executar estes casos com eficiência. Uma pessoa tem de rever se a matriz corresponde à política e se 404, 403, resultado vazio ou objeto ocultado é o resultado pretendido. Caso contrário, o agente pode celebrar um comportamento que o negócio considera uma violação.

A evidência negativa exige cuidado. Uma atualização negada pode ainda revelar se um objeto existe através do tempo de resposta, do texto de erro ou de um contador de versões. Uma leitura negada pode incrementar uma contagem de visualizações ou escrever um registo de auditoria com metadados secretos. Decida que efeitos secundários são permitidos e afirme-os. Testes de segurança que inspecionam apenas a resposta podem perder um canal útil de enumeração ou uma escrita prejudicial.

Teste também alterações de política durante uma sessão. Remova um utilizador de um projeto, transfira a propriedade, desative uma conta ou reduza uma função de serviço, depois reutilize tokens antigos e abra ligações. O tempo de revogação esperado deve vir da política do produto. «Eventualmente» não é testável, e a revogação imediata pode ser desnecessária, mas a equipa tem de escolher um limite e verificá-lo em pedidos de API, trabalho em fila, transferências e subscrições ativas.

O isolamento entre inquilinos falha fora do caminho óbvio do pedido

O isolamento entre inquilinos precisa de testes nas fronteiras de armazenamento, cache, filas, pesquisa, ficheiros, análise e administração. A falha comum não é a ausência de tenant_id no endpoint principal de listagem. É um caminho secundário que copia, indexa, coloca em cache ou exporta dados sem transportar o contexto do inquilino.

Comece com dois inquilinos que tenham registos deliberadamente semelhantes e um marcador inequívoco para cada um. Use utilizadores separados, sessões separadas e, quando a arquitetura o permitir, credenciais de serviço separadas. Teste criar, ler, atualizar, eliminar, listar, pesquisar, exportar, importar, aceder a anexos, entregar notificações e processar em segundo plano. Depois de cada ação, inspecione a resposta visível ao utilizador e o estado persistente. Um pedido rejeitado que ainda coloca um trabalho entre inquilinos na fila é uma falha.

Os agentes ajudam porque conseguem seguir um identificador através das camadas e gerar permutações que as pessoas acham cansativas. Podem reparar que a chave de cache usa document_id, enquanto a consulta à base de dados usa tenant_id e document_id. Podem comparar um trabalhador de exportação com o manipulador interativo e perguntar porque só um define o contexto ao nível da linha. São movimentos de revisão muito valiosos.

Também fazem uma suposição perigosa: os nomes implicam limites. Uma função chamada getTenantDocument pode aceitar um argumento de inquilino arbitrário a partir do pedido. Uma política de base de dados pode existir nas migrações, mas não numa tabela nova. Um filtro de pesquisa pode ser aplicado depois de contar os resultados, expondo atividade de outro inquilino. A verificação deve inspecionar o predicado imposto e depois tentar uma leitura e uma escrita entre inquilinos.

Não deixe o agente criar o seu próprio oráculo lendo o mesmo código que testa. Derive o acesso esperado de uma tabela de políticas independente, mantida com os requisitos do produto. Se a implementação e o teste entenderem mal a mesma regra, concordarão na perfeição enquanto expõem dados.

Os caminhos assíncronos precisam de verificações adiadas. Ative uma tarefa de exportação, notificação, miniatura ou indexação como inquilino A, altere a propriedade ou associação antes de o trabalhador executar e inspecione onde o resultado chega. Decida se o trabalhador deve usar a autoridade capturada no momento do pedido ou reverificar a autoridade atual no momento da execução. Ambas as escolhas podem ser corretas para uma operação específica, mas uma mistura acidental cria fugas e trilhos de auditoria quebrados.

As ferramentas administrativas merecem identidades separadas e verificações de registo. O acesso do suporte atravessa frequentemente limites entre inquilinos por conceção, por isso uma regra simples de «inquilino diferente deve falhar» está errada. Teste se o operador tem a função e o contexto de caso exigidos, se a política visível para o cliente é cumprida, se o acesso expira e se o evento de auditoria identifica o operador em vez de se fazer passar pelo cliente.

A lógica de negócio exige uma história de abuso

Os testes de lógica de negócio começam com uma história proibida: um utilizador recebe valor, autoridade ou estado que não deveria receber ao executar ações válidas numa ordem ou combinação inválida. Rótulos genéricos de vulnerabilidades são insuficientes. O testador precisa de saber como convites, aprovações, quotas, reembolsos, créditos, transferências de propriedade e cancelamentos devem interagir.

O OWASP Web Security Testing Guide pede aos testadores que tentem ignorar passos do fluxo, repetir funções, falsificar pedidos, alterar o tempo e usar incorretamente funcionalidades válidas. A sua introdução mais antiga à lógica de negócio diz sem rodeios que a automação por scanners não consegue fornecer o conhecimento específico da aplicação nem a criatividade. Os agentes modernos melhoram a automação, mas não eliminam a lacuna de conhecimento. Um modelo pode sugerir que um cupão é reutilizável. Não consegue saber se a reutilização é promoção ou fraude até alguém indicar a regra.

Dê ao agente um modelo de estados com transições e invariantes permitidos. Num fluxo de aprovação, uma invariante pode dizer: «Um requerente não pode aprovar o seu próprio pagamento, mesmo depois de uma transferência de propriedade». Depois peça-lhe para gerar sequências com alterações de função, pedidos duplicados, cancelamento, repetição, concorrência e sessões desatualizadas. O agente consegue explorar muito mais sequências do que uma pessoa executará manualmente.

Os casos difíceis envolvem consequências fora da resposta HTTP. Dois pedidos de resgate concorrentes podem ambos devolver sucesso, enquanto uma reconciliação posterior remove um deles. Um cancelamento pode parar a tarefa visível, mas não revogar uma transferência assinada. Um convite aceite depois de quem o enviou perder o acesso pode criar uma associação órfã. Os testes devem observar registos contabilísticos, filas, permissões de objetos e estado posterior, não apenas códigos de estado.

Os testadores humanos justificam o seu lugar ao questionar o modelo indicado. Perguntam se os colaboradores de suporte podem combinar funções inofensivas, se um operador pode influenciar o próprio trilho de auditoria ou se um objeto «expirado» continua utilizável por outro canal. Um agente trabalha dentro dos objetivos e ferramentas que recebe. Uma pessoa pode reparar que os objetivos deixam de fora a parte perigosa do negócio.

O risco de dependências é mais do que uma versão vulnerável

Os testes de dependências têm quatro perguntas distintas: que pacotes estão presentes, se as suas versões conhecidas têm vulnerabilidades reportadas, se a compilação obteve os artefactos pretendidos e se a aplicação expõe realmente o comportamento vulnerável. A análise de composição de software (SCA) e os controlos de proveniência respondem às três primeiras de forma mais fiável do que uma revisão conversacional isolada.

Um agente é útil depois de existir o inventário. Pode inspecionar como uma dependência é chamada, determinar se a função afetada é alcançável, encontrar um controlo compensatório e preparar um patch de atualização com testes de regressão. Também pode assinalar comportamento arriscado de pacotes que não tenha identificador de vulnerabilidade, como um script de instalação que ganha acesso à rede ou uma nova biblioteca que recebe segredos no ambiente.

Não peça ao modelo para se lembrar de dados atuais de vulnerabilidades. Forneça-lhe uma fonte de avisos com data, o ficheiro de bloqueio resolvido e o inventário dos artefactos compilados. A memória do modelo não é uma base de dados de vulnerabilidades, e um manifesto de pacote não prova o que foi lançado. A proveniência SLSA faz uma distinção relacionada: descreve onde, quando e como um artefacto foi produzido. Não declara que o artefacto é seguro.

O alcance pode reduzir a prioridade da triagem, mas não deve apagar a responsabilidade. Sinalizadores de funcionalidades mudam, código inativo volta e dependências indiretas são chamadas de formas inesperadas. Registe porque uma descoberta foi adiada, que versão e caminho de chamada foram avaliados e que evento deve reabri-la. O agente pode manter este raciocínio, enquanto um inventário determinístico vigia esse evento.

Os nomes de pacotes também criam armadilhas de identidade. Uma dependência com o nome esperado pode vir do registo errado, um ficheiro de bloqueio pode apontar para uma localização mutável ou um passo de compilação pode descarregar código ausente do manifesto. Verifique origens resolvidas, hashes, assinaturas quando o ecossistema as suportar e acesso à rede durante a compilação. Um agente pode explicar discrepâncias, mas o sistema de compilação tem de impor as fontes que aceita.

Atualizações não são alterações automaticamente seguras. Uma versão de segurança pode alterar análise, predefinições de autorização ou serialização de formas que quebram uma aplicação. Crie uma reprodução mínima para o aviso, aplique a atualização num ramo isolado e execute tanto a prova de segurança como os testes funcionais. A evidência resultante fundamenta uma decisão. Um modelo dizer que a nova versão «deve ser compatível» não a fundamenta.

Os falsos positivos são um problema de conceção da evidência

Uma descoberta merece o tempo de um programador apenas quando traz uma alegação, evidência, impacto e um caminho reproduzível. Relatórios gerados por IA soam muitas vezes completos, mas falta-lhes uma destas partes. Texto de correção fluente torna mais difícil reparar em evidência fraca.

Exija que cada descoberta do agente identifique a revisão e o ambiente analisados, o componente afetado, pré-condições do atacante, o limite de segurança atravessado, o resultado observado ou inferido, os passos de reprodução e a incerteza. Marque descobertas inferidas do código-fonte de forma diferente de explorações executadas. Se o agente não conseguiu executar a aplicação, deve dizê-lo na descoberta, não esconder a limitação numa nota ao nível da análise.

Depois aplique um vocabulário simples de classificação: confirmado, provável, precisa de contexto, não reproduzível, risco aceite ou corrigido. «Falso positivo» deve significar que a alegação de segurança está errada, não que a equipa discorda da gravidade ou escolheu adiar o trabalho. Misturar estas decisões destrói o feedback. O agente não consegue aprender que regra falhou se cada ticket indesejado receber o mesmo rótulo.

A IA pode reduzir ruído ao agrupar rastos duplicados, verificar higienizadores e voltar a testar depois de uma correção. Também pode ampliar o ruído ao produzir dez variantes persuasivas de uma suspeita fraca. Elimine duplicados pela causa-raiz e pelo limite, não pelo URL. Uma verificação de propriedade em falta, usada por oito endpoints, é um defeito de engenharia com oito pontos de exposição.

Acompanhe a precisão por categoria e fonte de teste. Se os relatórios de cross-site scripting gerados por agentes forem geralmente válidos, mas as suas alegações de condições de corrida raramente se reproduzirem, encaminhe-os de forma diferente. Não reduza o desempenho a uma única pontuação para tipos de defeito não relacionados. Uma barreira deve falhar com base em evidência e política, não no adjetivo de confiança do modelo.

A responsabilidade fecha o ciclo. Cada descoberta aceite precisa de uma pessoa ou equipa responsável pela correção, de um método esperado de novo teste e de uma prova preservada que outro testador consiga executar. Se o relatório só existir numa conversa com um agente, desaparecerá quando a conversa, o modelo ou o fornecedor mudar. O trabalho de segurança torna-se duradouro quando a evidência sobrevive à ferramenta que a produziu.

A privacidade também importa durante a triagem. Código-fonte, corpos de pedidos, registos e amostras de base de dados podem conter credenciais ou dados de clientes. Minimize o que o agente recebe, oculte transcrições retidas, separe dados de teste de dados de produção e aplique as regras aprovadas de tratamento de dados da organização ao fornecedor do modelo e às suas ferramentas. Uma melhor deteção não justifica copiar um incidente inteiro de produção para um prompt sem controlo.

Um pentest humano testa as premissas em torno do teste

Um pentester experiente muda o plano quando a aplicação contradiz o briefing. Essa é a parte que os agentes ainda não substituíram. A pessoa entrevista responsáveis, resolve regras ambíguas, deteta atalhos operacionais, pede outra identidade e decide quando um comportamento estranho merece uma cadeia mais longa de experiências.

As pessoas também respondem por decisões sob evidência incompleta. Conseguem distinguir uma ação tecnicamente possível de um caminho de ataque credível, explicar uma falha composta a executivos e engenheiros e negociar uma prova segura quando a exploração pode danificar dados. Um agente autónomo deve parar no limite definido pelo seu operador. Se alargar esse limite em silêncio, torna-se outro risco de segurança.

Isto não significa que cada lançamento precise de um trabalho externo de uma semana. Use testes humanos onde a alteração e a consequência se encontram: um novo modelo de autorização, arquitetura de inquilinos, fluxo de pagamento ou crédito, plano administrativo, integração sensível, migração importante ou lançamento público. Agende trabalho periódico mais amplo com base no risco e volte a testar correções graves. Lançamentos rotineiros continuam a precisar de cobertura automatizada.

Dê ao testador os resultados do agente, rastos SAST, cobertura DAST, notas de arquitetura, contas de teste e premissas por resolver. O agente pode tratar do reconhecimento e de variações repetitivas enquanto o testador procura comportamentos surpreendentes. Assim, o tempo humano torna-se mais produtivo sem fingir que é dispensável.

Desconfie de alegações de «pentest autónomo» medidas pelo número de descobertas. Dez descobertas familiares de injeção não equivalem a um caminho demonstrado que atravesse atribuição de funções, autorização desatualizada e armazenamento de exportações. Avalie o trabalho pelos limites testados, qualidade da evidência e premissas importantes questionadas.

Pergunte quem é responsável pela limpeza antes de o trabalho começar. Contas de teste, ficheiros carregados, mensagens em fila, funções temporárias e sinalizadores de funcionalidades alterados podem sobreviver à análise. Uma liderança humana deve aprovar provas destrutivas, manter contacto com as operações e verificar a reposição. O agente pode seguir um script de limpeza, mas não consegue decidir que um estado de produção inexplicado é seguro para remover.

Um bom testador também relata o que não pôde ser testado. Compilações móveis em falta, funções indisponíveis, limites de taxa, callbacks de terceiros e ambientes instáveis reduzem a garantia. Os agentes tendem a continuar a trabalhar à volta dos obstáculos e a apresentar os caminhos que concluíram. O relatório final tem de dar destaque às exclusões para que um resultado limpo não seja confundido com cobertura completa.

Crie uma barreira com vários tipos de evidência

O programa certo atribui uma função a cada método e faz com que os resultados se encontrem nos mesmos requisitos de segurança. Use SAST para padrões determinísticos de código-fonte e ampla cobertura das alterações. Use SCA e proveniência para factos sobre dependências e compilação. Use DAST para comportamento implementado e verificações básicas em tempo de execução. Use agentes para ligar evidência, explorar fluxos autenticados, criar testes e melhorar a triagem. Use pessoas para definir política, questionar premissas de negócio e investigar alterações de grande impacto.

Uma política de lançamento pode então ser específica. Bloqueie uma compilação quando uma regra determinística de alta gravidade corresponder a um caminho não aprovado, quando uma invariante de autorização exigida falhar, quando surgir um marcador entre inquilinos ou quando uma exploração confirmada continuar aberta. Envie descobertas incertas do agente para revisão, com um prazo baseado na exposição. Não deixe a confiança declarada pelo modelo decidir se a produção avança.

Mantenha a evidência portátil. Exporte descobertas, testes gerados, transcrições de pedidos, versões de ferramentas, revisões, identidades, cobertura e classificações em formatos que a equipa consiga inspecionar sem o agente. Isto importa para auditorias, análise de incidentes, alterações de fornecedor e para o dia comum em que uma atualização do modelo muda o comportamento.

Para aplicações criadas por chat, aplica-se a mesma separação. O Koder.ai pode gerar aplicações web, de servidor e móveis e exportar o seu código-fonte, mas o software gerado continua a precisar de requisitos de segurança explícitos e testes independentes contra o resultado implementado. A criação rápida torna uma barreira clara ainda mais útil, porque a arquitetura e o código podem mudar depressa.

Execute o agente continuamente, mas transforme as suas melhores descobertas em testes de regressão determinísticos. Cada desvio de autorização confirmado deve tornar-se um caso de política. Cada fuga entre inquilinos deve acrescentar uma invariante no limite que falhou. Cada regra ruidosa deve receber uma classificação registada. Com o tempo, o agente deve deixar o sistema de testes mais preciso do que o encontrou.

Não pergunte qual ferramenta única vence. Pergunte se cada alegação importante tem evidência independente: o caminho de código foi revisto, o comportamento implementado foi exercitado, a regra de negócio veio de um responsável e uma pessoa questionou as premissas onde a falha causaria dano. Se uma dessas linhas estiver em branco, um «tudo em ordem» gerado por IA não a preenche.