A tua IA obedece a ordens.
Garante que são as tuas.

Red teaming e hardening para aplicações LLM, agentes de IA e a infraestrutura que os suporta — por engenheiros que também constroem e operam sistemas de IA em produção.

De confiança em toda a Europa

Setores que servimos.

Equipas de engenharia em setores regulados e críticos — cada projeto auditado, documentado e levado a nível de produção.

Banca e pagamentos

FinTech

Infraestrutura de pagamentos e core bancário em conformidade com PCI-DSS — latência p99 abaixo de 100 ms, registo de auditoria ponta a ponta e tokenização no edge.

PCI-DSS · ISO 27001
Dados de doentes

Saúde

Pipelines de dados de doentes alinhados com HIPAA

HIPAA · SOC2
5G e redes

Telecomunicações

Observabilidade do core 5G à escala

NFV · ETSI MANO
Retalho e marketplaces

E-Commerce

99,99% de disponibilidade em picos de tráfego

PCI-DSS · GDPR
Soberano e público

Governo

Cloud soberana com registo de auditoria completo

eIDAS · FIPS 140-2
Frotas e IoT

Logística

Rastreio de frotas em tempo real e ingestão IoT

MQTT · OPC-UA
10Categorias de risco do OWASP Top 10 para LLM cobertas
15+Anos a construir e proteger sistemas em produção, desde 2011
24/7Monitorização e resposta a incidentes
ATLASAchados mapeados no MITRE ATLAS

O que entregamos

Segurança de IA, de ponta a ponta

Do prompt à GPU: a aplicação, o agente, o modelo, os dados e a plataforma onde tudo corre.

Testamos a aplicação à volta do modelo como um atacante faria: prompt injection direta, injeção indireta escondida em documentos, páginas web e respostas de ferramentas, jailbreaks, fuga do system prompt, output do modelo que chega a HTML, SQL ou a uma shell sem validação e exfiltração de dados através do modelo — incluindo imagens e links markdown que enviam dados para o servidor de um atacante. O OWASP Top 10 para aplicações LLM é o ponto de partida, não o teto.

OWASP Top 10 para aplicações LLM · injeção direta e indireta

Um agente é tão seguro quanto aquilo que lhe é permitido fazer. Definimos o seu âmbito, aplicamos o privilégio mínimo a cada ferramenta e conector — servidores MCP, function calling, tokens de API —, exigimos aprovação humana para as ações sensíveis, isolamos a execução de código num sandbox e tratamos o conteúdo que o agente lê (emails, tickets, páginas web) como não confiável, para que uma instrução escondida nele não consiga desencadear uma ação sensível sem aprovação — e testamos que assim é.

Ferramentas com privilégio mínimo · MCP · aprovação humana

Testes adversariais a modelos e aplicações de IA: contorno de guardrails, extração de dados de treino, abuso de ferramentas, conteúdo proibido e respostas erradas dadas com toda a confiança onde os utilizadores vão agir com base nelas. Funciona como um pentest com técnicas próprias — e como o output do modelo não é determinístico, cada ataque é repetido e reportado com a frequência com que tem sucesso.

Mapeado no MITRE ATLAS · transcrições reproduzíveis

Os modelos e os datasets são código que não escreveste. Verificamos a sua proveniência e integridade: pesos descarregados de hubs públicos, ficheiros pickle que podem executar código ao serem carregados (passamos-te para safetensors sempre que possível), datasets envenenados, dependências de ML vulneráveis, assinatura de artefactos e quem pode publicar ou descarregar do teu registo de modelos.

Proveniência · safetensors · artefactos assinados

Os dados sensíveis nunca deviam chegar por acidente ao treino, ao fine-tuning ou à recuperação. Revemos o que entra em cada etapa, aplicamos controlo de acesso por documento no RAG para que o assistente só recupere o que o utilizador pode ver, protegemos os vector stores e os embeddings, e mantemos os dados pessoais fora dos logs de prompts.

Acesso por documento no RAG · vector stores · RGPD

Segurança cloud e de Kubernetes aplicada a cargas de IA: clusters de GPU, endpoints de inferência, notebooks expostos, pipelines de MLOps e os segredos que transportam — incluindo as API keys dos fornecedores de modelos. O mesmo hardening de plataforma que aplicamos aos sistemas em produção, adaptado à forma como as equipas de ML trabalham de facto.

Kubernetes · endpoints de inferência · gestão de segredos

Controlos que continuam a funcionar depois do lançamento: filtros de input e output, deteção de abuso, limites de pedidos e de gastos contra o denial of wallet, registo de cada interação com o modelo e de cada chamada a ferramentas, e um playbook de resposta a incidentes de IA para que a tua equipa saiba o que fazer quando um jailbreak se torna público.

Filtros de input e output · rate limiting · resposta a incidentes de IA
Avaliação gratuita

Pede uma avaliação gratuita de Segurança de IA

Os nossos engenheiros analisam a tua configuração atual e entregam um roteiro priorizado — sem compromisso.

Quem ajudamos

Equipas que levam a IA para produção

As quatro situações em que uma revisão de segurança de IA se paga mais depressa.

Equipas a lançar uma funcionalidade com LLM

Estás prestes a pôr um chatbot, um copiloto ou uma pesquisa com IA à frente dos teus clientes. Fazemos-lhe red teaming antes do lançamento, para que o primeiro jailbreak seja o nosso e não uma captura de ecrã nas redes sociais.

Empresas a implementar agentes de IA

Os teus agentes leem emails, tickets ou páginas web e podem agir no teu CRM, no teu código ou na tua cloud. Delimitamos o que podem fazer, reduzimos as suas permissões ao mínimo e testamos se um conteúdo hostil consegue tomar o controlo.

Organizações com copilotos internos

Construíste um assistente RAG sobre contratos, processos de RH ou a wiki da empresa. Verificamos que só recupera o que cada utilizador pode ver e que nada sensível é exposto através dos prompts ou dos logs.

Equipas de ML que treinam ou alojam modelos

Fazes fine-tuning ou alojas modelos open-weight nas tuas próprias GPU. Protegemos a cadeia de abastecimento, os pipelines, os notebooks e os endpoints de inferência à volta deles.

Âmbito do red teaming de IA

Atacamos o sistema de IA completo

O modelo é apenas um componente. Testamo-lo em conjunto com o system prompt, a camada de recuperação, as ferramentas que pode chamar e o que a tua aplicação faz com o seu output — é aí que acontecem os incidentes reais. Cada achado inclui transcrições, uma taxa de sucesso e uma correção.

  • Prompt injection direta e indireta
  • Jailbreaks e contorno de guardrails
  • Fuga do system prompt
  • Exfiltração de dados através do modelo e das suas ferramentas
  • Extração de dados de treino e de RAG
  • Agência excessiva e abuso de ferramentas
  • Tratamento inadequado do output (XSS, injeção de SQL e de comandos através do output do modelo)
  • Revisão da cadeia de abastecimento de modelos
  • Denial of wallet e abuso de recursos
Resultados e método

Segurança para sistemas que recebem instruções

A segurança aplicacional clássica assume que o código faz aquilo para que foi escrito. Um LLM faz aquilo que o seu input o convence a fazer — por isso os controlos têm de assumir que, mais cedo ou mais tarde, uma injeção vai passar. Desenhamos para esse cenário e testamos que o desenho aguenta.

Business outcomes
  1. 01

    Exposição conhecida antes do lançamento

    Vês como o teu sistema de IA falha sob ataque antes dos teus clientes ou dos atacantes, com cada achado reproduzível.

  2. 02

    Danos limitados por desenho

    O privilégio mínimo, as portas de aprovação e os controlos de saída limitam o que uma injeção bem-sucedida consegue alcançar.

  3. 03

    Evidências para auditorias e clientes

    Os achados mapeados no OWASP e no MITRE ATLAS dão suporte aos questionários de segurança, à ISO/IEC 42001 e aos requisitos de robustez e cibersegurança do EU AI Act para sistemas de risco elevado.

How we implement
  1. 01

    Âmbito e modelo de ameaças

    Mapeamos os modelos, os prompts, as fontes de dados, as ferramentas e os utilizadores, e construímos um modelo de ameaças com o MITRE ATLAS.

  2. 02

    Ataque

    Red teaming manual apoiado em testes automatizados, contra a aplicação, o agente e a infraestrutura por baixo.

  3. 03

    Relatório

    Achados com transcrições, taxas de sucesso e severidade, mapeados no OWASP Top 10 para aplicações LLM e no MITRE ATLAS.

  4. 04

    Reforço

    Corrigimos em conjunto com a tua equipa: permissões, guardrails, regras de acesso a dados, controlos de pipeline e de infraestrutura.

  5. 05

    Re-teste e monitorização

    Voltamos a correr os ataques contra as correções e configuramos logs e alertas para o que acontece em produção.

Modelo de colaboração

Como trabalhamos

Da primeira chamada à produção — um modelo de colaboração comprovado em 4 passos que mantém a conversa transparente e a velocidade honesta.

  1. 01

    Descoberta

    Auditamos o teu stack atual, identificamos lacunas e alinhamos os objetivos de negócio.

  2. 02

    Avaliação

    Um roteiro detalhado com prioridades, estimativas de esforço e quick wins.

  3. 03

    Implementação

    Os nossos engenheiros integram-se na tua equipa e executam sprint a sprint.

  4. 04

    Suporte

    Monitorização contínua, otimização e transferência de conhecimento para a tua equipa.

Dúvidas habituais

Perguntas frequentes

Respostas práticas sobre âmbito, prazos e como costumam ser os projetos com a nossa equipa de Segurança de IA.

Um pentest clássico procura falhas no código, na configuração e na autenticação — uma vulnerabilidade existe ou não existe. Num sistema de IA, a linguagem natural é a superfície de ataque: o mesmo prompt pode resultar uma vez em cada dez, a carga pode chegar dentro de um documento que o modelo lê e a correção raramente é um único patch. Continuamos a testar a camada clássica — a API, a autenticação, a cloud por baixo — porque uma aplicação de IA também é uma aplicação web. Além disso, testamos o comportamento do modelo, as suas ferramentas e os seus dados com as técnicas catalogadas no MITRE ATLAS e no OWASP Top 10 para aplicações LLM.
Não, e quem o promete está a vender demais. Os modelos atuais recebem instruções e dados pelo mesmo canal, por isso nenhum filtro consegue distingui-los de forma fiável. O que funciona é a defesa em profundidade que assume que, mais cedo ou mais tarde, uma injeção vai ter sucesso: tratar o output do modelo como não confiável, dar às ferramentas o menor privilégio possível, exigir aprovação humana para as ações com consequências, separar o conteúdo confiável do não confiável, fechar os caminhos de exfiltração como os pedidos de saída e as imagens renderizadas, e monitorizar o abuso. Os filtros e classificadores reduzem a taxa de sucesso; a arquitetura limita os danos. Testamos as duas coisas.
Sim. A maioria das aplicações de IA é construída assim, e o risco costuma estar na tua aplicação e não no modelo do fornecedor: o system prompt, a camada de recuperação, as ferramentas que o modelo pode chamar e o que o teu código faz com o seu output. Testamos a tua aplicação e a tua integração — não os modelos nem a infraestrutura do fornecedor — e mantemo-nos dentro das suas políticas de utilização. Os achados que dependem do comportamento do modelo devem ser verificados de novo sempre que mudares de modelo ou de versão.
Partimos do que o agente deve poder fazer, não do que consegue fazer. Cada ferramenta e cada servidor MCP recebe as suas próprias credenciais com o âmbito mínimo; as ações de escrita e eliminação, os pagamentos e as mensagens de saída exigem aprovação humana; a execução de código corre num sandbox sem acesso a segredos nem à rede interna. Revemos os servidores MCP como qualquer dependência de terceiros — as descrições das ferramentas podem trazer instruções escondidas e um servidor pode alterar a definição das suas ferramentas depois de as teres aprovado —, por isso fixamos versões e mantemos uma lista de permitidos do que pode ser instalado. Depois testamos se o conteúdo que o agente lê consegue tomar o controlo das suas ações.
Um sumário executivo com o risco global, o âmbito e o método, e cada achado com a sua severidade, os prompts ou cargas exatos utilizados, as transcrições e com que frequência o ataque teve sucesso em tentativas repetidas — o output do modelo não é determinístico, por isso uma única captura de ecrã não é evidência. Cada achado está mapeado no OWASP Top 10 para aplicações LLM e no MITRE ATLAS e inclui uma correção concreta: uma alteração de permissões, um guardrail, uma regra de acesso a dados ou uma alteração de arquitetura.
Sim. Depois de aplicares as correções, voltamos a correr os mesmos ataques — as mesmas cargas, repetidas o mesmo número de vezes — e reportamos as novas taxas de sucesso ao lado das originais. Como uma atualização do modelo, uma ferramenta nova ou uma alteração ao system prompt podem reabrir um problema fechado, também podemos transformar o conjunto de ataques numa suite de regressão que corre no teu pipeline de CI/CD antes de cada release.
Fala com os nossos engenheiros

Vamos falar sobre a tua estratégia de Segurança de IA

Quer estejas a começar do zero ou a escalar o que já tens, os nossos engenheiros estão prontos para ajudar.

Segurança de IA e red teaming de LLM | Privum Consulting