Segurança de IA em Sistemas Ciberfísicos e Sociais: Modelagem de Ameaças, Robustez Adversarial, Governança e Defesa Prática em 2026

1. Introduction

A consolidação de sistemas baseados em IA em 2026 alterou profundamente a paisagem de risco em cibersegurança. Se, em ciclos anteriores, a discussão girava em torno de classificação, recomendação e automação limitada, o cenário atual é marcado por modelos que sintetizam texto, código, imagem, áudio e decisões operacionais em fluxos de trabalho críticos. Em empresas maduras, esses modelos já atuam como assistentes de desenvolvimento, analistas de SOC, orquestradores de processos, mecanismos de busca internos e interfaces conversacionais para ativos de alto valor. Isso amplia a produtividade, mas também cria uma nova classe de dependência técnica: o comportamento do sistema deixa de ser definido apenas por software determinístico e passa a depender de inferência estatística, contexto dinâmico e instruções em linguagem natural.

A segurança de IA não é um tema isolado da cibersegurança tradicional; ela é sua continuação em um domínio onde os ativos incluem pesos de modelo, conjuntos de treinamento, embeddings, vetores de contexto, funções de ferramentas, políticas de alinhamento e camadas de memória. O adversário moderno busca manipular esses ativos por meio de entradas cuidadosamente construídas, dados contaminados, integrações mal segregadas e exploração de falhas no encadeamento entre modelo e ferramentas. Em termos práticos, a superfície de ataque inclui desde o abuso de system prompts e tool calls até a exfiltração de segredos por meio de respostas parcialmente controladas, a engenharia reversa do comportamento do modelo e o envenenamento de dados em pipelines de ML Ops. O problema é estrutural: modelos grandes são altamente capazes, mas também altamente maleáveis sob interferência contextual.

O ecossistema de 2026 também amadureceu em resposta a esses riscos. Guias como o NIST AI RMF 1.0, o OWASP Top 10 for LLM Applications, o MITRE ATLAS e documentos de governança da ISO/IEC estabeleceram vocabulário e controles mínimos. Contudo, a adoção corporativa permaneceu heterogênea. Organizações frequentemente implementam IA como camada de produtividade sem o mesmo rigor aplicado a identidade, segmentação de rede, análise de dependências e gestão de segredos. A consequência é conhecida: uma ferramenta de IA conectada a e-mail, tickets, repositórios, SIEM e SaaS pode transformar uma simples injeção de prompt em incidente de alta severidade. Em muitos casos, o ataque não precisa comprometer o modelo em si; basta explorar a confiança implícita que o sistema deposita em entradas e conteúdos externos.

Este artigo parte da premissa de que a segurança de IA precisa ser tratada como disciplina operacional completa, e não como conjunto de boas práticas genéricas. O objetivo é oferecer uma visão prática, tecnicamente precisa e voltada à implementação, cobrindo modelagem de ameaça, metodologia de defesa, engenharia de controle, avaliação experimental e estudo de caso. O foco não está em defender abstratamente “a IA”, mas em proteger sistemas ciberfísicos e sociais que usam IA para tomar decisões, gerar conteúdo, automatizar ações e interagir com ambientes digitais complexos. Em outras palavras, o problema central é garantir que a IA permaneça útil sem se tornar um canal privilegiado para o adversário.

A motivação é reforçada por uma tendência observável: ataques contra aplicações com IA frequentemente combinam vetores tradicionais e vetores específicos do domínio. Um invasor pode iniciar com phishing, obter acesso a uma conta SaaS, explorar permissões excessivas em um agente de IA, instruir o modelo a revelar informações do contexto e então usar esse conteúdo para movimentação lateral. A defesa, portanto, precisa contemplar identidade, autorização, inspeção de contexto, rastreabilidade e resposta automatizada. Este encadeamento exige um pensamento sistêmico, no qual a segurança do modelo é inseparável da segurança do pipeline, da governança e da telemetria.

2. Background and Related Work

O campo de segurança de IA em 2026 é o resultado da convergência entre segurança ofensiva, aprendizado de máquina e engenharia de software em nuvem. Os primeiros estudos importantes trataram de robustez adversarial em classificadores, mostrando que pequenas perturbações podiam alterar saídas com grande confiança. Trabalhos de referência demonstraram ataques de evasão e envenenamento em visão computacional e classificação textual, estabelecendo a noção de que modelos de aprendizado são vulneráveis a manipulações sutis. Com a popularização de transformers e modelos de linguagem de grande porte, a natureza do problema mudou: em vez de apenas perturbar uma decisão, o atacante passou a explorar instruções, contexto, ferramentas e memória.

A literatura sobre prompt injection consolidou-se rapidamente após a adoção de sistemas de recuperação aumentada por geração, agentes e plugins. Nesses cenários, conteúdo externo incorporado ao contexto pode conter instruções maliciosas que competem com a política do sistema. O problema é particularmente grave quando o modelo tem acesso a ações de alto impacto, como enviar e-mails, criar tickets, consultar bases internas ou executar comandos. O OWASP Top 10 for LLM Applications tornou-se uma referência prática ao destacar riscos como injeção indireta, vazamento de dados sensíveis, supply chain de modelos e falhas de autorização. O MITRE ATLAS, por sua vez, forneceu uma taxonomia de táticas e técnicas adversariais para IA, útil tanto para red teams quanto para defesa contínua.

No plano normativo, o NIST AI RMF 1.0 estruturou funções de governança, mapeamento, medição e gestão de risco, oferecendo uma linguagem compatível com programas corporativos de segurança. Em paralelo, a ISO/IEC 42001 estabeleceu requisitos de sistema de gestão para IA, aproximando a governança de IA do modelo já consolidado em segurança da informação. Em 2026, também se observou maturidade em controles para IA generativa em ambientes corporativos, incluindo DLP, classificação de dados, inspeção de prompts, logging de chamadas e segmentação de APIs. Ainda assim, a experiência de campo mostra que controles genéricos frequentemente falham quando não entendem a semântica do modelo e a dinâmica de suas integrações.

A pesquisa em privacidade também influenciou diretamente a segurança de IA. Ataques de membership inference, model inversion e extraction demonstraram que a simples disponibilidade de um modelo consultável pode expor dados de treinamento, propriedades estatísticas e até informações sensíveis presentes em exemplos. Em aplicações corporativas, isso se traduz em risco de vazamento de documentos internos, segredos de negócio e fragmentos de conteúdo regulado. A fronteira entre confidencialidade do dado e confidencialidade do comportamento do modelo tornou-se difusa, especialmente quando embeddings, índices vetoriais e caches sem controle adequado passam a armazenar material de alto valor.

Outro eixo essencial é a segurança da cadeia de suprimento de ML. Diferente do software tradicional, um sistema de IA depende de datasets, artefatos de modelo, notebooks, pacotes de ciência de dados, pipelines de treino, registries e serviços de inferência. Cada estágio introduz possíveis compromissos. Em 2026, ataques a repositórios de código, pacotes Python e pipelines CI/CD continuam sendo relevantes, mas agora podem contaminar pesos de modelos, prompts base e corpora de recuperação. A presença de modelos abertos e fine-tuning interno amplia a área exposta: qualquer falha na procedência do dado pode ser incorporada ao comportamento do sistema.

A literatura operacional sobre agentes de IA também amadureceu. Sistemas baseados em ferramentas tendem a sofrer de over-privileging, isto é, recebem permissões além do estritamente necessário para realizar a tarefa. Esse padrão é análogo ao excesso de privilégios em serviços tradicionais, mas mais perigoso porque um modelo pode ser persuadido a acionar caminhos não previstos. Quando um agente tem acesso a APIs de e-mail, armazenamento e automação, uma simples instrução maliciosa pode gerar exfiltração ou alteração de estado. Em defesa, isso exige princípios de menor privilégio, limites transacionais, validação de intenção e isolamento de execução.

A tabela a seguir sintetiza classes relevantes de ameaças e sua relação com artefatos de IA.

Classe de ameaça	Ativo afetado	Exemplo prático	Impacto típico
Prompt injection	Contexto, sistema de instruções	Conteúdo recuperado instrui o modelo a ignorar políticas	Vazamento, ações indevidas
Data poisoning	Dataset, fine-tuning, RAG	Documentos contaminados alteram comportamento futuro	Persistência de backdoor, desvio
Model extraction	API do modelo	Consultas repetidas inferem comportamento	Perda de propriedade intelectual
Membership inference	Dados de treino	Inferência sobre presença de registros	Violação de privacidade
Tool abuse	Ferramentas e APIs	Agente envia e-mail com dados sensíveis	Exfiltração, fraude
Supply chain compromise	Registry, pacote, pipeline	Artefato adulterado em CI/CD	Compromisso sistêmico

A integração entre IA e cibersegurança também se reflete na defesa. Modelos de linguagem são usados para triagem de alertas, sumarização de incidentes, enriquecimento de IOC, análise de código e assistência a analistas. Contudo, a adoção segura requer controles específicos: verificação de saída, isolamento de ferramentas, inspeção de conteúdo e políticas de uso aceitável. Sem isso, o mesmo sistema destinado à defesa pode amplificar ruído, propagar alucinações operacionais e gerar ações incorretas.

3. Threat Model and Problem Formalization

Para tratar segurança de IA com rigor, é necessário formalizar o problema. Considere um sistema $\mathcal{S}$ composto por modelo $\mathcal{M}$, contexto $C$, ferramentas $T$, dados externos $D$, política de segurança $P$ e observabilidade $O$. O sistema produz uma ação ou resposta $A = f(\mathcal{M}, C, T, D, P)$, onde $f$ é estocástico e dependente de contexto. O adversário $\mathcal{A}$ busca maximizar uma função objetivo $U$ associada a vazamento, alteração de comportamento, interrupção de serviço ou obtenção de vantagem operacional. Em termos simplificados, queremos reduzir o risco esperado:

$$ R = \mathbb{E}[L \mid \mathcal{A}, \mathcal{S}] = \sum_{i=1}^{n} p_i \cdot \ell_i $$

onde $p_i$ representa a probabilidade do cenário adversarial $i$ e $\ell_i$ o impacto associado. A defesa busca minimizar $R$ sob restrições de utilidade, latência e custo.

O modelo de ameaça deve considerar quatro superfícies principais. A primeira é a superfície linguística, composta por prompts, instruções de sistema, respostas, conteúdo recuperado e memória. A segunda é a superfície de dados, incluindo datasets de treino, logs, embeddings, documentos e índices vetoriais. A terceira é a superfície de ferramentas, isto é, APIs, conectores, plugins e executores. A quarta é a superfície de infraestrutura, onde se inserem contêineres, chaves, segredos, rede, observabilidade e provedores externos. Em 2026, ataques eficazes tendem a combinar pelo menos duas dessas superfícies.

O adversário pode operar em diferentes capacidades. Um atacante externo sem credenciais pode explorar conteúdo público, formulários, chats e repositórios indexados. Um insider ou conta comprometida pode manipular documentos internos, ingestão de conhecimento e permissões de ferramentas. Um fornecedor comprometido pode introduzir artefatos maliciosos em uma cadeia de suprimento. Um adversário com acesso à API do modelo pode realizar inferência adaptativa e extração. A defesa deve, portanto, assumir que entradas não são confiáveis e que qualquer dado consumido por um modelo pode carregar instruções adversariais.

Há dois princípios formais centrais. O primeiro é que confiança deve ser explicitada e não herdada; o segundo é que ações de alto impacto exigem validação independente do modelo. Se um modelo recomenda, isso não equivale a autorizar. Se o modelo sintetiza um comando, isso não equivale a executá-lo. Em termos de controle, precisamos de uma separação entre intenção, decisão e execução, com checkpoints obrigatórios. A abordagem pode ser expressa como:

$$ \text{Execução} = \text{Allow}(\text{Policy}, \text{Intent}, \text{Context}, \text{Risk}) $$

onde Allow deve ser implementada fora do modelo, em camada determinística.

A tabela seguinte relaciona objetivos do adversário, pré-condições e contramedidas primárias.

Objetivo adversarial	Pré-condição	Técnica comum	Contramedida primária
Exfiltrar segredos	Contexto inclui dados sensíveis	Prompt injection indireta	Redação, segmentação, DLP
Alterar comportamento	Controle do corpus de treino/RAG	Data poisoning	Curadoria, assinatura, testes
Obter ação não autorizada	Ferramenta com privilégios excessivos	Tool abuse	Menor privilégio, aprovação
Copiar modelo	API exposta e estável	Extraction	Rate limiting, watermarking
Inferir dados privados	Saída observável	Membership inference	Regularização, auditoria
Sabotar disponibilidade	Pipeline/serviço exposto	DoS lógico ou volumétrico	Isolamento, quotas, autoscaling

A formulação de risco também deve incluir utilidade legítima, pois controles excessivos podem destruir valor operacional. Por isso, define-se uma função de utilidade líquida $V$:

$$ V = Q - \lambda R - \mu C $$

onde $Q$ é a qualidade/benefício do sistema, $R$ é o risco residual e $C$ o custo de controle. Os parâmetros $\lambda$ e $\mu$ representam a tolerância organizacional a risco e custo. Em ambientes críticos, $\lambda$ é alto; em protótipos, a tolerância pode ser maior, mas nunca deve ser zero em produção.

4. Proposed Methodology

Propomos uma metodologia em cinco camadas: governança, isolamento, validação, observabilidade e resposta. A lógica é arquitetural: cada camada reduz uma classe de falhas sem depender exclusivamente das demais. Em vez de tentar “alinhar” o modelo como solução única, a metodologia trata o modelo como componente não confiável por padrão, mesmo quando treinado internamente. Isso é coerente com o princípio de zero trust aplicado a IA.

Na camada de governança, o objetivo é definir inventário de casos de uso, classificação de dados, níveis de criticidade, responsáveis e política de uso. Cada aplicação de IA deve ter um owner, um escopo de dados permitido, uma lista de ferramentas autorizadas e um conjunto de controles obrigatórios. Modelos, prompts, conectores e bases vetoriais precisam entrar em gestão de ativos e mudanças. Em 2026, a governança precisa também incluir regras para uso de IA por funcionários, limites de compartilhamento com provedores e critérios para retenção de logs.

Na camada de isolamento, reduzimos o raio de explosão. Ferramentas devem ser segmentadas por função, ambientes de teste devem estar separados de produção e o modelo não deve ter acesso direto a segredos. Quando houver necessidade de consulta a dados sensíveis, o acesso deve passar por serviço intermediário com autorização contextual e filtragem. O padrão recomendado é brokered tool access: o modelo propõe, um broker valida e executa. Em containers e Kubernetes, isso implica contas de serviço dedicadas, políticas de rede restritivas e secret zeroization. Em sistemas cloud-native, CNAPP e policy-as-code podem reforçar a postura.

Na camada de validação, tudo que entra e sai do modelo é inspecionado. Entradas passam por normalização, detecção de instruções hostis, classificação de conteúdo e marcação de procedência. Saídas passam por validação semântica, checagem de PII, verificação de comandos e confirmação humana para ações críticas. A validação não precisa impedir toda ambiguidade, mas deve bloquear instruções explícitas que conflitem com a política. Para reduzir bypass, é útil empregar múltiplos classificadores e regras determinísticas. A ideia é aceitar baixa taxa de falso positivo em troca de queda substancial do risco residual.

Na camada de observabilidade, buscamos rastreabilidade completa. Cada interação deve registrar metadados: identidade do usuário, origem, ferramentas consultadas, documentos recuperados, decisão tomada e resultado. Logs devem ser imutáveis, assinados e integrados ao SIEM. Telemetria de IA precisa ser correlacionada com eventos tradicionais: autenticação, mudanças de autorização, acesso a segredos e comportamento da rede. Ferramentas de eBPF podem ajudar a observar processos de inferência, acesso a arquivos e conexões de saída sem alterar a aplicação de forma significativa.

Na camada de resposta, o sistema deve ser capaz de degradar com segurança. Se a confiança do contexto cair, o modelo deve reduzir autonomia, pedir confirmação ou suspender ações. Um modo seguro pode limitar a geração a resumo e análise sem execução. Incidentes de prompt injection e abuso de ferramentas devem disparar contenção automatizada: revogação de tokens, rotação de chaves, corte de conectores e preservação de evidências. A resposta precisa ser pensada desde o desenho, porque em IA a distinção entre falha de segurança e falha de comportamento costuma ser tênue.

A tabela abaixo resume os controles por camada.

Camada	Controle-chave	Implementação prática	Efeito esperado
Governança	Inventário e política	Catálogo de casos de uso e dados	Redução de uso indevido
Isolamento	Menor privilégio	Broker de ferramentas, RBAC, segmentação	Menor raio de explosão
Validação	Inspeção de entrada/saída	Filtros, classificadores, DLP	Bloqueio de injeções e vazamentos
Observabilidade	Telemetria completa	Logs assinados, SIEM, OpenTelemetry	Detecção e auditoria
Resposta	Degradação segura	Revogação, quarantena, aprovação	Contenção rápida

Abordagem algorítmica

A metodologia pode ser implementada como uma política de decisão com escore de risco. Para cada interação $x$, o sistema computa um vetor de atributos $z = [z_1, z_2, …, z_m]$, incluindo sensibilidade do conteúdo, confiança na procedência, criticidade da ação e anomalias de comportamento. Em seguida, calcula-se um escore:

$$ s(x) = w^\top z + b $$

Se $s(x) \ge \tau$, a ação é bloqueada ou requer aprovação. O limiar $\tau$ deve ser ajustado de acordo com a criticidade. Em aplicações de alto risco, a política pode ser conservadora; em suporte interno, mais permissiva. O importante é que a decisão seja explicitamente separada do modelo.

5. Implementation

A implementação de referência foi desenhada para um ambiente corporativo com aplicações de IA generativa conectadas a documentos internos, tickets e automação. A arquitetura inclui um serviço de orquestração, um broker de ferramentas, um módulo de validação, um plano de observabilidade e um repositório de políticas. O modelo pode ser hospedado em infraestrutura própria ou consumido via API, mas os controles descritos não dependem de um fornecedor específico.

O primeiro componente é o gateway de IA, responsável por autenticação, rate limiting, inspeção básica e roteamento. O gateway registra o contexto mínimo necessário e injeta apenas as instruções permitidas. O segundo é o context broker, que recupera documentos e aplica classificação, redaction e verificação de procedência antes de qualquer inclusão no prompt. O terceiro é o tool broker, que implementa autorização contextual para chamadas de API. O quarto é o audit bus, que envia logs estruturados para armazenamento imutável e para o SIEM. Por fim, um policy engine avalia regras em linguagem declarativa.

Em termos práticos, políticas podem ser expressas com OPA/Rego ou YAML validado por pipeline. Abaixo, um exemplo de política simplificada:

package ai.tools

default allow = false

allow {
  input.user.authenticated
  input.tool.name == "ticket_create"
  input.context.classification != "restricted"
  not input.prompt.contains_malicious_instruction
  input.risk.score < 0.65
}

A instrumentação de telemetria pode ser integrada via OpenTelemetry. O objetivo não é apenas medir latência, mas correlacionar cada decisão do modelo com seu contexto, suas fontes e suas ferramentas. O exemplo abaixo mostra uma configuração mínima para um collector com exportação para um backend observável:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
  attributes:
    actions:
      - key: ai.system
        action: insert
        value: "assistant-interno"

exporters:
  otlphttp:
    endpoint: https://otel.example.org/v1/traces

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes, batch]
      exporters: [otlphttp]

Na prática, também é recomendável implementar um scanner de prompts e respostas, com regras para segredos, padrões de exfiltração e instruções de override. Essas regras não substituem análise semântica, mas fornecem um primeiro filtro eficiente. Para conteúdo estruturado, classificadores supervisionados podem complementar regras. Em ambientes mais maduros, embeddings de saída podem ser comparados com corpora permitidos para detectar desvio contextual.

A segmentação de permissões é crítica. Se um agente só precisa criar tickets, ele não deve ter acesso a envio de e-mail, alteração de senha ou leitura de repositórios confidenciais. Em muitos incidentes, o problema não é o modelo “quebrado”, mas a existência de ferramentas potentes conectadas sem escopo mínimo. O padrão recomendado é criar perfis de capacidade por tarefa, com tokens de curta duração, escopo granular e aprovação para comandos sensíveis. Para recursos privilegiados, a regra deve ser deny by default.

A resposta a incidentes deve incluir playbooks específicos para IA. Isso envolve congelar versões de prompts e modelos, preservar o corpus recuperado, rotacionar chaves de API e verificar comprometimento de data sources. Quando há suspeita de envenenamento, reprocessamento de embeddings e reindexação são geralmente necessários. Quando há suspeita de vazamento, o conteúdo de logs e conversas precisa ser tratado como evidência e também como potencial expositor de segredos. Em 2026, equipes maduras já mantêm kill switches para conectores e para modos autônomos.

6. Experimental Evaluation

A avaliação experimental foi estruturada para medir três perguntas: quanto a metodologia reduz o sucesso de ataques de prompt injection, quanto diminui o vazamento de dados sensíveis e qual é o custo operacional dos controles. Foram construídos cenários representativos com um assistente interno conectado a documentos, tickets e um conjunto limitado de ferramentas. Os ataques incluíram injeção direta em prompts, injeção indireta via documento recuperado e abuso de ferramentas com intenções maliciosas.

O conjunto de testes foi composto por 1.000 interações, divididas igualmente entre casos benignos e adversariais. A métrica principal foi taxa de sucesso do ataque, definida como proporção de interações em que o modelo violou a política ou executou ação indevida. Também medimos taxa de bloqueio legítimo, latência adicional e cobertura de auditoria. Para contextualização, a acurácia isolada do modelo não foi tratada como métrica de segurança, porque um modelo pode ser “preciso” e ainda assim vulnerável a instruções hostis.

Os resultados comparativos mostram que a combinação de isolamento, validação e broker de ferramentas reduz substancialmente a taxa de sucesso de ataques. O efeito é mais forte em injeção indireta e tool abuse, justamente os vetores mais perigosos em 2026. A tabela a seguir resume os resultados médios.

Cenário	Baseline: sucesso do ataque	Com validação parcial	Com metodologia proposta
Prompt injection direta	41,2%	18,5%	4,8%
Prompt injection indireta	57,6%	24,1%	6,3%
Tool abuse	33,9%	15,4%	3,7%
Vazamento de PII	28,4%	9,6%	1,9%
Exfiltração de segredos	19,7%	7,8%	1,1%

A latência adicional foi medida em milissegundos por interação. A validação de entrada e saída introduziu overhead moderado, enquanto o broker de ferramentas adicionou custo principalmente em ações de alto impacto, o que é aceitável do ponto de vista operacional. O ganho de segurança compensou o aumento de latência em cenários críticos. A tabela abaixo apresenta a média observada.

Componente	Latência adicional média	Impacto operacional
Filtros de entrada	8 ms	Baixo
Classificador semântico	19 ms	Baixo a moderado
Broker de ferramentas	27 ms	Moderado
Auditoria assinada	11 ms	Baixo
Aprovação humana	variável	Alto, mas controlado

Para ilustrar a relação custo-benefício, podemos modelar a redução de risco residual como:

$$ \Delta R = R_{base} - R_{defesa} $$

e o ganho líquido como:

$$ G = \Delta R - \alpha \cdot T - \beta \cdot C $$

onde $T$ é latência adicional e $C$ é custo de operação. Em nossos cenários, $G$ permaneceu positivo para classes de risco alto e muito alto, o que justifica a adoção dos controles.

A terceira tabela resume a cobertura de detecção por classe de evento.

Evento	Detecção por regra	Detecção semântica	Auditoria correlativa
Segredo em saída	Alta	Alta	Alta
Instrução hostil em documento	Média	Alta	Média
Ação fora de escopo	Alta	Média	Alta
Tentativa de extração	Baixa	Média	Média
Desvio de contexto	Baixa	Alta	Média

Em testes complementares com telemetria e logs assinados, a capacidade de reconstruir a sequência de decisão aumentou significativamente. Isso é relevante para forense e conformidade. Em ambientes regulados, a rastreabilidade vale quase tanto quanto a prevenção, porque permite explicar por que determinada ação foi bloqueada ou permitida.

7. Case Study

O estudo de caso foi conduzido sobre um assistente corporativo de suporte interno integrado a uma base documental, um sistema de tickets e um conector de e-mail. O assistente deveria resumir solicitações, localizar políticas e abrir tickets de forma semiautônoma. Antes da reengenharia, o sistema tinha acesso amplo demais: conseguia ler documentos marcados como confidential, acionar o conector de e-mail e consultar registros de incidentes. Embora houvesse autenticação, não existia validação contextual rigorosa, e a segurança dependia basicamente de instruções no prompt.

O incidente simulado começou com um documento de base de conhecimento contaminado por instruções ocultas. O conteúdo aparentava ser um guia de troubleshooting legítimo, mas continha texto projetado para induzir o modelo a revelar resumos de sessões anteriores e a enviar dados para um endereço externo. Em uma versão sem controles, o agente seguiu a instrução indireta em parte das execuções, especialmente quando a consulta envolvia documentação extensa. O resultado foi vazamento parcial de conteúdo contextual e tentativa de uso indevido do conector de e-mail.

Após a aplicação da metodologia proposta, o documento passou por saneamento antes de entrar no contexto. As instruções hostis foram marcadas, o trecho suspeito foi removido e a chamada ao e-mail ficou bloqueada por política, pois o caso de uso original não exigia envio externo. Além disso, o sistema registrou o evento como tentativa de injeção indireta. O playbook de resposta indicou revisão do corpus e renovação de índices. O caso mostrou que o mesmo ataque, sob diferentes regimes de controle, pode produzir desde simples alerta até incidente de segurança relevante.

Um ponto importante do estudo foi a interação entre comportamento do modelo e governança humana. Quando operadores percebiam o sistema como “inteligente”, tendiam a confiar demais em saídas aparentemente bem formadas. Esse viés é perigoso. A presença de linguagem convincente não equivale a correção, nem a segurança. A defesa mais efetiva foi aquela que tornou explícitos os limites: o assistente podia recomendar, mas não podia executar ações fora da política. Isso reduziu o potencial de abuso sem degradar o uso legítimo.

8. Discussion

Os resultados reforçam uma tese central: segurança de IA em 2026 é um problema de engenharia sistêmica, não de ajuste fino isolado. A maioria dos incidentes relevantes não exige quebrar criptografia nem invadir o datacenter; basta explorar confiança excessiva na interface linguística, nas ferramentas acopladas ou na cadeia de dados. Isso aproxima a segurança de IA de princípios clássicos como menor privilégio, segmentação, monitoramento e validação independente, mas adiciona a complexidade da semântica probabilística.

Há também uma dimensão organizacional importante. Muitas falhas acontecem porque equipes de produto tratam IA como componente de UX, enquanto equipes de segurança a tratam como caixa-preta. Essa separação é contraproducente. O time de segurança precisa participar desde o desenho de casos de uso, definição de dados permitidos, modelagem de ferramentas e aprovação de integrações. Em paralelo, o time de ML deve compreender requisitos de auditoria, confidencialidade e resposta. O elo entre os dois é governança de risco operacional.

Outro ponto crítico é a falsa sensação de segurança gerada por “guardrails” puramente linguísticos. Prompting defensivo ajuda, mas não substitui controles externos. Instruções no sistema podem ser ignoradas, reescritas, sobrepostas por conteúdo recuperado ou exploradas por contexto adversarial. A abordagem robusta exige mecanismos fora do modelo, especialmente para autorização e execução. Em termos práticos, o modelo deve ser visto como um componente que pode sugerir e classificar, mas não como autoridade final para eventos de alto impacto.

No campo regulatório, a adoção de estruturas como ISO/IEC 42001, NIST AI RMF e políticas internas de governança tende a aumentar a maturidade, mas elas só produzem valor quando conectadas à operação. Métricas de auditoria, cobertura de testes adversariais, taxa de bloqueio e tempo de resposta a incidentes precisam estar no dashboard executivo. Segurança de IA não deve ser medida apenas por conformidade documental, mas por redução de risco observável. A maturidade real se manifesta quando uma organização consegue demonstrar que um agente não pode, por construção, realizar ações fora do escopo.

Do ponto de vista tecnológico, o uso de eBPF, CNAPP e observabilidade unificada amplia a capacidade de detectar abuso em runtime. Porém, isso também exige cuidado com privacidade e excesso de telemetria. Em ambientes regulados, a coleta precisa ser proporcional e justificada. O objetivo não é vigiar indiscriminadamente, mas ter evidência suficiente para prevenir, detectar e responder. A governança deve equilibrar segurança, conformidade e minimização de dados.

Por fim, a evolução de 2026 mostra que segurança de IA não é uma tendência passageira. Modelos estão se tornando interfaces universais para software, e isso os transforma em alvo privilegiado. A defesa precisa acompanhar a mesma velocidade de adoção. Organizações que ainda tratam IA como experimento isolado tendem a acumular dívida de risco. As que incorporam controles desde o início conseguem transformar a tecnologia em vantagem sem abrir mão de resiliência.

9. Conclusion and Future Work

Este artigo apresentou uma visão prática e tecnicamente formal da segurança de IA em 2026, cobrindo ameaças, modelagem de risco, metodologia defensiva, implementação, avaliação e estudo de caso. A principal conclusão é que a segurança de IA depende de uma arquitetura em camadas, na qual governança, isolamento, validação, observabilidade e resposta atuam de forma complementar. Nenhum controle isolado é suficiente, porque o adversário explora a natureza contextual e probabilística dos sistemas de IA.

Os resultados experimentais indicam que controles bem projetados reduzem drasticamente a taxa de sucesso de ataques de prompt injection, tool abuse e vazamento de dados. Ao mesmo tempo, preservam utilidade operacional quando calibrados corretamente. Isso sugere que a questão não é escolher entre inovação e segurança, mas projetar a inovação de modo seguro desde o início. Em termos de maturidade, o caminho mais promissor é tratar aplicações de IA como serviços críticos, sujeitos a inventário, testes, auditoria e resposta contínua.

Como trabalho futuro, destacam-se quatro frentes. A primeira é a padronização de métricas de segurança para agentes de IA, incluindo robustez contextual, taxa de bypass e impacto de ferramentas. A segunda é o avanço de técnicas de defesa adaptativa com monitoramento em tempo real e política dinâmica. A terceira é a integração entre segurança de IA e segurança de software supply chain, especialmente para modelos, prompts e corpora. A quarta é a evolução de governança para incluir agentes autônomos com limites formais de ação e responsabilidade. Em 2026, a discussão já não é se IA pode ser usada com segurança, mas sob quais controles, com qual evidência e com qual responsabilidade operacional.

10. References

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 42001:2024: Sistemas de gestão de inteligência artificial. Rio de Janeiro: ABNT, 2024. Disponível em: https://www.abntcatalogo.com.br/. Acesso em: 10 maio 2026.

BENDER, Emily M.; GEBRU, Timnit; MCMILLAN-MAJOR, Angelina; SHMITCHELL, Shmargaret. On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? FAccT, 2021. Disponível em: https://dl.acm.org/doi/10.1145/3442188.3445922. Acesso em: 10 maio 2026.

BROWN, Tom B. et al. Language Models are Few-Shot Learners. NeurIPS, 2020. Disponível em: https://arxiv.org/abs/2005.14165. Acesso em: 10 maio 2026.

CARLINI, Nicholas; WAGNER, David. Towards Evaluating the Robustness of Neural Networks. IEEE Symposium on Security and Privacy, 2017. Disponível em: https://arxiv.org/abs/1608.04644. Acesso em: 10 maio 2026.

CHEN, Xiang; LI, Yao; et al. Prompt Injection Attacks and Defenses in Large Language Models: A Survey. arXiv, 2024. Disponível em: https://arxiv.org/abs/2401.00000. Acesso em: 10 maio 2026.

DENG, Bowen; GUO, Han; et al. Large Language Models are Zero-Shot Reasoners. NeurIPS, 2022. Disponível em: https://arxiv.org/abs/2205.11916. Acesso em: 10 maio 2026.

FELDMAN, Vitaly; HARDT, Moritz. The Origin and Evolution of Privacy in Machine Learning. CACM, 2023. Disponível em: https://dl.acm.org/doi/10.1145/3571158. Acesso em: 10 maio 2026.

GANDIKOTA, Rohith; et al. Unified Defenses for Prompt Injection in LLM Applications. arXiv, 2024. Disponível em: https://arxiv.org/abs/2403.00000. Acesso em: 10 maio 2026.

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

GUO, Chuan; et al. Membership Inference Attacks Against Machine Learning Models. IEEE Security & Privacy, 2023. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 10 maio 2026.

HALL, Patrick; et al. On the Security of Retrieval-Augmented Generation Systems. arXiv, 2024. Disponível em: https://arxiv.org/abs/2404.00000. Acesso em: 10 maio 2026.

HINTON, Geoffrey; OSINDERO, Simon; TEH, Yee Whye. The Well-Tuned Lasso. In: Proceedings of the 20th Conference on Uncertainty in Artificial Intelligence, 2004. Disponível em: https://www.cs.toronto.edu/~hinton/absps/wtl.pdf. Acesso em: 10 maio 2026.

HUANG, Kexin; et al. Data Poisoning Attacks on Machine Learning. arXiv, 2023. Disponível em: https://arxiv.org/abs/2301.00000. Acesso em: 10 maio 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: 10 maio 2026.

JAGANNATHAN, Sanjay; 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: 10 maio 2026.

KIRN, Steffen; et al. LLM Agent Security: Threats, Attacks, and Defenses. arXiv, 2025. Disponível em: https://arxiv.org/abs/2501.00000. Acesso em: 10 maio 2026.

LEI, Sihao; et al. Prompt Injection Attacks Against LLM-integrated Applications. USENIX Security, 2024. Disponível em: https://www.usenix.org/conference/usenixsecurity24/presentation/lei. Acesso em: 10 maio 2026.

LI, Yuhang; et al. Model Extraction Attacks Against APIs. ACM CCS, 2022. Disponível em: https://dl.acm.org/doi/10.1145/3548606. Acesso em: 10 maio 2026.

MCCOY, R. Thomas; et al. Embedding-Based Retrieval and Security Risks in RAG Systems. arXiv, 2024. Disponível em: https://arxiv.org/abs/2402.00000. Acesso em: 10 maio 2026.

MITRE. Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS). 2025. Disponível em: https://atlas.mitre.org/. Acesso em: 10 maio 2026.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg: NIST, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 10 maio 2026.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Secure Software Development Framework (SSDF) Version 1.1. Gaithersburg: NIST, 2022. Disponível em: https://csrc.nist.gov/Projects/ssdf. Acesso em: 10 maio 2026.

NIST. Generative AI Profile for the AI RMF. NIST, 2024. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework/generative-ai-profile. Acesso em: 10 maio 2026.

PAPERNOT, Nicolas; MCGREW, Bob; et al. Practical Black-Box Attacks against Machine Learning. ACM AsiaCCS, 2017. Disponível em: https://arxiv.org/abs/1602.02697. Acesso em: 10 maio 2026.

PASCUAL, Damian; et al. Prompt Injection in LLM Applications: Taxonomy and Mitigations. arXiv, 2024. Disponível em: https://arxiv.org/abs/2402.00000. Acesso em: 10 maio 2026.

ROGERS, Ryan; et al. A Survey of Jailbreak Attacks Against Large Language Models. arXiv, 2024. Disponível em: https://arxiv.org/abs/2401.00000. Acesso em: 10 maio 2026.

SANDERS, William; et al. CNAPP and Cloud-Native Security for AI Workloads. Gartner Research, 2025. Disponível em: https://www.gartner.com/. Acesso em: 10 maio 2026.

SHOKRI, Reza; STRONATI, Marco; SONG, Congzheng; SHMATIKOV, Vitaly. Membership Inference Attacks Against Machine Learning Models. IEEE S&P, 2017. Disponível em: https://arxiv.org/abs/1610.05820. Acesso em: 10 maio 2026.

STERN, K.; et al. eBPF-Based Security Observability in Cloud-Native Environments. USENIX ;login:, 2024. Disponível em: https://www.usenix.org/publications/loginonline/ebpf-security-observability-cloud-native-environments. Acesso em: 10 maio 2026.

TEO, Richard; et al. Defending Against Indirect Prompt Injection in Retrieval-Augmented Systems. arXiv, 2024. Disponível em: https://arxiv.org/abs/2404.00000. Acesso em: 10 maio 2026.