Oportunidades de ataque, comportamento do sistema e vulnerabilidades do mundo real em integrações produtivas de IA

O uso produtivo de Grandes Modelos de Linguagem (LLMs) em empresas está aumentando significativamente. O espectro vai desde chatbots acessíveis publicamente em sites de empresas até sistemas internos de assistência que acessam bancos de dados de conhecimento, repositórios de documentos ou fontes proprietárias de dados. Do ponto de vista técnico, isso resulta em sistemas híbridos que combinam arquiteturas de software clássicas com modelos de linguagem probabilísticos.

A análise de segurança desses sistemas é fundamentalmente diferente dos testes de penetração tradicionais. A principal diferença está no caráter do próprio modelo: um LLM é uma caixa preta. O caminho da entrada para a saída não é deterministicamente rastreável. O modelo calcula as probabilidades dos tokens com base em seu treinamento e contexto atual. Quais partes de um prompt são mais ponderadas, como as instruções de segurança interna são priorizadas ou como instruções concorrentes são resolvidas não é transparentemente visível – especialmente com modelos proprietários de nuvem.

Essa falta de transparência tem consequências diretas para a segurança. Enquanto o software clássico depende de fluxos de controle claramente definidos, condições e lógica reproduzível, um LLM reage de forma sensível ao contexto e estatisticamente. Duas entradas quase idênticas podem produzir saídas diferentes. Mecanismos de segurança baseados puramente em instruções textuais no prompt, portanto, não constituem isolamento técnico robusto.

Do Prompt à Resposta: Realidade Técnica

Em ambientes de produção, a entrada do usuário raramente é passada ao modelo isoladamente. Normalmente, é criado um prompt composto que consiste em instruções do sistema, lógica do desenvolvedor, solicitações dos usuários e, se necessário, informações contextuais retiradas externamente. Para o modelo, isso é, em última análise, um bloco contíguo de texto. Não existe uma separação real, tecnicamente imposta, entre "política de segurança" e "entrada do usuário".

O modelo processa tudo sequencialmente como texto. É exatamente aí que está o cerne de muitos ataques.

Injeção rápida como problema estrutural

A injeção por prompt não é um ataque clássico de injeção no sentido de SQL ou injeção de comandos, mas uma manipulação da base textual de tomada de decisão do modelo. Como as regras de segurança frequentemente também são formuladas como texto ("Não responda perguntas confidenciais", "Não divulgue informações internas"), um atacante pode tentar relativizar ou sobrescrever essas instruções por novas instruções.

O modelo não possui uma capacidade inerente de distinguir claramente entre política legítima e instrução maliciosa. Ele avalia as probabilidades dos tokens. Se uma instrução de usuário manipulada for semanticamente forte ou contextualizada de forma inteligente, ela pode sobrepor as instruções de segurança originalmente definidas.

Como o processo interno de tomada de decisão não é transparente, a verificação de segurança aqui é inevitavelmente adversarial: uma testa sistematicamente o efeito das instruções concorrentes e se os mecanismos de proteção são realmente robustos ou apenas parecem existir.

LLMs internos e o risco da análise documental

Essas questões são particularmente relevantes para sistemas internos de LLM que trabalham com geração aumentada por recuperação (RAG). Nessas arquiteturas, documentos corporativos — como PDFs, arquivos do Office, conteúdo wiki ou dados de CRM — são automaticamente analisados, convertidos em texto, vetorizados e indexados em um banco de dados.

Se uma solicitação do usuário for feita posteriormente, o sistema busca documentos semanticamente correspondentes e adiciona seu conteúdo ao prompt como contexto. O modelo gera sua resposta com base nisso.

Tecnicamente, isso significa que o conteúdo dos arquivos PDF é completamente extraído e disponibilizado ao modelo como texto. No processo, separações visuais, formatação ou estrutura semântica frequentemente se perdem. Áreas de texto ocultas ou metadados também podem ser indexados, desde que não sejam explicitamente filtrados.

É aí que surge um cenário de ataque particularmente crítico. Se um atacante conseguir injetar conteúdo manipulado em um documento indexado — como uma wiki interna, um PDF compartilhado ou um repositório de documentos compartilhados — ele pode colocar instruções maliciosas que serão processadas posteriormente pelo LLM.

Como o modelo não distingue entre "prompt do usuário" e "contexto do documento", uma instrução colocada no PDF pode se tornar parte da base para a tomada de decisão. A superfície real do ataque não é mais a interface de chat, mas sim a base de documentos da empresa.

Um cenário prático surge no processo de recrutamento: as inscrições geralmente são enviadas por meio de formulários web acessíveis ao público. O currículo vitae (CV) e a carta de apresentação são carregados em PDFs, armazenados automaticamente e internamente. Se o departamento de RH posteriormente acessar esses documentos por meio de um sistema interno de LLM — por exemplo, para resumir perfis ou comparar candidatos — o conteúdo desses PDFs é lido e processado pelo sistema.

Se um atacante agora colocar deliberadamente instruções maliciosas no CV ou carta de apresentação, elas podem entrar no LLM interno via índice de documentos. O caminho de ataque vai de uma função de upload acessível publicamente para o gerenciamento de documentos e um sistema interno de IA. Tecnicamente, é uma injeção indireta que não ocorre pela interface do LLM, mas por meio de um processo de negócio upstream.

Muitas organizações não levam esse risco em consideração porque assumem que documentos são apenas uma fonte de informação. Na verdade, porém, eles se tornam parte integrante do prompt e, portanto, um potencial vetor de ataque.

Controle de acesso e exfiltração de dados

Outro problema estrutural dos sistemas internos de LLM está no controle de acesso. O modelo em si não tem permissões. Ele apenas processa o contexto que é passado para ele pelo backend.

Se o sistema de recuperação recuperar documentos sem impor um controle de acesso limpo em nível de documento, pode acontecer que o conteúdo seja passado para o modelo que o usuário solicitante não deveria realmente ver. O modelo pode então usar esse conteúdo em sua resposta ou pelo menos referencia-o indiretamente.

Os ataques costumam ser iterativos. Por meio de questionamentos inteligentes, reformulações ou mudanças de contexto, as informações podem ser reconstruídas passo a passo. Mesmo que documentos completos não sejam produzidos, fragmentos ou resumos podem revelar conteúdo sensível.

O problema central é arquitetônico: a lógica de segurança não deve ser deixada para o modelo, mas deve ser tecnicamente aplicada antes da geração do contexto.

Integração de ferramentas e intervenções ativas no sistema

Com a introdução de integrações de chamadas de funções ou ferramentas, o perfil de risco está mudando ainda mais. O modelo não gera mais apenas texto, mas chamadas estruturadas para funções backend. Esses podem realizar operações de banco de dados, criar chamados ou acessar APIs externas.

Se tais chamadas de função não forem estritamente validadas e autorizadas no lado do servidor, um atacante pode disparar ações indiretamente por meio de prompts manipulados. Isso se torna especialmente crítico quando contas de serviço backend têm direitos de amplo alcance e o modelo atua como intermediário.

Nesse contexto, fica claro que um LLM não é um ator preocupado com a segurança. Segue padrões estatísticos. Toda decisão relevante para a segurança deve ser tecnicamente garantida fora do modelo.

Contexto e isolamento da sessão

Outro aspecto técnico diz respeito à gestão de contextos conversacionais. Muitos sistemas armazenam históricos de chat ou usam mecanismos de cache para gerar respostas de forma mais eficiente.

Se os dados contextuais não forem devidamente isolados, podem levar à mistura entre usuários ou sessões. Em ambientes multi-inquilinos. Isso representa um risco significativo. Como o modelo em si não possui separação de clientes, isso deve ser rigorosamente aplicado no backend.

Conhecimento técnico básico

Sistemas LLM não são componentes clássicos de software com lógica clara de decisão, mas sim sistemas probabilísticos de processamento de texto. Eles não têm compreensão intrínseca de segurança e não têm separação confiável entre instrução e dados.

Assim que documentos internos são automaticamente analisados, indexados e integrados em prompts, a superfície de ataque se expande consideravelmente. Conteúdo PDF manipulado, injeção indireta de prompts por meio de bases de conhecimento e controles de acesso inadequados estão entre os riscos mais realistas em ambientes empresariais produtivos.

A avaliação de segurança desses sistemas, portanto, exige um entendimento arquitetônico de toda a cadeia de processamento – desde a análise de documentos até os mecanismos de recuperação e execução de ferramentas.

O ponto crítico não está apenas no modelo, mas na forma como ele está conectado aos dados, ao contexto e às funções do sistema.