A adoção de agentes de inteligência artificial (IA) em redes de TI, pipelines de desenvolvimento de software e outros fluxos de trabalho automatizados cresceu de forma acelerada nos últimos anos. Ferramentas que analisam código, sugerem correções e até executam comandos diretamente em repositórios corporativos passaram a fazer parte da rotina de equipes de tecnologia. Esse cenário, porém, trouxe à tona um tipo específico de risco de segurança: a injeção de prompt malicioso, capaz de explorar a forma como modelos de linguagem interpretam instruções dentro desses ambientes.
A pesquisa conduzida pela empresa de segurança Aikido chama atenção para esse tipo de vulnerabilidade em integrações com agentes de IA, especialmente quando esses sistemas operam de modo automatizado em plataformas como GitHub e GitLab. Em vez de atacar diretamente servidores ou bancos de dados, agentes maliciosos podem explorar a lógica do próprio modelo de linguagem, inserindo comandos escondidos em mensagens que, à primeira vista, parecem apenas dados comuns de desenvolvimento, como mensagens de commit, issues ou pull requests. Além disso, como esses dados trafegam por diversos serviços interligados, a superfície de ataque cresce rapidamente e dificulta a detecção precoce de um comprometimento.
O que é injeção de prompt malicioso em desenvolvimento de software?
A chamada injeção de prompt ocorre quando um atacante insere instruções ocultas em conteúdos que um modelo de linguagem irá processar, com o objetivo de manipular o comportamento da IA. Em fluxos de desenvolvimento de software, isso pode acontecer em diversos pontos do pipeline: na descrição de um bug, em um comentário de revisão de código, em arquivos de documentação ou até em mensagens de commit. Quando uma equipe integra um agente de IA ao processo, esse agente passa a consumir esses dados como entrada e, se os controles forem insuficientes, pode interpretar esses trechos como comandos legítimos.
No contexto de ferramentas como Claude Code, Google Gemini, Codex da OpenAI e a funcionalidade AI Inference do GitHub, essa vulnerabilidade se torna relevante porque esses agentes, muitas vezes, recebem altos privilégios dentro dos repositórios. Isso inclui permissão para editar arquivos, abrir ou aprovar pull requests, executar comandos em pipelines e interagir com outros serviços conectados. Portanto, se um prompt malicioso for tratado como instrução, o modelo pode, por exemplo, modificar código de forma indevida ou expor informações sensíveis.
Além disso, em ambientes corporativos complexos, esses agentes costumam ser integrados a sistemas de rastreamento de tarefas (como Jira), plataformas de observabilidade e ferramentas de segurança. Isso cria um ecossistema em que uma única injeção de prompt bem-sucedida pode se propagar por vários sistemas, afetando não apenas o código-fonte, mas também dashboards de monitoramento, playbooks de resposta a incidentes e documentação técnica compartilhada entre equipes. Como consequência, equipes de operação, desenvolvimento e segurança podem tomar decisões com base em informações já manipuladas pela ação maliciosa.
Como a injeção de prompt afeta agentes de IA em GitHub Actions e GitLab?
Quando agentes de IA são integrados a fluxos automatizados, como GitHub Actions e pipelines do GitLab, o risco se amplia de forma significativa. Nessas situações, o modelo não atua apenas como assistente, mas como parte de um processo contínuo: analisa alterações, gera relatórios, sugere correções e, em alguns casos, toma ações automaticamente. A pesquisa da Aikido mostrou que agentes maliciosos podem enviar prompts embutidos em elementos aparentemente rotineiros, como pedidos de pull ou relatos de problemas, explorando a confiança da automação nesses canais.
Persistência de contexto e reinterpretação de comandos
Essas mensagens são repassadas à IA como texto de entrada, e o modelo tende a guardar o contexto e “lembrar” do que leu ao longo da sessão. Em determinados cenários, esse conteúdo pode ser reinterpretado mais tarde como se fosse uma instrução do usuário legítimo, levando o agente a executar comandos shell, editar arquivos sensíveis ou até publicar conteúdo malicioso em repositórios. Além disso, como muitos pipelines executam tarefas em paralelo, uma instrução maliciosa pode influenciar múltiplas etapas quase ao mesmo tempo, o que aumenta a dificuldade de rastrear a origem do problema.
Impactos práticos em automações de CI/CD
Em projetos que permitem maior automação, o impacto potencial inclui:
- Alteração silenciosa de código em bibliotecas e serviços críticos;
- Criação ou aprovação de pull requests contendo backdoors ou funções indesejadas;
- Execução de scripts que expõem arquivos de configuração, segredos ou tokens;
- Contaminação de documentação com instruções enganosas que induzem a erros futuros.
Em alguns casos, os agentes também podem interagir com sistemas de CI/CD para gerenciar deploys, aprovar promoções de versões entre ambientes (dev, homologação, produção) ou disparar rollbacks. Um prompt malicioso bem elaborado pode instruir a IA a desabilitar testes, ignorar verificações de segurança ou promover automaticamente uma versão comprometida para produção, sem passar pelos controles manuais habituais. Por isso, times de engenharia de confiabilidade precisam tratar agentes de IA como componentes críticos da cadeia de entrega, e não apenas como “ferramentas auxiliares”.
Por que os modelos de IA têm dificuldade em separar dados e instruções?
O ponto central destacado por especialistas, como o pesquisador Rein Daelman, é uma fragilidade estrutural de muitos modelos de linguagem de grande porte (LLMs): a dificuldade em diferenciar, de forma consistente, o que é apenas dado para análise e o que é um comando que deve ser seguido. Em um arquivo de log ou em uma mensagem de commit, por exemplo, pode haver trechos que parecem instruções claras, como “execute tal comando” ou “envie este arquivo para outro local”. Assim, o modelo precisa decidir, sem um delimitador técnico rígido, se aquilo constitui dado passivo ou ordem ativa.
Como o modelo foi treinado para seguir instruções textuais, a meta de um atacante é justamente confundir essa fronteira, fazendo com que a IA interprete um trecho de dado como se fosse um prompt legítimo. Essa ambiguidade se agrava em ambientes em que o agente de IA tem acesso direto a tokens privilegiados, como chaves de API e credenciais de repositórios. Segundo os testes divulgados, em muitos casos equipes de pesquisa conseguiram induzir o vazamento de tokens do GitHub ou forçar o modelo a tomar ações que, na prática, equivalem a uma invasão.
Outro agravante é que LLMs foram treinados em grandes quantidades de texto da internet, onde padrões como “siga as instruções abaixo” ou “ignore todas as regras anteriores” são comuns em exemplos de prompts. Isso torna o modelo especialmente sensível a esse tipo de formulação, mesmo quando aparece em contextos que deveriam ser tratados apenas como dado, como trechos de código, logs ou documentação histórica de um projeto. Consequentemente, sem camadas adicionais de validação, o modelo tende a seguir esse tipo de comando textual em vez de tratá-lo apenas como conteúdo inofensivo.
Que medidas de mitigação estão sendo adotadas pelas empresas?
Após o relatório da Aikido, empresas responsáveis por ferramentas de IA começaram a aplicar ajustes em seus produtos. O Google, por exemplo, recebeu uma prova de conceito detalhando a exploração da vulnerabilidade e divulgou correções específicas para o Gemini CLI. A correção envolveu, entre outros pontos, limitar o tipo de conteúdo que o agente pode interpretar como instrução, reforçar validações de contexto e reduzir privilégios em determinados cenários, além de orientar usuários a configurarem escopos de acesso mais restritos.
No caso de soluções como Claude Code e Codex, a exploração exige, em regra, algum nível de permissão de edição no repositório, mas a pesquisa mostrou que comandos simples podem contornar configurações padrão em projetos mais abertos. Isso evidencia a importância de práticas como:
- Revisar permissões concedidas a agentes de IA em repositórios e pipelines;
- Separar claramente o que é dado de entrada do que será tratado como instrução;
- Implementar filtros para detectar padrões suspeitos em mensagens, commits e issues;
- Registrar e auditar todas as ações tomadas automaticamente pelos agentes de IA;
- Restringir o uso de tokens privilegiados, com escopos reduzidos e rotação frequente.
Algumas organizações também começaram a adotar camadas intermediárias (“gateways de IA”) que recebem as solicitações do agente, aplicam políticas de segurança, mascaram ou removem trechos potencialmente perigosos e só então repassam o conteúdo ao modelo. Esses gateways podem aplicar validações adicionais, como listas de bloqueio de comandos, análise estática de sugestões de código geradas pela IA e exigência de aprovação humana antes de qualquer alteração crítica em repositórios produtivos. Além disso, equipes de segurança têm usado esses gateways para aplicar monitoramento em tempo real e alertas automáticos quando o agente tenta executar ações fora do comportamento esperado.
Como organizações podem lidar com a vulnerabilidade de injeção de prompt?
A discussão sobre injeção de prompt em agentes de IA utilizados em redes de TI e desenvolvimento de software reforça a necessidade de tratar a segurança de IA como parte integrante da segurança da informação. Em 2025, com modelos cada vez mais presentes em ambientes produtivos, organizações que adotam essas ferramentas precisam considerar não apenas falhas convencionais de software, mas também riscos ligados à forma como os modelos interpretam e executam comandos. Portanto, o tema deve entrar em comitês de segurança, planos de continuidade de negócios e políticas formais de governança de dados.
Equipes técnicas têm adotado abordagens que incluem treinamento interno sobre boas práticas de uso de IA, revisão da arquitetura de automações e inclusão de cenários de prompt injection em testes de segurança. O objetivo é reduzir a superfície de ataque e garantir que agentes de IA, mesmo com acesso a fluxos críticos, atuem de forma controlada e rastreável. Dessa forma, empresas podem continuar usando recursos avançados de automação e análise de código, ao mesmo tempo em que mantêm atenção constante às novas formas de exploração que surgem com a evolução dos modelos de linguagem. Em complemento, muitas organizações vêm criando playbooks específicos de resposta a incidentes envolvendo IA, prevendo desde a revogação rápida de tokens até a revisão forense de ações automatizadas.
FAQ — Perguntas frequentes sobre injeção de prompt em IA (tópicos adicionais)
1. Injeção de prompt é a mesma coisa que ataque de engenharia social?
Não. Eles são relacionados, mas não idênticos. A injeção de prompt é uma forma de “engenharia social aplicada ao modelo”, em que o alvo principal é a IA e não diretamente um humano. Entretanto, o raciocínio de explorar ambiguidades e confiança excessiva em instruções textuais é semelhante ao de ataques de engenharia social tradicionais. Além disso, em muitos casos, o atacante combina engenharia social humana com injeção de prompt para aumentar a chance de sucesso.
2. Pequenas empresas ou times menores também precisam se preocupar com isso?
Sim. Mesmo equipes pequenas que usam agentes de IA para automatizar tarefas de revisão de código, geração de documentação ou integração contínua podem sofrer impactos relevantes, como vazamento de segredos em repositórios ou inclusão de código malicioso em bibliotecas internas. A complexidade do ambiente pode ser menor, mas o dano potencial ainda é significativo. Por isso, práticas simples, como revisão manual de mudanças críticas e uso de tokens com escopo reduzido, já trazem ganhos importantes.
3. Ferramentas de segurança tradicionais (como scanners SAST/DAST) detectam injeção de prompt?
Normalmente não. Scanners de código e testes de aplicação focam em vulnerabilidades tradicionais (injeção de SQL, XSS, problemas de autenticação, etc.). A injeção de prompt ocorre na camada de interação com o modelo de linguagem, o que exige ferramentas e controles específicos, como validação de contexto, filtros de conteúdo e auditoria das ações da IA. Dessa maneira, organizações começam a avaliar soluções de “AI security” dedicadas, que complementam o arsenal tradicional.
4. Há padrões ou frameworks de mercado para segurança de IA?
Estão surgindo iniciativas como guias do NIST, OWASP Top 10 para aplicações de IA e boas práticas de provedores de nuvem, mas o ecossistema ainda está em evolução. Muitas organizações têm criado políticas internas baseadas em princípios de “zero trust” aplicados a agentes de IA, controle de acesso mínimo e revisão humana obrigatória em etapas críticas. Além disso, comunidades técnicas vêm compartilhando modelos de threat modeling específicos para fluxos com LLMs, o que ajuda a padronizar avaliações de risco.
5. A remoção de privilégios administrativos da IA resolve o problema?
Reduz bastante o risco, mas não elimina totalmente. Mesmo sem privilégios administrativos, a IA pode gerar código inseguro, sugerir configurações equivocadas ou produzir documentação enganosa que influencie decisões técnicas futuras. A combinação de privilégios mínimos, revisão humana e monitoramento contínuo é mais eficaz do que confiar apenas em um único controle. Em resumo, organizações obtêm melhores resultados quando tratam agentes de IA como qualquer outro componente crítico de software, sujeitando-os ao mesmo rigor de segurança e conformidade.
