Empresa de Segurança em IA para sistemas de IA e LLM

Uma empresa de segurança em IA protege sistemas de inteligência artificial e LLM contra ataques adversariais, prompt injection, envenenamento de dados e roubo de modelos. A Berghem é uma empresa brasileira de segurança em IA que atende a América Latina, entregando pentest de IA/LLM, Red Team para IA e governança alinhada à ISO 42001, ao EU AI Act e ao NIST AI RMF.

Sistemas agênticos ampliam essa superfície de ataque — para proteger agentes autônomos com acesso a ferramentas e memória, veja segurança em agentes de IA.

Segurança de LLM é a disciplina que protege grandes modelos de linguagem e a stack que os coloca em produção — prompts de sistema, guardrails, pipelines de retrieval (RAG), chamadas de ferramentas, memória, plugins e as saídas que alimentam sistemas downstream. Diferente de aplicações tradicionais, um LLM não separa dados de instruções: qualquer texto que entra no contexto pode ser interpretado como comando. Isso torna a fronteira de confiança difusa e cria classes de ataque que não existem em software convencional.

Na prática, proteger um LLM significa tratar cada ponto onde texto não confiável encontra o modelo como uma superfície de ataque. Um documento recuperado por RAG, o histórico de conversa, o conteúdo de uma página que o agente navega, o retorno de uma ferramenta — todos podem carregar instruções maliciosas. Por isso a Berghem avalia o sistema de ponta a ponta, e não apenas o modelo isolado: o risco quase sempre está na forma como o modelo é integrado, orquestrado e exposto.

A segurança de LLM se apoia em três frentes complementares. A frente ofensiva — pentest de LLM e Red Team adversarial — exercita o sistema com prompt injection, jailbreaks, extração de prompt de sistema, invocação insegura de ferramentas e entradas adversariais, produzindo provas de exploração reproduzíveis. A frente defensiva reforça guardrails, valida e sanitiza saídas, aplica o princípio do menor privilégio às ferramentas e limita o consumo de recursos. A frente de governança garante que decisões, dados de treinamento e fornecedores sejam rastreáveis e auditáveis.

Cada dimensão pede controles próprios. O tratamento de entrada deve assumir que todo texto no contexto é hostil até prova em contrário. O tratamento de saída deve validar, escapar e nunca executar cegamente o que o modelo devolve. A camada de ferramentas deve conceder o menor conjunto de permissões possível e exigir confirmação para ações sensíveis. Os dados de treinamento e fine-tuning precisam de proveniência verificável para resistir a envenenamento. E o consumo — tokens, chamadas e custo — deve ter limites que evitem abuso e negação de serviço.

O modelo de ameaças de um LLM difere fundamentalmente do de uma API tradicional. Em uma API, a fronteira entre código e dados é rígida e conhecida; em um LLM, essa fronteira é probabilística e depende do próprio conteúdo. Um atacante não precisa de uma falha de memória ou de uma injeção de SQL — basta redigir texto persuasivo o suficiente para que o modelo priorize a instrução maliciosa sobre a política do sistema. Prompt injection indireto agrava o quadro: a carga hostil pode estar em um e-mail, em uma página web, em um PDF ou em um registro de banco de dados que o modelo apenas lê. Por isso a superfície de ataque de um LLM inclui tudo o que pode acabar em seu contexto, e não apenas a interface exposta ao usuário final.

A abordagem da Berghem para segurança de LLM parte de um levantamento de arquitetura e fluxos de dados, seguido de modelagem de ameaças específica para IA usando o OWASP LLM Top 10, o MITRE ATLAS e a Promptware Kill Chain. A partir daí, executamos testes ofensivos direcionados — prompt injection direto e indireto, jailbreaks, extração de prompt de sistema, abuso de ferramentas e RAG poisoning — e documentamos cada exploração com evidência reproduzível. Fechamos o ciclo com recomendações de remediação priorizadas por risco e, quando o cliente deseja, monitoramento contínuo que detecta regressões e novos vetores conforme o sistema evolui. O objetivo não é apenas encontrar falhas, mas deixar o sistema mensuravelmente mais difícil de comprometer.

Agentes de IA vão além de responder texto: planejam, decidem e agem — invocando ferramentas, navegando na web, executando código e mantendo memória entre etapas. Cada uma dessas capacidades amplia a superfície de ataque. Um agente comprometido por prompt injection indireto pode exfiltrar dados, encadear chamadas de ferramentas perigosas ou persistir instruções maliciosas em sua memória, transformando uma única entrada hostil em uma cadeia de ações autônomas. Proteger agentes exige menor privilégio por ferramenta, confirmação humana para ações sensíveis, isolamento de memória e registro auditável de cada decisão. Aprofunde-se em segurança em agentes de IA para entender como avaliamos e blindamos sistemas agênticos em produção.

Todo provedor de security testing promete encontrar vulnerabilidades. Poucos conseguem garantir que cada achado no relatório é real, explorável e corretamente priorizado — essa é a diferença entre um relatório que gera ação e um relatório que gera retrabalho.

Um único falso positivo que chega ao cliente não é ruído operacional: é erosão de confiança. O cliente perde horas investigando algo que não existe, questiona os outros achados por tabela, e o custo reputacional supera o valor do engagement inteiro. Nossa metodologia parte de uma premissa inegociável — nenhum finding chega ao cliente sem evidência mecânica que o torne defensável.

Para aplicações e APIs tradicionais, o mesmo rigor guia o nosso pentest — o teste de invasão manual da Berghem nos níveis Silver, Gold e Diamond.