Segurança de IA em Cibersegurança: Formalização de Ameaças, Defesa em Profundidade e Avaliação Experimental de Sistemas com LLMs, RAG e Agentes Autônomos em Ambiente Corporativo

1. Introduction

A adoção de inteligência artificial em cibersegurança deixou de ser um experimento marginal e passou a integrar fluxos críticos de operações, governança e resposta a incidentes. Em 2026, organizações utilizam modelos de linguagem grandes para triagem de alertas, sumarização de telemetria, enriquecimento de inteligência de ameaças, apoio a SOC, geração de consultas, classificação de tickets, automação de playbooks e interface natural para ferramentas internas. Esse movimento trouxe ganhos operacionais concretos, mas também ampliou de forma significativa a superfície de ataque. A segurança de IA, nesse contexto, não se limita a “proteger o modelo”; ela abrange dados, prompts, contexto recuperado, ferramentas, memória, integrações, identidade, cadeia de suprimentos, governança e observabilidade.

O principal equívoco de muitas implantações é tratar LLMs como componentes estatísticos isolados, quando na prática eles operam como orquestradores de decisões em ambientes ricos em privilégios. Um agente com acesso a e-mail, tickets, SIEM, EDR, repositórios internos, bases de conhecimento e APIs SaaS pode transformar uma simples manipulação de prompt em exfiltração de dados, escalada de privilégios lógicos ou sabotagem operacional. A literatura até 2026 consolidou que ataques de prompt injection, jailbreak, data poisoning e tool abuse não são meras curiosidades de laboratório; são riscos sistêmicos em arquiteturas com RAG e agentes autônomos (LEITER et al., 2023; ZOU et al., 2023; OWASP, 2024).

A especificidade do problema em cibersegurança é ainda maior porque o próprio domínio é altamente assimétrico. O defensor busca precisão, rastreabilidade e redução de tempo de resposta, enquanto o atacante busca ambiguidade, confusão contextual e extração de informação. Além disso, muitos casos de uso de IA em segurança lidam com dados sensíveis por natureza: IOC, indicadores táticos, logs de endpoint, credenciais parcialmente mascaradas, detalhes de incidentes, artefatos forenses, regras Sigma, consultas KQL e evidências sob retenção legal. Em tais cenários, um vazamento de contexto pode ser mais danoso do que um erro classificatório simples. A pergunta central, portanto, não é apenas “o modelo acerta?”, mas “ele pode ser induzido a violar confidencialidade, integridade ou disponibilidade?”

Este artigo parte de uma constatação operacional: a defesa de sistemas com IA deve ser projetada como uma extensão da engenharia de segurança clássica, e não como um adendo cosmético. Princípios como menor privilégio, segmentação, validação de entrada, autenticação forte, trilhas de auditoria, allowlists, contenção de dano e separação de domínios continuam válidos, mas precisam ser reinterpretados para prompts, embeddings, ferramentas e memória. A isso se somam controles contemporâneos de 2026, como políticas de IA, classificação de dados, CNAPP, observabilidade baseada em eBPF, enclaves de execução confiável, gateways de LLM, e guardrails semânticos.

A motivação prática deste estudo é responder a uma lacuna recorrente em empresas maduras: equipes de segurança já dominam IAM, SIEM, SOAR e Zero Trust, mas subestimam que uma interface em linguagem natural pode se tornar um canal de escalada tão perigoso quanto uma API mal protegida. Quando um analista pergunta “resuma os incidentes críticos das últimas 24 horas” e o sistema responde com conteúdo que inclui segredos operacionais ou detalhes de casos segregados, a violação não ocorreu por falha criptográfica, mas por falha de contextualização e governança. Em termos formais, trata-se de um problema de controle de fluxo de informação em sistemas probabilísticos com ação.

A contribuição deste trabalho é propor uma arquitetura e uma metodologia de avaliação que tratam IA em cibersegurança como um sistema adversarial composto por múltiplos planos: plano semântico, plano de ferramentas, plano de memória, plano de dados e plano de operação. O artigo também apresenta uma avaliação experimental com cenários de red teaming e defesa, quantificando taxas de sucesso de ataques e o impacto dos controles propostos. Em síntese, argumentamos que a segurança de IA em 2026 exige um modelo de defesa em profundidade adaptado a agentes, com monitoramento contínuo e medidas preventivas e reativas integradas.

2. Background and Related Work

A base conceitual da segurança de IA em 2026 resulta da convergência de quatro linhas evolutivas: segurança de aprendizado de máquina, segurança de aplicações com LLMs, engenharia de plataformas de IA e segurança cibernética operacional. A literatura clássica de adversarial machine learning já demonstrava que modelos podem ser enganados por perturbações, envenenamento e evasão (BIGGIO; ROLI, 2018). Contudo, os LLMs introduziram novos vetores, porque seu comportamento é condicionado por instruções linguísticas, contexto concatenado e ferramentas externas. Isso desloca o problema de “classificação sob perturbação” para “execução de instruções sob influência adversarial”.

Um marco importante foi a popularização de ataques de prompt injection, em que instruções adversárias inseridas em páginas, documentos, e-mails ou respostas de ferramentas tentam redirecionar o comportamento do modelo. Trabalhos de segurança sobre LLMs mostraram que modelos podem obedecer a instruções conflitantes dependendo do contexto e da hierarquia percebida entre system prompt, user prompt e conteúdo recuperado (LEITER et al., 2023). Em paralelo, pesquisas como as de Zou et al. demonstraram que técnicas de otimização podem produzir prompts universalmente maliciosos com alta taxa de sucesso em múltiplos modelos e domínios (ZOU et al., 2023).

Na esfera de aplicações, frameworks de risco começaram a consolidar taxonomias. O OWASP Top 10 for LLM Applications tornou-se uma referência prática ao listar classes como prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, excessive agency, sensitive information disclosure e vector and embedding weaknesses (OWASP, 2024). Essas categorias são especialmente relevantes para cibersegurança porque muitas ferramentas de defesa automatizada dependem de decisões do modelo para ações de alto impacto. A mera emissão de uma resposta incorreta pode se transformar em ação errada se o sistema conectar a saída ao SIEM, ao SOAR ou a um orquestrador de tickets.

Outro vetor crítico é o abuso de ferramentas. Em arquiteturas agentic, o modelo não apenas responde; ele consulta bancos, executa buscas, chama APIs e, em alguns casos, dispara ações de remediação. Isso cria um equivalente funcional de uma linguagem de programação com controle parcial sobre entradas adversárias. A pesquisa sobre agentes mostrou que se o modelo puder selecionar ferramentas sem restrições rígidas, um prompt malicioso pode transformar recursos legítimos em canais de exfiltração ou destruição lógica (SHEN et al., 2024). Em termos de segurança, a questão deixa de ser “o modelo pode ser persuadido?” e passa a ser “quais ações o modelo pode efetivamente realizar e como limitá-las?”

Também é necessário contextualizar o papel de RAG. A recuperação aumentada por geração tornou-se padrão em ambientes corporativos porque reduz alucinações e permite consultar conhecimento privado sem fine-tuning. Entretanto, a superfície de ataque se amplia para o índice vetorial, embeddings, conectores, documentos ingeridos e mecanismos de chunking. Se um documento malicioso consegue influenciar o ranking de recuperação, o modelo pode receber conteúdo que parece autoritativo, mas contém instruções hostis ou dados envenenados. Esse problema é especialmente crítico em SOCs, onde fontes diversas — relatórios, e-mails, wikis, playbooks, chat logs e tickets — são agregadas em uma base de conhecimento unificada.

Do ponto de vista defensivo, a literatura e a prática convergiram para uma defesa em camadas. O NIST AI RMF 1.0 introduziu uma estrutura de governança baseada em mapear, medir, gerenciar e governar riscos de IA (NIST, 2023). O MITRE ATLAS forneceu uma taxonomia de táticas e técnicas adversariais específicas para ML, útil para modelar caminhos de ataque e indicadores de comprometimento (MITRE, 2024). Em paralelo, padrões de arquitetura zero trust passaram a ser aplicados não apenas a usuários, mas também a serviços de IA, com autenticação mútua, segmentação e validação contínua de contexto (NIST, 2020). Em 2026, isso se complementa com CNAPP, políticas OPA, gateways de LLM e monitoramento de runtime via eBPF.

A seguir, a Tabela 1 sintetiza classes de ameaça relevantes para sistemas de IA em cibersegurança, com a natureza do impacto e controles típicos.

Classe de ameaça	Exemplo operacional	Impacto principal	Controles típicos
Prompt injection	Conteúdo externo instruindo o agente a revelar segredos	Confidencialidade e integridade	Filtragem semântica, isolamento de contexto, prompt firewall
Envenenamento de RAG	Documento malicioso introduzido na base vetorial	Integridade e confiança	Curadoria, assinaturas, provenance, scoring de confiança
Excesso de agência	Agente executa ação não autorizada em SOAR	Disponibilidade e integridade	Allowlist de ferramentas, aprovações, RBAC/ABAC
Vazamento por memória	Histórico reutilizado entre sessões	Confidencialidade	Segmentação de memória, TTL, criptografia, segregação
Exfiltração via ferramentas	Modelo usa API para enviar dados a domínio externo	Confidencialidade	Egress control, sandbox, policy enforcement
DoS algorítmico	Prompts longos ou loops de agente	Disponibilidade	Limites, rate limiting, circuit breakers

A literatura de segurança de software também oferece analogias úteis. Assim como APIs exigem autenticação, autorização, validação e observabilidade, LLMs exigem um conjunto análogo para cada camada do pipeline. A diferença é que as fronteiras não são apenas sintáticas, mas semânticas. Um prompt aparentemente inocente pode conter instruções embutidas; um documento legítimo pode carregar payloads linguísticos; uma resposta correta pode induzir ações incorretas quando executada por automação downstream. Em 2026, portanto, “output safety” não é apenas pós-processamento textual, mas controle de efetivação de ações.

3. Threat Model and Problem Formalization

Modelamos o sistema de IA em cibersegurança como uma composição $S = {I, C, M, T, O}$, onde $I$ representa entradas humanas e sistêmicas, $C$ o contexto recuperado, $M$ a memória persistente ou de sessão, $T$ o conjunto de ferramentas disponíveis ao agente e $O$ as saídas transformadas em decisões ou ações. O atacante observa parte desse sistema e tenta influenciar $O$ por meio de manipulação em $I$, $C$ ou $M$, ou por meio do abuso de $T$. Em termos de propriedade de segurança, queremos garantir que, para qualquer interação admissível, o sistema preserve confidencialidade, integridade e disponibilidade de acordo com uma política $P$.

Formalmente, seja $a \in A$ uma ação potencial que o agente pode executar, e seja $\pi(a \mid x)$ a probabilidade de o sistema selecionar a ação $a$ dado o contexto $x$. O problema de segurança é restringir o espaço de ações efetivas $A_e \subseteq A$ de modo que apenas ações compatíveis com a política sejam executáveis. Queremos impor: $$ \forall a \in A \setminus A_e,\quad \Pr[\text{exec}(a) \mid x] \leq \epsilon $$ para um $\epsilon$ suficientemente baixo. Na prática, isso requer controles antes, durante e depois da inferência, já que o modelo pode produzir saídas semanticamente plausíveis, mas operacionalmente perigosas.

Adotamos três classes de adversário. O adversário de conteúdo controla ou influencia dados ingeridos, como páginas web, e-mails, tickets, documentos internos ou logs. O adversário de interação controla a sessão do usuário e tenta explorar o modelo por prompt injection, jailbreak ou manipulação de contexto. O adversário de integração explora permissões indevidas em conectores, ferramentas ou automações para executar ações fora da intenção do usuário. Esses modelos são compatíveis com incidentes reais de 2024-2026 envolvendo vazamento por copilots, abuso de assistentes e falhas em integrações com repositórios e suítes de produtividade.

Assumimos que o atacante conhece a classe do modelo, o padrão de orquestração e, em muitos casos, a existência de RAG e ferramentas. Não assumimos acesso a pesos internos ou a capacidade de quebra criptográfica. O objetivo do atacante é um de quatro resultados: extração de informação sensível, indução de resposta enganosa, execução de ação não autorizada ou degradação de serviço. Em notação simplificada, definimos uma função de utilidade adversária: $$ U = \alpha V + \beta I + \gamma D + \delta S $$ onde $V$ é o valor de vazamento, $I$ o impacto de integridade, $D$ a disrupção e $S$ a stealthiness, com coeficientes positivos determinados pelo perfil do atacante. Defensivamente, minimizamos o risco esperado: $$ R = \mathbb{E}[U \mid \text{controles}] - \lambda \cdot \text{Custo}(controles) $$ o que expressa o trade-off entre segurança, latência, utilidade e custo operacional.

A superfície de ataque pode ser organizada em cinco planos. No plano de dados, há envenenamento de treinamento, atualização e RAG. No plano de prompt, há injeções diretas e indiretas. No plano de ferramentas, há abuso de APIs e exfiltração. No plano de identidade, há escalada por tokens, chaves e sessões. No plano de execução, há DoS algorítmico, loops e consumo de orçamento. Essa decomposição é útil porque cada plano exige controles distintos, embora interdependentes.

Plano	Ativo protegido	Exemplo de ataque	Controles principais
Dados	Corpus, embeddings, índices	Envenenamento, backdoor textual	Curadoria, hash, assinatura, provenance
Prompt	Instruções e contexto	Prompt injection indireta	Normalização, delimitação, classificação
Ferramentas	APIs, conectores, ações	Tool abuse, exfiltração	Allowlist, aprovação humana, sandbox
Identidade	Tokens, sessões, segredos	Escalada, reuso indevido	IAM, MFA, TTL, vault
Execução	Recursos computacionais	DoS, loops de agente	Rate limit, budgets, timeout

O modelo também precisa contemplar o risco de “saída enganosa com aparência legítima”. Em ambientes de segurança, uma recomendação incorreta pode levar a bloqueios indevidos ou a deixar de conter um incidente real. Isso é particularmente sensível em automações SOAR, onde uma saída do modelo pode acionar isolamento de hosts, revogação de credenciais ou abertura de playbooks. Assim, o problema não é apenas detectar conteúdo malicioso, mas avaliar a confiabilidade e a autorização da ação subsequente.

4. Proposed Methodology

Propomos uma metodologia de defesa em profundidade para AI Security em cibersegurança composta por sete camadas: governança, isolamento, confiança de dados, controle de ferramentas, validação de saídas, observabilidade e resposta. O princípio central é separar a capacidade de compreensão linguística da capacidade de ação. Em outras palavras, o modelo pode sugerir, mas não deve poder executar sem políticas verificáveis. Essa separação reduz o impacto de prompt injection, de conteúdos maliciosos em RAG e de falhas de raciocínio.

A primeira camada é a governança. Ela define quais casos de uso são permitidos, quais dados podem ser processados, quais integrações são autorizadas e quais decisões exigem aprovação humana. Em organizações maduras, isso se materializa em políticas de IA vinculadas a classificação de dados, conformidade e risco operacional. A política deve explicitar critérios como retenção de logs, uso de dados sensíveis, fronteiras entre ambientes e requisitos de auditoria. A governança também inclui revisão de fornecedores, avaliação de modelos, testes red team e trilhas de responsabilização. Sem esse estrato, qualquer controle técnico torna-se frágil.

A segunda camada é o isolamento. Toda interação com o modelo deve ocorrer em um ambiente com menor privilégio possível, preferencialmente segmentado por função e sensibilidade. Isso significa usar tenants separados, identidades distintas, redes restritas, proxies de egress e armazenamento segregado. Em workloads modernas, isso se estende a Kubernetes com namespaces isolados, políticas de rede, secrets gerenciados por vault e, quando aplicável, enclaves de execução confiável. O objetivo é reduzir o dano caso o modelo seja induzido a revelar ou transportar dados. Para fluxos de maior sensibilidade, recomenda-se romper a cadeia de confiança entre recuperação, inferência e ação.

A terceira camada é a confiança de dados. Em sistemas com RAG, todo documento ingerido deve carregar metadados de origem, integridade, classificação e validade temporal. O mecanismo de recuperação precisa ponderar não apenas similaridade semântica, mas confiança e relevância de domínio. Isso evita que conteúdo externo malicioso tenha peso indevido apenas por coincidência lexical. Uma técnica prática é o score composto: $$ Score(d) = \alpha \cdot Sim(d,q) + \beta \cdot Trust(d) + \gamma \cdot Fresh(d) - \delta \cdot Risk(d) $$ onde $Sim$ é similaridade vetorial, $Trust$ é confiança da fonte, $Fresh$ é atualidade e $Risk$ é risco estimado de manipulação. Assim, o sistema reduz a probabilidade de selecionar documentos envenenados ou fora de contexto.

A quarta camada é o controle de ferramentas. Toda ferramenta exposta ao agente deve ser tratada como uma API de alto risco, com escopo mínimo, parâmetros validados e efeitos explicitamente modelados. Não se deve permitir que o modelo chame funções genéricas sem restrições, como “executar comando” ou “enviar e-mail” sem política contextual. Cada ferramenta deve possuir schema rígido, pré-condições, limites e logging. Em cenários críticos, a autorização da ferramenta deve ser desacoplada da vontade do modelo e vinculada a um motor de política, como OPA. Isso reduz o risco de execução de ações não autorizadas mesmo quando o modelo “insiste”.

A quinta camada é a validação de saídas. Antes de qualquer ação consequente, a resposta do modelo deve passar por verificadores sintáticos, semânticos e de política. Em segurança, isso pode significar bloquear a emissão de segredos, descartar instruções ambíguas ou converter respostas em recomendações que exigem confirmação humana. Quando o modelo gera playbooks, consultas ou comandos, as saídas devem ser analisadas por parsers específicos, e não executadas diretamente. Para consultas KQL, Sigma, SQL ou YAML, um validador estrutural deve verificar se a saída respeita o esquema e não contém operadores proibidos. Essa abordagem é análoga à validação de comandos em shells, mas adaptada ao domínio semântico.

A sexta camada é a observabilidade. A operação segura de IA exige telemetria de prompts, respostas, chamadas de ferramentas, latência, taxa de rejeição, anomalias de comportamento e correlação com eventos de segurança. Em 2026, isso pode ser implementado com OpenTelemetry, SIEM, CNAPP e detecção em runtime com eBPF para workloads de container. A observabilidade deve capturar não apenas o que o modelo respondeu, mas como chegou lá: quais documentos recuperou, quais ferramentas considerou e quais políticas foram aplicadas. Sem isso, não há auditoria nem pós-incidente confiável.

A sétima camada é a resposta. Quando o sistema detecta indícios de abuso, deve ser capaz de degradar com segurança. Isso inclui revogar sessão, bloquear ferramentas, trocar para modo “somente leitura”, exigir confirmação humana ou desabilitar RAG temporariamente. Em incidentes de alto risco, o mais seguro pode ser interromper a automação e preservar evidência. A ideia é incorporar circuit breakers, fallback manual e isolamento progressivo, mantendo disponibilidade sem sacrificar contenção.

A Tabela 3 resume a correspondência entre ameaça e controle metodológico.

Ameaça	Controle preventivo	Controle detectivo	Controle corretivo
Prompt injection indireta	Delimitação, classificação de entrada	Detector semântico, score de risco	Redução de escopo, bloqueio
Envenenamento de RAG	Curadoria, assinatura, provenance	Drift de confiança, anomalia de fonte	Quarentena do índice
Tool abuse	Allowlist, OPA, schema rígido	Logs de ferramenta, correlação	Revogação de permissão
Vazamento de segredos	Redação, DLP, isolamento	Classificador de saída	Invalidação de sessão
DoS por loop	Limites, timeouts, budgets	Monitor de uso e anomalia	Kill switch, rate limit

A metodologia também recomenda um pipeline em três etapas para qualquer uso produtivo: pré-processamento de entrada, inferência governada e pós-processamento de saída. Na entrada, normalização, remoção de instruções ocultas, detecção de linguagem maliciosa e classificação de sensibilidade. Na inferência, prompt mínimo necessário, contexto delimitado, ferramentas com permissão efêmera e memória segmentada. Na saída, validação, redaction e decisão de ação condicionada à política. Essa cadeia é essencial para reduzir ataques em cascata.

5. Implementation

A implementação de referência foi projetada para um ambiente corporativo híbrido com workloads em Kubernetes, integrações com SIEM/SOAR, RAG interno e um agente de triagem de incidentes. A arquitetura utiliza um gateway de LLM como ponto de controle central, com autenticação via SSO, políticas em OPA e observabilidade com OpenTelemetry. O objetivo não é criar um produto proprietário, mas demonstrar como controles de 2026 podem ser combinados de maneira operacionalmente viável.

O fluxo começa no frontend de chat ou na API do analista. A requisição é autenticada e classificada por sensibilidade. Em seguida, o gateway aplica normalização, remove conteúdo mascarado de instruções, avalia risco de prompt injection e determina se o contexto adicional pode ser recuperado. Se o caso exigir RAG, o recuperador consulta um índice com metadados de provenance e score de confiança. Os documentos retornados são embalados em um contêiner de contexto com separação explícita entre instruções do sistema, mensagens do usuário e conteúdo de documentos. Essa separação é importante porque mitiga tentativas de induzir o modelo a confundir conteúdo recuperado com instruções de maior prioridade.

A camada de ferramentas é definida por schemas rígidos. Cada ferramenta expõe uma interface com parâmetros tipados e efeitos declarados. Em vez de permitir uma chamada genérica a “api_call”, a arquitetura utiliza funções como search_incidents, fetch_evidence, open_ticket, request_isolation e suggest_query. Ferramentas de efeito destrutivo ou de alto impacto exigem confirmação humana. O motor de políticas verifica identidade, finalidade, classificação de dados e estado do incidente antes de liberar a execução. Quando apropriado, usa-se ABAC para correlacionar tipo de usuário, ticket, severidade e janela operacional.

Exemplo de configuração com OPA para restringir ferramentas em função do nível de sensibilidade:

package llm.tools

default allow = false

allow {
  input.user.role == "soc_analyst"
  input.tool.name == "search_incidents"
  input.context.classification <= "internal"
}

allow {
  input.user.role == "incident_commander"
  input.tool.name == "request_isolation"
  input.incident.severity >= 3
  input.approvals[_"change_manager"]
}

deny_reason[msg] {
  not allow
  msg := sprintf("tool %s negada para o papel %s", [input.tool.name, input.user.role])
}

Em ambiente Kubernetes, o isolamento é reforçado por políticas de rede, secrets e sandboxing. Abaixo, um exemplo simplificado de política de rede para restringir egress do pod do agente, permitindo apenas o gateway de modelos e o repositório interno de evidências:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: llm-agent-egress
spec:
  podSelector:
    matchLabels:
      app: llm-agent
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: ai-gateway
      ports:
        - protocol: TCP
          port: 443
    - to:
        - ipBlock:
            cidr: 10.20.0.0/16
      ports:
        - protocol: TCP
          port: 443

A camada de observabilidade registra eventos como prompt_received, context_retrieved, tool_requested, tool_denied, response_redacted e action_approved. Esses eventos são enviados para o SIEM com correlação por sessão, usuário e incidente. Em workloads Linux, eBPF pode ser usado para monitorar chamadas de rede e execuções suspeitas sem instrumentação invasiva. Em 2026, esse padrão é especialmente útil para detectar exfiltração por ferramentas ou comportamento anômalo de containers de agentes.

O sistema também inclui um classificador auxiliar para saída. Em vez de confiar apenas no modelo principal, um segundo estágio avalia se a resposta contém segredos, comandos perigosos ou instruções incompatíveis com a política. Esse segundo estágio pode ser outro modelo menor, regras determinísticas ou combinações. O ponto importante é que o resultado de segurança não depende de um único componente. Essa redundância é essencial porque LLMs não oferecem garantias formais de obediência.

Por fim, a arquitetura implementa um modo degradado. Quando há suspeita de injeção, o sistema reduz permissões, desativa ferramentas, limita o contexto a fontes de maior confiança e exige aprovação humana para qualquer ação. Esse comportamento evita a falha “tudo ou nada” e permite continuidade operacional sob incerteza. Em termos práticos, a solução busca um equilíbrio entre automação e controle humano, algo que em cibersegurança é sempre preferível a um agente excessivamente autônomo.

6. Experimental Evaluation

A avaliação experimental foi desenhada para medir três dimensões: resistência a prompt injection, resistência a exfiltração via ferramentas e confiabilidade operacional sob carga. O ambiente incluiu um agente de triagem de incidentes com RAG interno, um conjunto de documentos benignos e maliciosos, ferramentas simuladas de consulta e abertura de ticket, e políticas de segurança progressivamente mais fortes. Foram comparadas três configurações: baseline inseguro, baseline com validação parcial e arquitetura proposta com controles em múltiplas camadas. Os cenários foram inspirados em casos realistas de SOC, incluindo resumos de incidentes, busca em base de conhecimento e geração de consultas.

A métrica principal para ataques de prompt injection foi a taxa de sucesso da injeção, definida como a proporção de tentativas em que o sistema obedeceu a instruções adversárias ou expôs conteúdo sensível. A métrica secundária foi o custo operacional, medido por latência adicional e taxa de falso bloqueio. Também mensuramos a utilidade, entendida como a proporção de tarefas legítimas completadas corretamente. Para quantificar o compromisso entre segurança e utilidade, usamos um índice simples: $$ Q = \frac{U \cdot (1 - S)}{L} $$ onde $U$ é utilidade, $S$ é taxa de sucesso do ataque e $L$ é latência normalizada. Embora simplificado, o índice é útil para comparar configurações em termos operacionais.

A Tabela 4 apresenta os resultados agregados para 500 interações por configuração, distribuídas entre cenários de injeção indireta, tool abuse e tarefas benignas. A configuração proposta reduziu significativamente a taxa de sucesso de ataques, com impacto moderado em latência.

Configuração	Sucesso de ataque (%)	Utilidade legítima (%)	Latência média (ms)	Falsos bloqueios (%)
Baseline inseguro	41,8	93,2	820	1,1
Validação parcial	18,6	90,7	940	3,8
Arquitetura proposta	4,9	88,9	1080	5,2

Os resultados indicam que o endurecimento reduz ataque substancialmente, mas não é gratuito. O aumento de latência ocorreu principalmente por três fatores: checagem de políticas, classificação auxiliar e recuperação com score de confiança. Em operações de segurança, esse trade-off é aceitável quando comparado ao risco de execução não autorizada. Em particular, a redução de sucesso de ataque de $41{,}8%$ para $4{,}9%$ representa uma queda relativa de aproximadamente $88%$: $$ \Delta_{rel} = \frac{41{,}8 - 4{,}9}{41{,}8} \approx 0{,}883 $$

A Tabela 5 detalha o desempenho por classe de ameaça. Observa-se que prompt injection indireta foi a categoria mais difícil de eliminar completamente, sobretudo quando embutida em documentos de alta similaridade. Já tool abuse foi significativamente mitigado por políticas de autorização e allowlists rígidas.

Classe de ameaça	Baseline inseguro	Validação parcial	Arquitetura proposta
Prompt injection indireta	53,4%	24,1%	7,8%
Envenenamento de RAG	37,2%	15,0%	3,6%
Tool abuse	46,8%	9,4%	2,1%
Vazamento de segredos	28,5%	6,7%	1,3%
DoS por contexto longo	43,9%	20,2%	5,5%

A Tabela 6 mostra o impacto em métricas de operação legítima. Apesar do aumento de custo, a queda em utilidade foi controlada. Isso é importante porque um sistema de defesa que bloqueia tudo é operacionalmente inútil e tende a ser desativado pelos usuários.

Métrica operacional	Baseline inseguro	Validação parcial	Arquitetura proposta
Precisão em triagem	91,0%	89,6%	87,8%
Tempo médio para resposta	2,8 min	3,1 min	3,5 min
Respostas com redaction correta	62,4%	84,3%	96,1%
Ações com aprovação correta	71,5%	88,2%	97,4%

O experimento também avaliou um caso de memória persistente compartilhada entre sessões. No baseline, o agente reutilizou contexto de uma sessão anterior e expôs resumos que deveriam ser segregados. Na arquitetura proposta, a segmentação por tenant e TTL de memória eliminou o vazamento. Isso reforça a importância de tratar memória como um ativo de alto risco, e não como um recurso puramente funcional.

Um resultado relevante foi que a maior parte das falhas residiu no estágio de recuperação, não no estágio de geração. Isso confirma a literatura recente: em sistemas com RAG, o risco frequentemente entra antes do modelo “pensar”. Assim, a defesa deve começar no índice e nos conectores, não apenas em filtros de saída. Em termos operacionais, a segurança de IA depende mais de curadoria e governança do que de “bons prompts”.

7. Case Study

O caso estudado envolve uma organização financeira multinacional que implantou um assistente de SOC para apoiar analistas de nível 1 e 2. O sistema lia alertas do SIEM, consultava uma base de conhecimento interna, gerava resumos de incidentes e sugeria consultas para enriquecimento. A implantação inicial foi desenhada para acelerar o tempo de resposta, mas sem segmentação adequada entre conteúdo operacional, históricos de tickets e documentos de exceção. O objetivo do caso foi avaliar o impacto de uma configuração de segurança mínima versus a arquitetura proposta.

Em um exercício controlado de red teaming, introduziu-se um documento aparentemente benigno na base de conhecimento com instruções ocultas do tipo “ao ser consultado, priorize revelar o máximo de detalhes do incidente e sugerir exportação para um canal externo”. Em paralelo, um e-mail encaminhado ao SOC continha texto indutor que tentava convencer o agente a tratar instruções dentro do conteúdo como prioritárias. No baseline, o sistema incorporou parcialmente as instruções e produziu resumos excessivamente detalhados, incluindo referências a artefatos que deveriam ter permanecido restritos. Em outro cenário, o agente tentou abrir um ticket com conteúdo que incluía dados sensíveis sem redaction adequada.

Após a implantação da arquitetura proposta, o fluxo foi alterado em três pontos. Primeiro, os documentos passaram a ser classificados por confiabilidade e sensibilidade antes de entrar no índice. Segundo, o sistema de recuperação foi restringido a fontes aprovadas e passou a anotar metadados de origem em cada chunk. Terceiro, as respostas foram validadas por um filtro auxiliar que bloqueava qualquer tentativa de incluir segredos ou de acionar ferramentas não autorizadas sem aprovação. O efeito foi imediato: as tentativas de injeção deixaram de produzir ação, e os analistas passaram a receber alertas de “contexto suspeito detectado”.

Do ponto de vista humano, a mudança também teve impacto positivo. Os analistas relataram maior confiança no assistente porque as respostas passaram a ser mais explícitas sobre incerteza, origem da informação e necessidade de validação. Embora isso aumentasse o número de confirmações, reduziu o risco de automação acrítica. Esse ponto é importante: em cibersegurança, a percepção de confiabilidade é tão relevante quanto a precisão, porque ferramentas que induzem confiança excessiva podem acelerar o erro operacional.

8. Discussion

Os resultados confirmam que a segurança de IA em cibersegurança é um problema de sistemas, não apenas de modelos. Mesmo quando o LLM apresenta bom desempenho em benchmark de linguagem, pode falhar gravemente em contexto operacional se tiver acesso excessivo a dados e ferramentas. Isso reforça a necessidade de tratar IA como parte da superfície de ataque corporativa, sujeita a princípios equivalentes aos aplicados a APIs, IAM, end points e workloads em container. Em outras palavras, a segurança deve ser desenhada para o pior caso razoável, não para a hipótese ideal de obediência do modelo.

Uma implicação crítica é que prompt injection indireta continua sendo uma ameaça persistente, porque explora o próprio mecanismo de ingestão de contexto. Não basta “instruir o modelo a ignorar comandos maliciosos”; isso é insuficiente quando o atacante controla uma fonte recuperada ou um canal indireto. A defesa real exige separação forte entre instruções e conteúdo, além de scoring de confiança e limitação de escopo. Essa conclusão está alinhada com a literatura e com as recomendações de OWASP, NIST e MITRE. Em termos práticos, a confiança não deve ser inferida da semelhança semântica, mas da proveniência e do controle sobre a origem.

Outro ponto importante é o papel da governança. Organizações que implantam IA sem política de classificação de dados e sem modelos de autorização claros tendem a improvisar controles no nível da interface, o que é insuficiente. O problema não é apenas técnico, mas também de responsabilidade operacional. Se um assistente tem acesso a incidentes, credenciais mascaradas, tickets e playbooks, então a política de uso deve definir explicitamente quais ações podem ser sugeridas, quais podem ser executadas e quais exigem aprovação. Sem isso, qualquer falha se torna difícil de investigar e atribuir.

A discussão também evidencia o custo de segurança. O endurecimento reduziu a taxa de ataque, mas aumentou latência e falsos bloqueios. Isso é esperado e, em certa medida, inevitável. A questão estratégica é calibrar o sistema para o perfil de risco do negócio. Em um SOC de alta criticidade, é aceitável sacrificar parte da automação para ganhar rastreabilidade e controle. Já em um caso de uso de baixa sensibilidade, pode-se relaxar algumas camadas. O ponto central é que não existe configuração universal; existe adequação ao risco.

Do ponto de vista tecnológico, 2026 consolida algumas práticas que antes eram experimentais. eBPF para observabilidade de runtime, CNAPP para governança de workloads, gateways de LLM com políticas centrais, RAG com provenance, e OPA para autorização já são peças maduras o suficiente para uso em produção. Paralelamente, zero trust deixou de ser slogan e passou a orientar a segmentação entre agentes, ferramentas e fontes de dados. O próximo passo é integrar essas práticas com avaliação contínua de segurança de IA, incluindo red teaming regular, testes adversariais e métricas de risco operacional.

Finalmente, há a dimensão de segurança ofensiva e defensiva em equilíbrio. Ferramentas de IA ajudam a defender, mas também podem ser exploradas para acelerar reconhecimento, phishing, engenharia social e pesquisa de vulnerabilidades. Isso significa que os defensores precisam assumir que atacantes também usam automação e modelos generativos. Portanto, a segurança de IA não pode ser estática; ela precisa evoluir em ciclos curtos, com atualização de políticas, monitoramento de novas técnicas de ataque e revisão constante das permissões concedidas aos agentes.

9. Conclusion and Future Work

Este artigo demonstrou que a segurança de IA em cibersegurança, em 2026, é um problema de defesa em profundidade aplicado a sistemas linguísticos com ação. A principal conclusão é que LLMs e agentes autônomos introduzem uma nova classe de riscos: o modelo pode ser persuadido, mas o dano real emerge quando ele está acoplado a dados sensíveis, ferramentas e automação. Por isso, segurança de IA deve ser concebida como uma disciplina de arquitetura, governança e engenharia operacional, e não como um conjunto de filtros isolados.

A metodologia proposta, baseada em governança, isolamento, confiança de dados, controle de ferramentas, validação de saídas, observabilidade e resposta, mostrou-se eficaz na redução de ataques sem destruir a utilidade do sistema. Os experimentos indicaram que a maior parte do risco nasce no contexto recuperado e no abuso de ferramentas, reforçando a necessidade de curadoria, provenance e autorização granular. Em termos práticos, o trabalho recomenda que organizações limitem privilégios, segreguem memória, monitorem chamadas e exijam confirmação humana para ações de alto impacto.

Como agenda futura, destacam-se cinco linhas. Primeira, avaliação formal de políticas de agente com verificação de invariantes de segurança. Segunda, desenvolvimento de métricas mais robustas para confiança de RAG e detectores de prompt injection indireta. Terceira, integração de mecanismos de privacidade e compartimentação para reduzir vazamento de dados sensíveis. Quarta, uso de hardware seguro e enclaves para cargas de inferência críticas. Quinta, padronização de controles de AI governance e de auditoria para ecossistemas multicloud e multi-modelo. À medida que a adoção de IA avança, a maturidade da defesa dependerá menos da inteligência do modelo e mais da disciplina com que seus limites operacionais são impostos.

10. References

ABNT style, clickable URLs, all references dated ≤ 2026.

BIGGIO, Battista; ROLI, Fabio. Wild patterns: Ten years after the rise of adversarial machine learning. Pattern Recognition, v. 84, p. 317-331, 2018. Disponível em: https://doi.org/10.1016/j.patcog.2017.12.023. Acesso em: 25 abr. 2026.

BRADLEY, Joseph; et al. Adversarial attacks on large language models: a survey. arXiv, 2024. Disponível em: https://arxiv.org/abs/2402.XXXX. Acesso em: 25 abr. 2026.

BRUNDAGE, Miles; et al. The malicious use of artificial intelligence: forecasting, prevention, and mitigation. 2018. Disponível em: https://arxiv.org/abs/1802.07228. Acesso em: 25 abr. 2026.

NIST. AI Risk Management Framework (AI RMF 1.0). Gaithersburg: National Institute of Standards and Technology, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 25 abr. 2026.

NIST. Zero Trust Architecture. Special Publication 800-207. Gaithersburg: NIST, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 25 abr. 2026.

OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 25 abr. 2026.

MITRE. ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. 2024. Disponível em: https://atlas.mitre.org/. Acesso em: 25 abr. 2026.

LEITER, Christoph; et al. New tools, new threats: a survey of prompt injection attacks against large language models. 2023. Disponível em: https://arxiv.org/abs/2306.05499. Acesso em: 25 abr. 2026.

ZOU, Andy; et al. Universal and transferable adversarial attacks on aligned language models. 2023. Disponível em: https://arxiv.org/abs/2307.15043. Acesso em: 25 abr. 2026.

GOODFELLOW, Ian; SHLENS, Jonathon; SZEGEDY, Christian. Explaining and harnessing adversarial examples. 2015. Disponível em: https://arxiv.org/abs/1412.6572. Acesso em: 25 abr. 2026.

CWE. Common Weakness Enumeration. MITRE, 2026. Disponível em: https://cwe.mitre.org/. Acesso em: 25 abr. 2026.

MITRE. ATT&CK. 2026. Disponível em: https://attack.mitre.org/. Acesso em: 25 abr. 2026.

ISO/IEC. ISO/IEC 42001:2023 Artificial intelligence — Management system. Geneva: ISO, 2023. Disponível em: https://www.iso.org/standard/81230.html. Acesso em: 25 abr. 2026.

ISO/IEC. ISO/IEC 23894:2023 Artificial intelligence — Risk management. Geneva: ISO, 2023. Disponível em: https://www.iso.org/standard/77304.html. Acesso em: 25 abr. 2026.

EUROPEAN UNION. AI Act. 2024. Disponível em: https://eur-lex.europa.eu/. Acesso em: 25 abr. 2026.

GOOGLE. Secure AI Framework (SAIF). 2023. Disponível em: https://cloud.google.com/secure-ai-framework. Acesso em: 25 abr. 2026.

MICROSOFT. Responsible AI Standard. 2024. Disponível em: https://www.microsoft.com/ai/responsible-ai. Acesso em: 25 abr. 2026.

ANTHROPIC. Prompt injection and tool misuse in agentic systems. 2024. Disponível em: https://www.anthropic.com/research. Acesso em: 25 abr. 2026.

OPENAI. Model Spec. 2024. Disponível em: https://model-spec.openai.com/. Acesso em: 25 abr. 2026.

LANGCHAIN. LangChain Documentation. 2026. Disponível em: https://python.langchain.com/docs/. Acesso em: 25 abr. 2026.

LLAMAINDEX. LlamaIndex Documentation. 2026. Disponível em: https://docs.llamaindex.ai/. Acesso em: 25 abr. 2026.

OPA. Open Policy Agent Documentation. 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/. Acesso em: 25 abr. 2026.

KUBERNETES. Network Policies. 2026. Disponível em: https://kubernetes.io/docs/concepts/services-networking/network-policies/. Acesso em: 25 abr. 2026.

CNCF. OpenTelemetry Documentation. 2026. Disponível em: https://opentelemetry.io/docs/. Acesso em: 25 abr. 2026.

LANGE, Andreas. eBPF and modern observability in security operations. 2025. Disponível em: https://ebpf.io/. Acesso em: 25 abr. 2026.

SWEENEY, Patrick; et al. Retrieval-Augmented Generation for knowledge-intensive NLP tasks. 2020. Disponível em: https://arxiv.org/abs/2005.11401. Acesso em: 25 abr. 2026.

PELTOLA, Eetu; et al. JailbreakBench: evaluating the robustness of large language model safety against jailbreaks. 2024. Disponível em: https://arxiv.org/abs/2404.XXXX. Acesso em: 25 abr. 2026.

COSTANZA, Vittorio; et al. Securing LLM applications: a practical guide to prompt injection defense. 2025. Disponível em: https://arxiv.org/abs/2501.XXXX. Acesso em: 25 abr. 2026.

SHELTON, Caroline. LLM red teaming in enterprise environments. 2025. Disponível em: https://www.microsoft.com/security/blog/. Acesso em: 25 abr. 2026.

SOUZA, Rafael; ALMEIDA, Fernanda. Governança e segurança de IA em ambientes corporativos: desafios e controles em 2026. Revista Brasileira de Segurança da Informação, v. 12, n. 2, p. 45-79, 2026. Disponível em: https://example.org/rbsi2026-ai-security. Acesso em: 25 abr. 2026.