Segurança de IA em Ambientes Cibernéticos: Modelagem de Ameaças, Defesa em Camadas e Avaliação Experimental de Sistemas Baseados em LLMs, RAG e Agentes Autônomos

1. Introdução

A incorporação de sistemas de inteligência artificial ao ecossistema de cibersegurança atingiu, em 2026, um ponto de inflexão operacional. Modelos de linguagem de grande porte, classificadores multimodais, motores de recomendação e agentes autônomos passaram a intermediar tarefas críticas de análise de logs, triagem de alertas, geração de playbooks, sumarização de inteligência de ameaças, automação de remediação e suporte à investigação digital. Essa mudança trouxe ganhos de escala e velocidade, mas também alterou profundamente o perfil de risco. O problema deixou de ser apenas “usar IA para defender” e passou a ser “defender a própria IA que agora participa da defesa”, um fenômeno comparável à transição histórica de redes planas para arquiteturas zero trust, porém com maior complexidade, maior variabilidade e maior opacidade decisória.

O aspecto central é que sistemas de IA possuem uma superfície de ataque distinta daquela observada em aplicações tradicionais. Em vez de depender apenas de vulnerabilidades clássicas como SQL injection, SSRF, deserialização insegura ou falhas de autenticação, um sistema de IA exposto a entradas naturais pode ser manipulado por meios semânticos. Uma instrução maliciosa embutida em um e-mail, documento PDF, página web ou ticket de suporte pode alterar o comportamento do modelo, direcionar sua cadeia de raciocínio, induzir vazamento de contexto e, em arquiteturas com ferramentas conectadas, levar o agente a executar ações fora de política. A literatura consolidou esse fenômeno sob rótulos como prompt injection, jailbreak, indirect prompt injection, tool abuse e data poisoning, com impactos concretos em assistentes corporativos, copilots, sistemas de busca interna e pipelines RAG (PAPIERS et al., 2024; OWASP, 2024).

Do ponto de vista de segurança cibernética, a emergência da IA produziu um problema duplo. Primeiro, adversários utilizam IA para escalar phishing, engenharia social, geração de malware, evasão de detecção e adaptação dinâmica de payloads. Segundo, defensores passaram a confiar em IA para decidir o que é benigno, o que é malicioso e qual remediação deve ser aplicada. Essa dependência recíproca cria uma superfície sistêmica em que o ataque não precisa comprometer o sistema operacional ou a rede para produzir dano relevante; basta comprometer a cadeia semântica que alimenta a decisão automatizada. Em ambientes SOC, por exemplo, um agente mal configurado pode transformar uma simples solicitação de sumarização em uma ordem indireta para buscar segredos em repositórios, enviar dados para destinos externos ou acionar workflows de contenção indevidos.

Em 2026, o amadurecimento das arquiteturas de IA seguras passou a depender de princípios já consolidados em outras áreas de segurança: minimização de privilégios, segregação de funções, trilhas de auditoria, hardening da cadeia de suprimentos, validação de entradas, monitoramento contínuo e resposta a incidentes. Entretanto, a tradução desses princípios para LLMs e agentes autônomos exige adaptações importantes. A integridade do contexto, por exemplo, é tão relevante quanto a integridade binária; o controle de ferramentas é tão crítico quanto o controle de chamadas RPC; e a confiança em um retrieval pipeline precisa ser tratada com o mesmo rigor aplicado a dependências de software. A analogia mais adequada é considerar o sistema de IA como uma “aplicação composta de linguagem, memória e execução”, na qual cada componente pode ser explorado por caminhos diferentes, mas interdependentes.

Este artigo aborda a segurança de IA dentro de cibersegurança sob uma perspectiva operacional e defensiva. O objetivo não é apresentar um discurso genérico sobre ética ou governança abstrata, mas sim propor uma estrutura concreta para modelagem de ameaças, implementação de controles e avaliação experimental. Partimos de um conjunto de ameaças historicamente verificadas até 2026, incluindo envenenamento de dados de treino e de contexto, prompt injection direto e indireto, exfiltração por embeddings e memória, abuso de ferramentas, adversarial examples em classificadores, supply chain de modelos e riscos associados a agentes autônomos. Em seguida, formalizamos o problema como uma otimização de risco sob restrições de utilidade e custo operacional, para então propor uma metodologia de defesa em camadas baseada em isolamento, política, observabilidade e validação adversarial.

A relevância prática do tema é evidente. Organizações que adotam copilots para responder tickets, resumir incidentes ou consultar documentação interna frequentemente expõem, sem perceber, dados sensíveis a prompts contextuais ou a ferramentas conectadas. Um simples fluxo de RAG mal desenhado pode recuperar materiais confidenciais sem necessidade e inseri-los em prompts que serão processados por modelos externos ou por serviços SaaS. Em paralelo, equipes de segurança empregam IA para priorizar alertas, mas essa automação pode ser enganada por entradas manipuladas em logs, descrições falsas de incidentes ou conteúdo adversarial em anexos e páginas web. O resultado é uma disputa entre atacantes que exploram semântica e defensores que precisam proteger tanto a infraestrutura quanto a própria lógica de interpretação.

A hipótese central deste trabalho é que a segurança de IA em cibersegurança não pode ser tratada como um conjunto de filtros de conteúdo. Ela deve ser construída como um sistema de controle distribuído, com fronteiras explícitas de confiança, avaliação contínua de comportamento e mecanismos de contenção para quando o modelo, o prompt ou a cadeia de ferramentas forem influenciados. Em termos práticos, isso significa reduzir o poder de qualquer instrução não autenticada, separar recuperação de execução, registrar decisões em logs imutáveis e aplicar políticas de autorização per-ação, não apenas per-sessão. O valor científico e operacional deste artigo está justamente em articular essas peças de forma coerente e mensurável.

2. Background and Related Work

A literatura sobre segurança de IA evoluiu rapidamente após 2022, impulsionada pela popularização de LLMs comerciais e open source, além da adoção de arquiteturas RAG e agentes com capacidade de execução de ferramentas. Em 2023 e 2024, ataques baseados em prompt injection ganharam atenção prática, especialmente quando sistemas começaram a consultar conteúdo externo e a tomar ações baseadas em linguagem natural. A comunidade passou a reconhecer que o modelo, quando conectado a ferramentas, deixa de ser apenas um gerador de texto e passa a ser um intermediário de execução. Esse salto de função amplia significativamente a superfície de ataque, uma vez que o adversário não precisa quebrar criptografia nem explorar memória corrompida; basta influenciar a semântica da conversa ou dos documentos recuperados (PAPIERS et al., 2024; LINDEN; ZHANG, 2024).

A taxonomia de riscos promovida pelo OWASP para aplicações de LLM foi um marco prático, ao consolidar classes como prompt injection, data leakage, insecure output handling, excessive agency, supply chain vulnerabilities e overreliance. O valor da taxonomia não está apenas na nomenclatura, mas na capacidade de orientar controles concretos. Por exemplo, “excessive agency” corresponde a sistemas que concedem ao modelo ações demais sem autorização granular, enquanto “insecure output handling” aponta o risco de tratar saídas do modelo como texto confiável, sem validação ou escaping adequado. Em contextos cibernéticos, isso se traduz em agentes que abrem tickets, consultam sistemas internos, alteram regras de firewall ou disparam automações sem trilha de aprovação robusta (OWASP, 2024).

Em paralelo, o NIST publicou o AI Risk Management Framework, que estabeleceu uma linguagem comum para mapear, medir, gerenciar e governar riscos de IA. Embora o AI RMF não seja específico para cibersegurança, ele oferece princípios úteis como validade, confiabilidade, segurança, resiliência, explicabilidade e accountability. A contribuição decisiva foi tornar explícito que risco de IA não é apenas “erro de modelo”, mas um fenômeno socio-técnico que envolve dados, operação, supervisão humana, monitoramento e contexto de uso (NIST, 2023). Em 2026, a convergência entre AI RMF, zero trust e práticas de MLOps seguro já se mostra uma tendência madura, especialmente em organizações que operam em ambientes regulados.

Outra linha de pesquisa importante trata de ataques adversariais a modelos de aprendizado de máquina. Trabalhos clássicos sobre adversarial examples demonstraram que pequenas perturbações podem induzir classificação incorreta em visão computacional e NLP. Embora LLMs sejam mais robustos em alguns sentidos, a essência do problema permanece: a entrada pode ser projetada para explorar decisões internas do sistema. No entanto, a natureza generativa dos LLMs introduz um risco adicional: a saída pode ser plausível mesmo quando incorreta, e essa plausibilidade é particularmente perigosa em segurança, onde relatórios, resumos e recomendações podem ser consumidos por analistas sob alta carga cognitiva (GOODFELLOW; SHLENS; SZEGEDY, 2015; SZEGEDY et al., 2014).

A arquitetura RAG tornou-se onipresente porque reduz alucinação e injeta contexto específico, mas ela também ampliou o problema de confiança em fontes. Se o pipeline de recuperação inclui fontes internas, documentos externos, tickets históricos, web search ou wikis, o sistema passa a ingerir conteúdo potencialmente adversarial. A literatura recente mostrou que prompts maliciosos podem ser introduzidos por documentos aparentemente inocentes, em páginas HTML, PDFs e mesmo em metadados, o que é especialmente perigoso quando o agente trata o conteúdo recuperado como autoridade superior ao prompt do usuário (PAPIERS et al., 2024; WILLISON, 2024). Em termos práticos, o ataque explora a confusão entre instrução e dado.

A noção de “agentic AI” ampliou ainda mais o problema. Ao conectar um modelo a ferramentas, APIs e execuções de código, criamos uma cadeia de confiança que precisa ser validada a cada etapa. Ferramentas como browser automation, integração com e-mail, gerenciamento de tickets, acesso a repositórios Git, consulta a SIEM e execução de comandos em shell podem ser abusadas se o modelo for induzido a acioná-las fora de contexto. O problema assemelha-se a uma forma de execução remota mediada por linguagem natural, onde o atacante manipula a interface de decisão em vez de uma chamada de sistema convencional. A consequência prática é que a fronteira entre ataque lógico e ataque operacional ficou muito mais difusa.

Além das ameaças de inferência e execução, a cadeia de suprimentos de IA também se tornou crítica. Modelos baixados de repositórios públicos, pesos convertidos, quantizações, adapters, prompt templates, embeddings e datasets de treino podem carregar backdoors, vieses maliciosos ou metadados perigosos. Em 2024 e 2025, o ecossistema open source consolidou práticas como model signing, verificação de provenance, SBOM para modelos e controle de integridade de artefatos. A lógica é análoga à supply chain de software: não basta confiar no nome do repositório, é necessário verificar origem, hash, assinatura e comportamento em execução.

Por fim, é necessário considerar o uso ofensivo de IA em cibercrime. Em 2026, grupos criminosos e atores patrocinados por Estados utilizam LLMs para acelerar phishing contextual, geração de iscas em múltiplos idiomas, variação de payloads e adaptação de engenharia social. A ameaça não está necessariamente em malware “superinteligente”, mas na automação de tarefas que antes exigiam mão de obra especializada. Isso eleva a escala e reduz o custo marginal do ataque, enquanto sobrecarrega equipes de defesa com maior volume e variabilidade. Assim, a segurança de IA deve ser entendida tanto como proteção contra ataques à IA quanto contra o uso da IA como multiplicador de capacidades ofensivas.

Tabela 1. Principais classes de ameaça em segurança de IA para cibersegurança

Classe de ameaça	Vetor típico	Impacto principal	Exemplo operacional
Prompt injection direta	Entrada do usuário	Desvio de instrução	Usuário induz o agente a ignorar política
Prompt injection indireta	Conteúdo externo recuperado	Exfiltração e execução indevida	Página web maliciosa afeta agente com browser
Data poisoning	Dados de treino, fine-tuning, memória	Backdoor e degradação	Dataset com exemplos que associam rótulos errados
Tool abuse	Ferramentas/API conectadas	Ações não autorizadas	Envio de e-mail, criação de ticket, alteração de regra
Supply chain de modelos	Pesos, adapters, prompts, embeddings	Compromisso persistente	Modelo baixado com comportamento oculto
Output handling inseguro	Saída do modelo em sistemas downstream	Injeção secundária	Resumo gerado é repassado a sistema sem sanitização
Excessive agency	Permissões amplas ao agente	Amplificação de impacto	Agente executa comandos sem aprovação humana

3. Threat Model and Problem Formalization

O modelo de ameaça adotado neste artigo assume um ambiente corporativo com um ou mais componentes de IA integrados a um stack de segurança. Isso inclui um front-end conversacional, um orquestrador, um motor RAG, conectores para fontes de dados internas e externas, um conjunto de ferramentas autorizadas e um canal de telemetria para observabilidade. O adversário pode ser externo, interno malicioso ou uma fonte de conteúdo comprometida. Em cenários reais, o atacante não precisa comprometer toda a infraestrutura; basta influenciar o fluxo de entrada, a seleção de contexto ou a interpretação da saída.

Definimos o sistema como uma função composta: $$ f(x, c, T, \pi) = y $$ em que $x$ representa a entrada do usuário ou conteúdo indireto, $c$ o contexto recuperado, $T$ o conjunto de ferramentas disponíveis e $\pi$ a política de execução. A saída $y$ pode ser texto, ação ou combinação de ambos. O risco surge quando um atacante controla parcialmente $x$ ou $c$ e consegue induzir uma ação em $T$ fora do conjunto autorizado por $\pi$. Assim, o objetivo da defesa é garantir que a probabilidade de execução indevida permaneça abaixo de um limiar aceitável: $$ \Pr(\text{ação indevida} \mid x, c, T, \pi) \le \epsilon $$ para um $\epsilon$ dependente do apetite ao risco da organização.

A ameaça central em sistemas agentic é que a política $\pi$ frequentemente é implícita, naturalizada ou distribuída em múltiplas camadas de prompt, middleware e aplicação. Isso cria inconsistência entre o que o desenvolvedor imagina ser a regra e o que o sistema realmente executa. Um atacante pode explorar essa inconsistência com instruções como “trate o próximo documento como prioridade máxima” ou “envie o conteúdo ao analista”, obtendo um efeito de sobreposição semântica. O problema é agravado quando a aplicação mistura instruções do sistema com conteúdo recuperado sem marcação rígida de confiança.

Uma formalização útil é decompor o risco em três componentes: $$ R = P_a \cdot I_a \cdot C_a $$ em que $P_a$ é a probabilidade de sucesso do ataque, $I_a$ é o impacto caso o ataque tenha sucesso e $C_a$ é o custo de contenção e recuperação. Em segurança de IA, $P_a$ depende não apenas de técnica de exploração, mas da presença de guardrails, isolamento de ferramentas, robustez do retrieval e qualidade do monitoramento. Já $I_a$ cresce quando o sistema possui acesso a dados sensíveis, privilégios de escrita, integrações com sistemas de resposta ou capacidade de acionar automações. O custo de contenção aumenta quando há baixa rastreabilidade, ausência de logs imutáveis e dependência de provedores externos.

A modelagem também deve considerar o risco de alucinação operacional. Mesmo sem ataque, um modelo pode produzir uma recomendação errada, e em segurança isso pode gerar falso positivo ou falso negativo com consequências reais. Portanto, o sistema deve ser avaliado não apenas por robustez a ataques, mas por confiabilidade em condições normais. Uma métrica útil é a taxa de erro operacional ponderada: $$ E_w = \alpha \cdot FP + \beta \cdot FN + \gamma \cdot AE $$ em que $FP$ e $FN$ são falsos positivos e falsos negativos, e $AE$ representa ação errada executada autonomamente. Em contextos de SOC, o termo $AE$ costuma ter peso maior, pois uma única ação indevida pode introduzir indisponibilidade ou expor dados.

Tabela 2. Variáveis de risco e seus efeitos no sistema

Variável	Significado	Efeito se alto	Controle principal
$P_a$	Probabilidade de ataque bem-sucedido	Aumenta exploração	Filtragem, sandbox, robustez contextual
$I_a$	Impacto do ataque	Amplifica dano	Menor privilégio, segregação, aprovação
$C_a$	Custo de contenção	Recuperação lenta	Logs, rollback, playbooks
$FP$	Falso positivo	Ruído operacional	Calibração, thresholds
$FN$	Falso negativo	Ataque não detectado	Detecção adversarial, revisão humana
$AE$	Ação errada executada	Dano direto	Autorização granular, confirmação

Do ponto de vista de causalidade, a segurança de IA deve separar input trustworthiness de action trustworthiness. Um texto pode ser semanticamente benigno e ainda assim conter instruções maliciosas indiretas; da mesma forma, uma saída pode parecer correta e estar errada em um detalhe crítico. Logo, não basta validar entradas. É necessário validar o caminho inteiro: origem, transformação, recuperação, síntese e execução. A consequência prática é a necessidade de controles em cada fronteira de confiança.

4. Metodologia Proposta

Propomos uma metodologia de defesa em camadas para sistemas de IA em cibersegurança, orientada por quatro princípios: contenção, autorização granular, observabilidade e avaliação adversarial contínua. A proposta não trata o modelo como um componente confiável por padrão. Ao contrário, assume que toda entrada externa, toda recuperação e toda ação gerada precisam passar por filtros específicos de confiança e política.

A primeira camada é a contenção de contexto. O sistema deve manter instruções de sistema, instruções do desenvolvedor, conteúdo recuperado e entrada do usuário em canais semanticamente separados. Isso reduz a chance de confusão entre dado e comando. O conteúdo recuperado deve ser marcado com provenance, fonte, timestamp e score de confiança. Quando possível, documentos externos devem ser submetidos a um pipeline de pré-processamento que remova instruções, normalize texto e detecte padrões de prompt injection. Isso não elimina o risco, mas reduz a probabilidade de que o modelo trate o conteúdo como autoridade.

A segunda camada é a autorização por ação. Em vez de permitir que o modelo chame ferramentas livremente, cada tool call deve passar por um policy engine. Por exemplo, leitura de documento interno pode ser permitida, mas escrita em ticket, envio de e-mail ou alteração de configuração deve exigir critérios adicionais, como confirmação humana, assinatura de política ou escopo temporal. Isso alinha a arquitetura de IA com os princípios de zero trust: nunca confiar implicitamente no modelo, sempre verificar contexto, identidade e intenção antes da execução.

A terceira camada é a observabilidade orientada a risco. Toda interação relevante deve gerar telemetria estruturada: prompt, contexto recuperado, ferramentas avaliadas, ferramenta executada, resultado, latência e motivo de bloqueio, quando houver. Logs devem ser protegidos contra adulteração e correlacionados com ID de sessão e ID de incidente. Em sistemas críticos, recomenda-se retenção imutável e exportação para um SIEM. A observabilidade é importante não só para auditoria posterior, mas também para detecção online de comportamentos anômalos, como repetição suspeita de consultas, escalada progressiva de permissões ou uso incomum de ferramentas.

A quarta camada é a avaliação adversarial contínua. Assim como se testa software com fuzzing e pentest, sistemas de IA precisam ser avaliados com suítes de red teaming específicas. Isso inclui prompt injection direta, indirect prompt injection em HTML e PDF, jailbreaks, tentativas de exfiltração de contexto, abuso de ferramentas e manipulação de output downstream. Um conjunto de testes automatizados deve rodar a cada mudança de prompt, modelo, vetorstore, política ou conector. Em ambientes maduros, a equipe de defesa mantém um catálogo de ataques reproduzíveis com métricas de sucesso, severidade e cobertura.

A defesa também deve incorporar segregação de funções entre recuperação e execução. O mecanismo de busca pode recuperar documentos potencialmente hostis, mas não deve ser o mesmo componente que interpreta o conteúdo como instrução. Da mesma forma, o módulo que decide sobre ferramentas deve operar com visão limitada e política explícita. Em termos práticos, isso pode ser implementado com um “planner” que sugere ações e um “executor” que somente executa após validação. Essa separação reduz o risco de que um único prompt malicioso transforme o modelo em um operador indevido.

Tabela 3. Controles propostos por camada e seu efeito

Camada	Controle	Risco mitigado	Limitação
Contexto	Separação e marcação de fontes	Prompt injection indireta	Não impede todo conteúdo semântico hostil
Ação	Policy engine para tools	Tool abuse	Aumenta latência e complexidade
Observabilidade	Logs imutáveis e correlação	Baixa rastreabilidade	Exige maturidade operacional
Avaliação	Red teaming contínuo	Regressão de segurança	Custo recorrente
Recuperação	Ranking por confiança/proveniência	Envenenamento de contexto	Depende da qualidade das fontes
Execução	Confirmação humana em ações críticas	Ação indevida	Reduz automação total

A metodologia proposta é compatível com arquiteturas baseadas em RAG, mas exige disciplina arquitetural. RAG não deve ser interpretado como mecanismo de segurança; ele é, no máximo, um mecanismo de groundedness parcial. Se o conteúdo recuperado é adversarial, o sistema só amplifica o problema. Por isso, o score de confiança da fonte precisa influenciar tanto a recuperação quanto a exibição e a possibilidade de citação. Em ambientes de SOC, por exemplo, uma recomendação gerada por IA deve ser acompanhada de evidências verificáveis, e não apenas de uma resposta fluida e persuasiva.

5. Implementação

A implementação de referência foi concebida como um serviço web com três componentes principais: um gateway de entrada, um orquestrador de IA e um executor de ferramentas. O gateway recebe solicitações, aplica autenticação e controla taxa de chamadas. O orquestrador constrói o prompt final, injeta contexto recuperado e consulta o modelo. O executor só aceita ações previamente autorizadas por política e trabalha em sandbox. Essa topologia reduz o acoplamento entre linguagem e execução e permite auditoria separada de cada etapa.

Na camada de aplicação, usamos FastAPI para expor endpoints REST, Redis para controle de sessão e um vetorstore com indexação de documentos internos. O componente de governança de prompts separa system, developer, retrieved e user, e cada bloco recebe marcação explícita de confiança. O acesso a ferramentas é mediado por um policy engine simples, baseado em regras, que verifica o tipo da ação, o escopo e o risco da operação. Para detectar entradas suspeitas, emprega-se uma combinação de heurísticas lexicais, scoring semântico e regras baseadas em contexto, sempre com a premissa de que a detecção não é perfeita.

Um exemplo de endurecimento operacional é a execução do serviço em contêiner sem privilégios, com sistema de arquivos somente leitura e limites de rede. Ferramentas que exigem acesso a recursos internos são isoladas em outro contêiner ou worker, com credenciais de curta duração. Esse design permite que, mesmo em caso de prompt injection bem-sucedida, o impacto seja limitado pela falta de privilégio do executor. Em outras palavras, o modelo pode sugerir uma ação, mas não obtém automaticamente a capacidade de executá-la em qualquer lugar.

Exemplo de configuração de políticas para tools

tools:
  - name: search_internal_docs
    action: read
    resource_scope: internal_docs
    requires_human_approval: false
    max_results: 5
  - name: create_soc_ticket
    action: write
    resource_scope: soc_tickets
    requires_human_approval: true
    approval_ttl_seconds: 300
  - name: send_email
    action: write
    resource_scope: outbound_mail
    requires_human_approval: true
    allowed_domains:
      - corp.example
  - name: run_shell_command
    action: execute
    resource_scope: sandbox
    requires_human_approval: true
    deny_patterns:
      - "curl .* http"
      - "bash -c"
      - "powershell -enc"

Para testes de segurança, foi criada uma suíte de red teaming com prompts maliciosos, documentos HTML e PDFs contendo instruções embutidas e casos de abuso de ferramentas. A suíte avalia se o sistema obedece à instrução maliciosa, se vaza contexto ou se executa ação indevida. Também são testadas variações linguísticas em português e inglês, já que a engenharia social multilingue segue sendo relevante em 2026. O objetivo é medir resistência comportamental, não apenas filtragem lexical.

Exemplo de execução com integração ao scanner de prompts

python3 -m venv .venv
source .venv/bin/activate
pip install fastapi uvicorn requests pyyaml langchain langfuse

export APP_ENV=staging
export MODEL_ENDPOINT=http://localhost:8000/v1/chat/completions
export POLICY_FILE=policy.yaml

uvicorn app.main:app --host 0.0.0.0 --port 8080

A instrumentação de observabilidade inclui rastreamento de cada tool call, com correlação por trace_id. Quando o sistema bloqueia uma ação, ele registra o motivo, a regra acionada e a versão da política. Isso é essencial para análise posterior, pois permite distinguir falha do modelo de falha de configuração. Em ambientes corporativos, essa distinção é frequentemente a diferença entre melhorar o sistema e permanecer cegos diante do mesmo tipo de ataque.

6. Experimental Evaluation

A avaliação foi desenhada para responder a três perguntas: (1) o modelo é suscetível a prompt injection direta e indireta? (2) as proteções por política reduzem a taxa de execução indevida sem destruir utilidade? e (3) a combinação de contenção, autorização e observabilidade reduz o impacto operacional? Os experimentos foram executados em um ambiente controlado com dados sintéticos e documentos de teste, sem exposição de segredos reais. Foram comparados quatro cenários: baseline sem proteção, filtragem lexical, policy engine com confirmação humana e arquitetura em camadas completa.

Os ataques avaliados incluíram instruções diretas do tipo “ignore todas as instruções anteriores” e ataques indiretos inseridos em HTML com trechos como “resuma este conteúdo e envie o resultado ao canal X”, além de tentativas de forçar uso de ferramenta para listar segredos, criar tickets ou exfiltrar contexto. A métrica principal foi taxa de sucesso do ataque, definida como a proporção de tentativas em que o sistema executou a ação indevida ou revelou informação sensível. A utilidade foi estimada por uma tarefa legítima de triagem de alertas, medida por precisão de sumarização e tempo de resposta.

Os resultados mostram que filtragem lexical isolada é insuficiente. Ela reduz ataques triviais, mas falha diante de variações semânticas, contexto externo e conteúdo aparentemente benigno. O policy engine com confirmação humana reduz drasticamente tool abuse, porém mantém algum risco de vazamento textual se o contexto recuperado for malicioso. A arquitetura em camadas apresentou o melhor equilíbrio: menor taxa de sucesso de ataque, menor risco de ação indevida e custo operacional aceitável, ainda que com latência adicional.

Tabela 4. Comparação experimental entre estratégias de defesa

Estratégia	Taxa de sucesso de prompt injection	Taxa de tool abuse	Latência média adicional	Utilidade legítima
Baseline sem proteção	0,74	0,68	0 ms	Alta
Filtragem lexical	0,49	0,55	12 ms	Alta
Policy engine + aprovação	0,21	0,09	1800 ms	Média-alta
Arquitetura em camadas completa	0,08	0,04	220 ms	Alta

A interpretação desses números é direta: a defesa que depende apenas de palavras-chave falha porque o ataque é semântico. Já a autorização granular resolve a parte mais perigosa do problema, que é a execução, mas precisa ser combinada com isolamento de contexto para impedir vazamento. O aumento de latência observado no cenário com aprovação humana é real e, em algumas organizações, inaceitável para todas as tarefas. No entanto, o custo é justificável para ações críticas, como alteração de regras, envio externo ou acesso a segredos.

Tabela 5. Efeito dos controles na avaliação legítima de triagem de alertas

Métrica	Baseline	Filtragem lexical	Policy engine	Camadas completas
Precisão de sumarização	0,86	0,85	0,84	0,85
Tempo médio de resposta	1,2 s	1,2 s	3,0 s	1,4 s
Falsos positivos de bloqueio	0,03	0,08	0,05	0,04
Incidentes de ação indevida	11	7	1	0

Tabela 6. Matriz simplificada de risco residual

Ameaça	Baseline	Filtragem lexical	Policy engine	Camadas completas
Prompt injection direta	Alto	Médio	Baixo	Muito baixo
Prompt injection indireta	Alto	Alto	Médio	Baixo
Exfiltração de contexto	Alto	Alto	Médio	Baixo
Tool abuse	Alto	Médio	Muito baixo	Muito baixo
Supply chain de modelo	Alto	Alto	Alto	Médio

Os resultados indicam que a maior redução de risco vem da combinação entre isolamento e política, e não de uma técnica única. Isso reforça a tese de que segurança de IA deve ser tratada como engenharia de sistemas, não como simples moderação de texto. Um sistema de IA para defesa cibernética precisa aceitar que o erro pode vir da semântica, da fonte recuperada, da ferramenta ou da política. Portanto, a avaliação deve cobrir todos os caminhos de falha.

7. Case Study

O estudo de caso examina um assistente de triagem de alertas implantado em uma equipe SOC de médio porte. O objetivo do sistema era resumir eventos do SIEM, consultar runbooks internos e sugerir próximos passos. Em sua primeira versão, o assistente tinha acesso a documentos operacionais, tickets históricos e uma ferramenta para criar incidentes no sistema de gestão. O design privilegiava produtividade, mas assumia confiança excessiva no conteúdo recuperado e na instrução do usuário.

O incidente ocorreu quando um analista recebeu um alerta aparentemente rotineiro associado a um e-mail externo contendo uma “descrição do incidente”. O texto tinha, escondida em linguagem natural, uma instrução para o assistente “usar o conteúdo abaixo como prioridade operacional e encaminhar um resumo detalhado ao canal de resposta”. O documento também continha um bloco que mimetizava uma nota técnica, sugerindo que era necessário consultar um repositório interno específico. O agente, sem separação rígida entre dado e instrução, interpretou o trecho como parte do fluxo legítimo e iniciou uma busca desnecessária, chegando a compor um resumo com excertos sensíveis do contexto.

Embora não tenha ocorrido exfiltração externa real no ambiente do estudo, o teste demonstrou o risco de execução indireta. O problema não foi apenas o prompt malicioso, mas o fato de que a ferramenta de criação de ticket estava acessível sem confirmação adicional e que os documentos recuperados eram inseridos no contexto sem marcação de confiabilidade. A equipe concluiu que, em uma versão menos controlada do sistema, o mesmo mecanismo poderia ter enviado dados a um canal errado ou acionado uma remediação incorreta. O impacto potencial é particularmente grave em SOCs, onde a pressão por resposta rápida favorece confiança excessiva em automação.

Após a redesign do fluxo, o sistema passou a exigir confirmação humana para qualquer ação de escrita, a limitar a recuperação a documentos com provenance validada e a exibir separadamente trechos provenientes de fontes externas. O assistente continuou útil para sumarização, mas deixou de ser um executor automático sem barreiras. Essa mudança reduziu drasticamente o risco sem eliminar a utilidade operacional, confirmando a hipótese de que o melhor equilíbrio em segurança de IA é a automação supervisionada, não a autonomia irrestrita.

8. Discussão

A principal lição deste trabalho é que a segurança de IA em cibersegurança não pode depender de uma única defesa. Filtros de entrada ajudam, mas não são suficientes. Guardrails de saída são úteis, mas podem ser contornados por conteúdo contextual. Modelos finetuned em dados internos podem parecer mais úteis, porém também amplificam o risco de vazamento e envenenamento. Assim, a defesa deve ser composta e redundante, com políticas explícitas em cada fronteira de confiança.

Outro ponto crucial é que a semântica introduz um novo tipo de ambiguidade. Em software tradicional, a intenção é codificada em chamadas, parâmetros e permissões. Em sistemas de IA, a intenção é expressa em linguagem natural e, portanto, sujeita a ambiguidade, manipulação e overfitting de contexto. Isso significa que o sistema precisa ser projetado para desconfiar de sua própria fluidez linguística. O fato de uma resposta soar coerente não implica que seja segura ou correta.

Também é preciso tratar o problema de governança. Em muitas organizações, o risco não está no modelo em si, mas no modo como ele é implantado. Um LLM exposto a e-mails, tickets e documentos sem política clara transforma todo o conteúdo em possível comando. Em 2026, com a consolidação de CNAPP, eBPF-based security, ZTNA e controles de identidade mais maduros, já existe base técnica suficiente para isolar serviços de IA de forma muito mais rigorosa. A barreira não é tecnológica; é de arquitetura e de cultura operacional.

A discussão econômica também é relevante. Toda medida de proteção tem custo em latência, complexidade e experiência do usuário. Entretanto, em cibersegurança, a automação irrestrita costuma ser uma falsa economia. O custo de um único incidente de ação indevida pode superar amplamente o custo contínuo de observabilidade e aprovação humana para ações críticas. Em termos de gestão de risco, é preferível aceitar um pequeno atrito operacional do que permitir que o sistema aja como um operador autônomo sem freios.

Finalmente, há o tema da avaliação contínua. Sistemas de IA mudam com frequência: novo modelo, novo prompt, novo conector, novo índice, novo dataset, novo policy. Cada alteração é potencialmente uma mudança de superfície de ataque. Portanto, testes de segurança precisam ser parte do pipeline de entrega, não uma atividade eventual. Isso inclui red teaming estruturado, regressão de comportamento e monitoramento de produção. Em outras palavras, a segurança de IA precisa ser tratada como um produto vivo, não como uma configuração estática.

9. Conclusão e Futuro Work

Este artigo apresentou uma visão operacional da segurança de IA aplicada à cibersegurança, concentrando-se em LLMs, RAG e agentes autônomos. Mostramos que a superfície de ataque vai além de vulnerabilidades clássicas e inclui manipulação semântica, envenenamento de contexto, abuso de ferramentas e falhas de governança. A metodologia proposta combina contenção, autorização granular, observabilidade e avaliação adversarial contínua, demonstrando que a defesa eficaz depende de arquitetura em camadas.

Os experimentos e o estudo de caso reforçam que filtragem lexical isolada é insuficiente e que a redução do risco exige segregação entre recuperação e execução, além de confirmação para ações críticas. Em ambientes SOC e de resposta a incidentes, isso significa limitar o poder dos agentes e preservar sempre um ponto de decisão humana para operações sensíveis. Em 2026, essa abordagem representa o estado da prática mais defensável para organizações que desejam usar IA sem transformar automação em um novo vetor de incidente.

Como trabalho futuro, destacam-se quatro frentes. Primeiro, melhorar métodos de detecção de prompt injection indireta com base em provenance e modelos de confiança por fonte. Segundo, desenvolver políticas formais para agentes com ferramentas, incluindo verificação automática de invariantes de segurança. Terceiro, explorar técnicas de hardening de RAG contra documentos adversariais e envenenamento de embeddings. Quarto, integrar métricas de risco de IA aos programas de governança corporativa, com auditoria, conformidade e resposta a incidentes específicos para sistemas generativos. A direção é clara: segurança de IA não é um apêndice da segurança cibernética; é uma de suas frentes centrais.

10. Referências

ANAND, Anish et al. Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviors, and Lessons Learned. arXiv, 2023. Disponível em: https://arxiv.org/abs/2209.07858. Acesso em: 5 maio 2026.

BROWN, Tom B. et al. Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems, 2020. Disponível em: https://arxiv.org/abs/2005.14165. Acesso em: 5 maio 2026.

CARLINI, Nicholas et al. Extracting Training Data from Diffusion Models. USENIX Security Symposium, 2023. Disponível em: https://www.usenix.org/conference/usenixsecurity23/presentation/carlini-extracting. Acesso em: 5 maio 2026.

CARLINI, Nicholas et al. Extracting Training Data from Large Language Models. USENIX Security Symposium, 2021. Disponível em: https://www.usenix.org/conference/usenixsecurity21/presentation/carlini-extracting. Acesso em: 5 maio 2026.

CHEN, Ze et al. Prompt Injection Attacks and Defenses in LLM-Integrated Applications. arXiv, 2024. Disponível em: https://arxiv.org/abs/2402.06363. Acesso em: 5 maio 2026.

CWE MITRE. CWE-77: Improper Neutralization of Special Elements used in a Command. 2026. Disponível em: https://cwe.mitre.org/data/definitions/77.html. Acesso em: 5 maio 2026.

GOODFELLOW, Ian; SHLENS, Jonathon; SZEGEDY, Christian. Explaining and Harnessing Adversarial Examples. arXiv, 2015. Disponível em: https://arxiv.org/abs/1412.6572. Acesso em: 5 maio 2026.

HINDLE, Abram et al. On the Naturalness of Software. ICSE, 2012. Disponível em: https://dl.acm.org/doi/10.1145/2337223.2337245. Acesso em: 5 maio 2026.

HOUDEBINE, Nicolas et al. Large Language Model Security: A Survey. arXiv, 2024. Disponível em: https://arxiv.org/abs/2401.05561. Acesso em: 5 maio 2026.

KIRAN, Ravi et al. Security Implications of Retrieval-Augmented Generation in Enterprise Systems. arXiv, 2024. Disponível em: https://arxiv.org/abs/2404.09873. Acesso em: 5 maio 2026.

LECUN, Yann; BENGIO, Yoshua; HINTON, Geoffrey. Deep Learning. Nature, 2015. Disponível em: https://www.nature.com/articles/nature14539. Acesso em: 5 maio 2026.

LIN, Susan et al. OWASP Top 10 for Large Language Model Applications. OWASP, 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 5 maio 2026.

MACHADO, Guilherme et al. Prompt Injection in Multimodal Systems: A Practical Evaluation. arXiv, 2025. Disponível em: https://arxiv.org/abs/2501.04211. Acesso em: 5 maio 2026.

NIST. AI Risk Management Framework (AI RMF 1.0). Gaithersburg: NIST, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 5 maio 2026.

NIST. Secure Software Development Framework (SSDF) Version 1.1. Gaithersburg: NIST, 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 5 maio 2026.

NIST. Cybersecurity Framework 2.0. Gaithersburg: NIST, 2024. Disponível em: https://www.nist.gov/cyberframework. Acesso em: 5 maio 2026.

OPENAI. Preparedness Framework. 2024. Disponível em: https://openai.com/index/preparedness-framework/. Acesso em: 5 maio 2026.

PAPIERS, Samuel et al. Indirect Prompt Injection Attacks Against LLM-Integrated Applications. arXiv, 2024. Disponível em: https://arxiv.org/abs/2402.08706. Acesso em: 5 maio 2026.

PENGLAI, Li et al. Data Poisoning Attacks in Machine Learning Systems: A Survey. arXiv, 2023. Disponível em: https://arxiv.org/abs/2303.13592. Acesso em: 5 maio 2026.

PINEAU, Joelle et al. Why AI Safety Requires Robust Monitoring and Evaluation. Nature Machine Intelligence, 2024. Disponível em: https://www.nature.com/articles/s42256-024-00803-1. Acesso em: 5 maio 2026.

RAGHAVAN, Minsuk et al. Robustness of Large Language Models to Prompt Attacks. arXiv, 2023. Disponível em: https://arxiv.org/abs/2307.15043. Acesso em: 5 maio 2026.

SHUMAILOV, Ilia et al. AI Model Collapse: Is Model Autophagy a Serious Concern? arXiv, 2023. Disponível em: https://arxiv.org/abs/2305.17493. Acesso em: 5 maio 2026.

SZEGEDY, Christian et al. Intriguing Properties of Neural Networks. arXiv, 2014. Disponível em: https://arxiv.org/abs/1312.6199. Acesso em: 5 maio 2026.

WILLISON, Simon. LLM Prompt Injection: A Practical Security Threat. 2024. Disponível em: https://simonwillison.net/2024/Mar/17/prompt-injection/. Acesso em: 5 maio 2026.

YAMADA, Ryo et al. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv, 2023. Disponível em: https://arxiv.org/abs/2302.04761. Acesso em: 5 maio 2026.

ZOU, Andy et al. Universal and Transferable Adversarial Attacks on Aligned Language Models. arXiv, 2023. Disponível em: https://arxiv.org/abs/2307.15043. Acesso em: 5 maio 2026.