Um desenvolvedor pede a um assistente que corrija uma consulta de busca de clientes que está falhando. A correção sugerida faz o teste passar, mas substitui o filtro de escopo do tenant (inquilino/cliente) por uma busca baseada apenas no customerId. Após a integração do pull request, um usuário que conhece o identificador de outro tenant recebe o registro daquele cliente. O atacante não precisou de acesso ao repositório, ao sistema de CI ou ao assistente de codificação; ele utilizou apenas uma requisição comum da aplicação contra um endpoint cuja verificação de autorização havia desaparecido silenciosamente.
Uma alteração não confiável é qualquer proposta de código, dependência, configuração ou edição de fluxo de trabalho que ainda não tenha passado por controles independentes de seu autor. O resultado gerado pelo assistente enquadra-se nessa categoria mesmo quando o código compila, possui uma explicação plausível e corrige o defeito relatado. O assistente gerou o texto a partir do prompt e do contexto do repositório. Nenhum desses fatores prova que a consulta resultante preserva o limite de isolamento entre tenants da aplicação.
O fluxo relevante atravessa diversos limites. A correção do assistente, a versão de pacote sugerida e qualquer configuração gerada entram no repositório como artefatos não confiáveis. O sistema de CI examina a alteração proposta, mas não garante automaticamente que a autorização esteja correta. O ambiente de produção executa apenas o artefato integrado, no qual a ausência do filtro expõe os dados de um cliente para outro tenant. O mapa de limites a seguir mantém esses artefatos distintos:
O mapa de limites mostra por que o processo utiliza um contrato de segurança. Trate todo artefato produzido por IA como não confiável até que uma revisão humana independente e as verificações automatizadas obrigatórias aceitem a alteração. O modelo nunca é o ponto de imposição de regras. Um prompt que solicita isolamento de tenant (inquilino/cliente) representa uma preferência transmitida pelo mesmo canal que o código sugerido, e não um controle que bloqueia uma mesclagem (merge) insegura.
Para a correção de busca de clientes, o revisor do pull request verifica se a consulta ainda aplica a permissão de acesso ao tenant do usuário autenticado. A CI (Integração Contínua) verifica diferentes evidências: a análise de código-fonte examina padrões de implementação, a análise de dependências examina o pacote recém-adicionado e a varredura de segredos examina o código-fonte e as configurações alterados em busca de credenciais. A proteção de branch do repositório impõe a decisão de mesclagem ao exigir essas verificações e aprovações. Nenhum controle deve depender da afirmação do assistente de que a correção é segura.
Regra do exame
O código gerado por IA só é aceito quando a revisão independente e os pontos de verificação de segurança (security gates) obrigatórios produzem evidências registradas. A saída do modelo e a redação do prompt não impõem controle de acesso.
Cada controle tem limitações. Uma revisão pode deixar passar um erro sutil de fluxo de dados; portanto, verificações automatizadas fornecem um sinal adicional. Um scanner pode deixar passar uma lógica de autorização que exige contexto da aplicação; portanto, uma revisão qualificada permanece obrigatória. Um pipeline bem-sucedido não prova a ausência de vulnerabilidades. Ele prova que as evidências exigidas pelo ponto de verificação definido existem para esta revisão. Quando um ponto de verificação obrigatório falha, o repositório registra a constatação, bloqueia a mesclagem de acordo com a política e preserva um rastro de auditoria para a decisão de aceitação ou exceção.
O artefato em questão é um pull request que adiciona GET /search?q=... a um serviço web multilocatário (multi-tenant) e inclui uma dependência de busca textual. Uma solicitação do usuário é uma entrada não confiável. O manipulador (handler) recebe a identidade do usuário autenticado, constrói uma consulta ao banco de dados e deve aplicar a permissão de acesso ao tenant desse usuário antes que o banco de dados retorne registros. A operação de banco de dados é executada sob a identidade de serviço da aplicação, enquanto a camada de consulta ou de políticas impõe restrições sobre o que o usuário final pode visualizar. Se o novo endpoint aceitar um tenantId da requisição sem compará-lo com a permissão autenticada, o raio de impacto abrange todos os registros acessíveis por meio dessa identidade de serviço.
O próprio pull request não é confiável. O diff pode remover o predicado de tenant, o manifesto de dependências pode introduzir um pacote vulnerável ou inadequado, e a configuração gerada pode conter um segredo exposto. A explicação do assistente não é suficiente para resolver essas questões. As evidências provêm do diff, do manifesto de dependências alterado, das categorias do scanner, da aprovação do revisor e do registro de merge.
Um teste estático de segurança de aplicações (SAST) examina o código-fonte e o fluxo de dados em nível de código em busca de padrões de vulnerabilidade conhecidos. A análise de composição de software (SCA) examina dependências e metadados de componentes em busca de riscos relacionados à cadeia de suprimentos. A varredura de segredos busca, nos artefatos alterados do repositório, credenciais ou tokens que não deveriam ser submetidos ao controle de versão (commit). Essas verificações examinam artefatos diferentes; portanto, um resultado positivo em uma delas não substitui a outra. O fluxo da requisição e o fluxo de CI mostram a origem das sugestões e em que ponto a verificação gera evidências de aceitação: