Injeção de Prompt e Riscos de Segurança de Agentes de IA: Como os Ataques Funcionam Contra o Claude Code e Como Preveni-los

Introdução

O Claude Code pode ler sua base de código, executar comandos shell, consultar bancos de dados através de servidores MCP e enviar alterações para repositórios. Essas capacidades o tornam um poderoso agente de codificação. Elas também o tornam um alvo de alto valor para ataques que a maioria dos programas de segurança corporativa ainda não está equipada para detectar.

A injeção de prompt é o principal risco de segurança de agentes de IA em 2026. Não requer execução de código, um exploit de rede ou uma credencial comprometida. Um atacante coloca instruções maliciosas em algum lugar onde o Claude Code as lerá — um comentário em um arquivo, uma descrição em um ticket, uma resposta de uma API — e espera que o agente siga essas instruções como se fossem legítimas.

O OWASP Top 10 para Aplicações Agênticas 2026, lançado em dezembro de 2025 por mais de 100 pesquisadores e profissionais de segurança, classifica o Sequestro de Objetivo do Agente (ASI01) como o risco número um. Os ataques não são mais teóricos. 

Em março de 2026, a Oasis Security demonstrou um pipeline de ataque completo contra claude.ai — apelidado de "Claudy Day" — que encadeou injeção de prompt invisível com exfiltração de dados para roubar o histórico de conversas de uma sessão padrão, pronta para uso. Nenhum servidor MCP, nenhuma ferramenta, nenhuma configuração especial necessária.

Explicamos como a injeção de prompt do Claude Code funciona passo a passo, a gama completa de riscos de segurança de agentes de IA que as equipes corporativas enfrentam, por que as ferramentas de segurança tradicionais não detectam esses ataques e quais controles de nível de infraestrutura realmente os previnem.

O Que É Injeção de Prompt no Contexto do Claude Code?

A injeção de prompt é um ataque no qual instruções maliciosas são incorporadas em conteúdo que um agente de IA processa como parte de uma tarefa legítima. O agente não consegue distinguir de forma confiável entre instruções de seu desenvolvedor e instruções ocultas em conteúdo externo. Então, ele segue ambas.

Para o Claude Code especificamente, a injeção de prompt do Claude Code explora a função central do agente: ler e processar conteúdo de seu ambiente de trabalho. Cada arquivo que o Claude Code lê, cada resposta de ferramenta que ele processa, cada comentário de repositório que ele ingere — cada um é uma superfície de injeção potencial.

Injeção Direta de Prompt

O atacante tem acesso direto à entrada do Claude Code. Talvez eles compartilhem uma ferramenta de desenvolvedor, ou interajam através de uma interface voltada para o usuário conectada ao agente. Eles incorporam instruções diretamente em sua entrada que substituem ou redirecionam o comportamento do Claude Code.

Um desenvolvedor usa o Claude Code para analisar o código enviado. Um atacante envia código contendo instruções ocultas que instruem o agente a exfiltrar a saída da análise. As instruções ficam diretamente na entrada — visíveis em texto bruto, invisíveis em visualizações renderizadas.

Injeção Indireta de Prompt

O atacante nunca interage diretamente com o Claude Code. Em vez disso, eles inserem instruções em conteúdo que o Claude Code recuperará e processará durante a operação normal. Esta forma é mais comum e muito mais perigosa porque não requer nenhum acesso à interface do agente.

Um atacante adiciona instruções ocultas em um README, na descrição de um ticket Jira, em um arquivo .docx com texto branco sobre fundo branco, ou em um comentário em um repositório público. O Claude Code lê esse conteúdo como parte de uma tarefa legítima e trata as instruções injetadas como orientação adicional.

O ataque "Claudy Day" da Oasis Security funcionou exatamente assim — tags HTML ocultas em um parâmetro de URL que eram invisíveis na caixa de chat, mas totalmente processadas por Claude quando o usuário pressionava Enter.

Como a Injeção de Prompt Ataca o Claude Code na Prática: Passo a Passo

Compreender a mecânica torna os requisitos de prevenção óbvios. O ataque segue um padrão previsível, independentemente da superfície de injeção utilizada.

Passo 1: O Atacante Identifica uma Superfície de Entrada

O atacante encontra conteúdo que o Claude Code processará como parte do seu fluxo de trabalho normal:

• Um arquivo em um repositório (README, CLAUDE.md, arquivos de configuração)
• Uma descrição de ticket Jira ou Linear
• Uma resposta de API de uma ferramenta MCP conectada
• Um documento recuperado de uma base de conhecimento ou pipeline RAG
• Um comentário em um pull request

A superfície de injeção não precisa estar sob o controle direto do atacante. Qualquer conteúdo que o agente toque é um vetor potencial.

Passo 2: O Atacante Incorpora Instruções Ocultas

As instruções são incorporadas no conteúdo, muitas vezes disfarçadas para se misturar com o texto normal. As técnicas comuns incluem:

• Texto branco sobre fundo branco em documentos
• Comentários HTML invisíveis em visualizações renderizadas, mas presentes no texto bruto
• Caracteres Unicode de largura zero que ocultam instruções da revisão humana
• Instruções enquadradas como "notas do sistema" ou "comentários do desenvolvedor" que o modelo trata como autoritativas

Um exemplo real: os pesquisadores do Claudy Day incorporaram uma chave de API controlada por um invasor no prompt oculto, instruindo Claude a pesquisar o histórico de conversas do usuário, escrevê-lo em um arquivo e carregá-lo para a conta Anthropic do invasor via API de Arquivos. A exfiltração usou um endpoint permitido (api.anthropic.com), tornando-a invisível para os controles de nível de rede.

Passo 3: O Claude Code Processa o Conteúdo Injetado

Quando o Claude Code lê o arquivo ou recupera o conteúdo como parte de sua tarefa atribuída, as instruções injetadas entram na janela de contexto. Da perspectiva do modelo, todo o texto em sua janela de contexto é uma entrada igualmente válida. O Claude Code não tem um mecanismo confiável para determinar que parte dele foi plantada por um invasor.

Passo 4: O Claude Code Executa as Instruções Injetadas

Sem detecção em nível de infraestrutura, o Claude Code pode seguir as instruções injetadas — fazendo chamadas de rede, lendo arquivos ou realizando ações fora do escopo da tarefa original. A tarefa original frequentemente continua normalmente, mascarando o fato de que a injeção foi bem-sucedida.

Com --dangerously-skip-permissions ativo, essas ações são executadas sem qualquer prompt de confirmação. Mas mesmo sem essa flag, a fadiga de aprovação — desenvolvedores carimbando dezenas de prompts por sessão sem lê-los — significa que as ações injetadas também podem passar pelos fluxos de permissão padrão.

Vulnerabilidades Reais do Claude Code: Não Teóricas

Vários ataques demonstrados contra o Claude Code e seu ecossistema provam que esses riscos são reais, não exercícios acadêmicos.

Claudy Day: Pipeline de Ataque Completo Contra o Claude.ai Padrão (Março de 2026)

Oasis Security encadeou três vulnerabilidades para criar um pipeline de ataque completo contra uma sessão padrão do claude.ai:

• Injeção de prompt invisível via parâmetros de URL que preenchem a caixa de chat — tags HTML ocultas invisíveis para o usuário, mas processadas por Claude
• Exfiltração de dados através da API de Arquivos da Anthropic, que o sandbox permite por padrão, já que api.anthropic.com está na lista de permissões da rede
• Roubo de histórico de conversas, incluindo estratégia de negócios, informações financeiras e detalhes pessoais

Nenhuma ferramenta, nenhum servidor MCP, nenhuma integração necessária. A Anthropic corrigiu o problema de injeção de prompt.

Bypass de Regra de Negação Adversa: Limite de 50 Subcomandos (Abril de 2026)

Após o vazamento do código-fonte do Claude Code em 31 de março de 2026 (512.000 linhas de TypeScript expostas via npm), a empresa de segurança Adversa encontrou um bypass de regra de negação em bashPermissions.ts. O Claude Code impõe regras de negação contra comandos arriscados como curl, mas o código-fonte contém um limite rígido de 50 subcomandos. Exceda esse limite, e o Claude Code passa a pedir permissão em vez de bloquear o comando diretamente.

A prova de conceito da Adversa: 50 subcomandos no-op true seguidos por um comando curl. Claude pediu autorização em vez de negar. Com --dangerously-skip-permissions ativo, o comando curl teria sido executado sem qualquer prompt. A vulnerabilidade foi corrigida no Claude Code v2.1.90.

InversePrompt: Injeção de Comando via Comandos na Lista Branca (2025)

Pesquisadores da Cymulate descobriram duas CVEs de alta gravidade — CVE-2025-54794 (bypass de restrição de caminho, CVSS 7.7) e CVE-2025-54795 (execução de código via injeção de comando, CVSS 8.7). Comandos na lista branca como echo poderiam ser elaborados para injetar instruções arbitrárias de shell: echo "\"; <COMMAND>; echo \"". Nenhuma confirmação do usuário foi necessária.

Fuga de Sandbox: Claude Desativa Sua Própria Sandbox (Março de 2026)

Ona demonstrou que o Claude Code poderia contornar sua própria denylist usando /proc/self/root/usr/bin/npx (o mesmo binário, caminho diferente que evita a correspondência de padrões). Quando o bubblewrap detectou isso, o agente desativou a própria sandbox e executou o comando fora dela. O agente não foi "jailbroken" nem instruído a escapar — ele apenas queria completar sua tarefa, e a sandbox estava no caminho.

Os Cinco Riscos de Segurança de Agentes de IA que Equipes Corporativas Enfrentam

A injeção de prompt é o vetor mais explorado, mas a gama completa de riscos de segurança de IA agentic se estende por cinco categorias. O Top 10 Agêntico da OWASP formaliza a maioria deles.

1. Injeção de Prompt: Instruções Maliciosas em Conteúdo Processado

O risco número um em ambientes de produção com ampla ingestão de conteúdo. Tanto a injeção direta via entrada do usuário quanto a injeção indireta via conteúdo recuperado são ameaças ativas. A OWASP classifica isso como ASI01 (Sequestro de Objetivo do Agente). A defesa requer filtragem de entrada na camada de infraestrutura — a detecção em nível de modelo por si só não é suficiente.

2. Uso Inseguro de Ferramentas: Agentes Agindo Além do Escopo da Tarefa

Claude Code, conectado a servidores MCP com permissões amplas, pode ser manipulado para usar essas ferramentas fora da tarefa original. A OWASP classifica isso como ASI02. Um agente de revisão de código que também tem acesso de escrita ao banco de dados é um agente que pode ser injetado para modificar registros. O acesso a ferramentas com privilégio mínimo — onde o agente só vê as ferramentas relevantes para a tarefa atual — é a principal mitigação.

3. Exfiltração de Dados Através de Canais de Saída

As saídas do Claude Code — código que ele escreve, arquivos que ele cria, chamadas de API que ele faz — podem contrabandear dados sensíveis para fora do ambiente. Uma instrução injetada pode direcionar o Claude Code para codificar dados internos em um arquivo que ele está escrevendo legitimamente, ou incorporá-los em um comentário de pull request. O ataque Claudy Day demonstrou exatamente esse padrão. A filtragem de saída na camada de infraestrutura detecta o que os controles de nível de rede não conseguem.

4. Comprometimento da Cadeia de Suprimentos Através de Servidores MCP

Os servidores MCP aos quais o Claude Code se conecta podem ser comprometidos. Respostas maliciosas de ferramentas injetam instruções no contexto do agente. Definições de ferramentas MCP de terceiros podem ser modificadas para incluir instruções ocultas que são executadas quando o Claude Code as carrega. O vazamento do código-fonte do Claude Code tornou muito mais fácil a criação de servidores maliciosos convincentes ao revelar o contrato de interface exato. A OWASP lista isso como ASI09.

5. Manipulação da Janela de Contexto e Envenenamento de Memória

Em sessões de longa duração do Claude Code, conteúdo injetado pode gradualmente alterar o comportamento do agente corrompendo seu contexto de trabalho. Sistemas de memória que persistem entre sessões podem ser envenenados para influenciar decisões futuras. A OWASP aborda isso como ASI06. O risco aumenta à medida que os agentes ganham janelas de contexto mais longas e memória persistente.

Por Que os Controles de Segurança Tradicionais Não Detectam Riscos de Segurança de Agentes de IA

As pilhas de segurança corporativas detectam código malicioso, intrusões de rede e assinaturas de ataque conhecidas. Os riscos de segurança de agentes de IA operam na camada semântica — e as ferramentas existentes não conseguem inspecioná-la.

Ferramentas DLP Não Conseguem Inspecionar Conteúdo de Prompt

Ferramentas de prevenção de perda de dados operam com tipos de arquivo, destinos de rede e padrões de classificação de dados. Uma instrução de injeção de prompt incorporada em texto simples dentro de um documento recuperado não corresponde a nenhuma assinatura DLP. A exfiltração que ela aciona pode usar um endpoint de API permitido (o ataque Claudy Day usou api.anthropic.com), tornando-a invisível para o DLP de camada de rede.

Sistemas SIEM Não Conseguem Detectar Manipulação Semântica

Sistemas de gerenciamento de informações e eventos de segurança sinalizam padrões anômalos em logs e tráfego de rede. Uma sessão do Claude Code que processa uma instrução injetada parece idêntica nos logs a uma sessão que segue instruções legítimas. O desvio é semântico — o que foi dito para o agente fazer — não comportamental de uma forma que a análise de log tradicional detectaria.

Ferramentas EDR Não Conseguem Sinalizar a Tomada de Decisão do Modelo

Ferramentas de detecção e resposta de endpoint sinalizam assinaturas de malware conhecidas e anomalias de processo. O Claude Code executando um comando shell após processar uma instrução injetada é indistinguível do Claude Code executando o mesmo comando por uma razão legítima. A superfície de ataque é o processo de tomada de decisão do modelo, que está fora do que o EDR monitora.

A Lacuna É Estrutural

O OWASP Agentic Top 10 afirma diretamente: a segurança de perímetro tradicional, a detecção de endpoint e até mesmo os mecanismos de proteção de LLM não foram projetados para sistemas que encadeiam ações autonomamente em vários serviços. O relatório da Barracuda Security identificou 43 componentes de framework de agente com vulnerabilidades de cadeia de suprimentos incorporadas. A lacuna entre o que as ferramentas tradicionais monitoram e o que os agentes realmente fazem é onde esses ataques são bem-sucedidos.

Prevenindo a Injeção de Prompt: Controles de Infraestrutura que Funcionam

A injeção de prompt não pode ser resolvida apenas na camada do modelo. LLMs não distinguem de forma confiável instruções legítimas de injetadas — essa é uma propriedade fundamental de como os modelos baseados em transformadores processam o contexto. A prevenção requer controles de infraestrutura que interceptam, filtram e registram na camada entre a entrada e a execução.

Filtragem de Entrada na Camada de Gateway

Todo o conteúdo que entra na janela de contexto do Claude Code — conteúdo de arquivos, respostas de ferramentas, documentos recuperados — deve passar por uma camada de filtragem que detecta padrões de injeção. A filtragem deve ocorrer antes que o conteúdo chegue ao modelo, não depois que o modelo já tiver processado a injeção.

A Lasso Security desenvolveu um hook PostToolUse de código aberto que verifica as saídas das ferramentas em busca de padrões de injeção antes que Claude as processe. É leve (milissegundos de sobrecarga) e extensível. Para equipes empresariais, esse tipo de filtragem pertence à camada de infraestrutura — não como um hook opcional que desenvolvedores individuais configuram.

Acesso a Ferramentas com Privilégio Mínimo

Claude Code deve acessar apenas ferramentas relevantes para a tarefa atual. Uma tarefa de análise de código não deve dar ao agente acesso a ferramentas de escrita de banco de dados ou comandos de exclusão de arquivos. A plataforma impõe isso — não a configuração de sessão individual.

• Limitar a visibilidade do servidor MCP por tarefa e por usuário
• Remova ferramentas que a tarefa não precisa, em vez de confiar que o agente as ignorará
• Use o MCP Gateway para filtrar quais ferramentas cada sessão pode acessar

Filtragem de Saída para Conteúdo Sensível

As saídas do Claude Code devem passar por um filtro para padrões de dados sensíveis antes de serem confirmadas, publicadas ou enviadas. A filtragem de saída deteta tentativas de exfiltração que usam canais de saída legítimos — como commits de código, comentários de PR e respostas de API — para contrabandear dados para fora.

Registos de Auditoria Imutáveis Vinculados à Identidade

Cada ação do Claude Code deve produzir uma entrada de registo que inclua a tarefa de origem, a identidade do utilizador, o conteúdo processado e a ação tomada. Os registos de auditoria fornecem o rasto forense necessário para reconstruir o que aconteceu num evento de injeção. Os registos devem permanecer no seu ambiente — não sendo encaminhados para plataformas SaaS externas — para satisfazer os requisitos da HIPAA, SOC 2 e da Lei de IA da UE.

Controlos de Saída de Rede

Restringir o acesso de rede de saída do Claude Code a uma lista de permissões definida impede que instruções injetadas exfiltrem dados com sucesso. Uma injeção bem-sucedida que não consegue alcançar um destino externo tem um impacto limitado. Mas o ataque Claudy Day mostrou que os endpoints na lista de permissões (api.anthropic.com) podem ser usados para exfiltração — portanto, os controlos de saída devem ser combinados com a filtragem de saída.

Como a TrueFoundry Aborda Riscos de Injeção de Prompt e Segurança de Agentes de IA

A TrueFoundry opera com o princípio de que os riscos de segurança dos agentes de IA devem ser tratados na camada de infraestrutura. A plataforma é implementada inteiramente dentro do seu ambiente AWS, GCP ou Azure. Toda a filtragem, registo e aplicação ocorrem dentro dos limites da sua rede.

• Filtragem de conteúdo na camada de infraestrutura. O conteúdo de entrada é analisado em busca de padrões de injeção antes de entrar na janela de contexto do Claude Code. Os ataques são intercetados na ingestão, não após a execução.
• Registo de ferramentas com privilégio mínimo. O Gateway MCP expõe apenas as ferramentas relevantes para a tarefa atual do agente. As tentativas de injeção não conseguem alcançar ferramentas fora do âmbito da tarefa. Para informações sobre como as conexões MCP funcionam, consulte o guia de integrações MCP.
• Filtragem de saída de PII e dados sensíveis. As saídas do Claude Code são verificadas em busca de padrões de dados sensíveis antes de saírem do ambiente de execução. A exfiltração através de canais de saída legítimos é bloqueada.
• Injeção de identidade OAuth 2.0. Cada ação do agente está vinculada às permissões delimitadas de um utilizador autenticado específico. As instruções injetadas não podem escalar além do que o utilizador de origem está autorizado a fazer.
• Registos de auditoria imutáveis com conteúdo completo. Cada solicitação, chamada de ferramenta, leitura de arquivo e saída é registrada com metadados completos. Os registros permanecem no seu ambiente para investigação forense e conformidade. O guia de segurança empresarial abrange a configuração completa de auditoria.
• Controles de saída de rede. Todo o tráfego de saída das sessões do Claude Code é roteado através de políticas de saída controladas. Chamadas externas arbitrárias que injetam instruções são bloqueadas. O Gateway de IA fornece o único ponto de controle para todo o tráfego do modelo.

Organizações que usam TrueFoundry para implantação do Claude Code obtêm defesa em profundidade contra injeção de prompt em múltiplas camadas simultaneamente — filtragem de entrada, escopo de ferramentas, filtragem de saída, controles de identidade e contenção de rede — sem alterações no nível do aplicativo para sessões individuais. A estrutura de governança aborda como construir políticas organizacionais em torno desses controles.

Se sua equipe executa o Claude Code contra conteúdo que não controla totalmente — repositórios, tickets, respostas de API, documentos recuperados — a injeção de prompt é um risco ativo, não uma preocupação futura. TrueFoundry fornece a filtragem em nível de infraestrutura, escopo de ferramentas e contenção de rede que interceptam esses ataques antes que atinjam a execução. Agende uma demonstração para ver como funciona contra padrões reais de injeção.