O que mudou não é apenas outro conjunto de regras — é uma ponte entre preocupações de segurança em IA e fluxos de trabalho maduros de AppSec. O CodeQL agora rastreia valores não confiáveis que podem moldar o prompt do sistema de um modelo e sinaliza quando esses fluxos alcançam chamadas sensíveis de SDK. Ao expandir os sinks para APIs dos principais fornecedores, a detecção reconhece padrões do mundo real que os desenvolvedores usam para montar instruções do sistema, políticas de sessão e conexões de ferramentas. O resultado é um evento de segurança familiar: uma descoberta de fluxo de dados que pode ser triada, corrigida e prevenida por políticas, em vez de uma anedota ambígua de “má conduta de IA” que raramente se relaciona com controles CI/CD.

Para líderes de engenharia, isso reformula a injeção de prompt como um problema de higiene de dependências e validação de entrada. Quando prompts do sistema herdam strings controláveis pelo usuário — flags de recursos, configurações de locatário ou conteúdo CMS — os modelos podem ser coagidos a ignorar instruções, expor ferramentas ou vazar contexto. A abordagem do CodeQL traz esses riscos para SARIF, anotações de PR e métricas de linha de base, permitindo os mesmos caminhos de escalonamento que as classes clássicas de injeção. Crucialmente, ajuda os proprietários de produto a quantificar o risco em termos que os auditores entendem: fluxo de dados de fontes não confiáveis para sinks sensíveis, respaldado por consultas reproduzíveis e políticas versionadas.

Adotar essa capacidade é menos sobre reescrever prompts e mais sobre codificar limites. As equipes devem fixar uma versão atual do CodeQL, habilitar a nova consulta de injeção de prompt do sistema para JS/TS e executar linhas de base em toda a organização. Comece com repositórios que constroem agentes, chamadas de ferramentas ou pipelines RAG; depois expanda para serviços onde prompts são montados a partir de configurações. A orientação de triagem deve classificar fluxos por explorabilidade: grau de controle do usuário, presença de salvaguardas de template e poder da ferramenta a jusante. Onde persistirem lacunas, escreva pequenos modelos personalizados para chamadas proprietárias de SDK para garantir paridade de cobertura com suas interfaces reais de produção.

Espere limites: análise estática não pode simular completamente gráficos dinâmicos de ferramentas, composição de prompts entre serviços ou guardrails em tempo de execução como restrições de chamadas de função. Mas o mesmo valia para SSRF ou desserialização até que ecossistemas normalizassem padrões e linters. O panorama maior é a convergência: riscos de IA estão sendo normalizados em portões SDLC, criando uma linguagem comum entre segurança, plataforma e conformidade. Isso eleva o padrão para fornecedores e plataformas internas — lançar recursos de IA sem cobertura de varredura de código parecerá cada vez mais como lançar APIs sem testes de autenticação.