Pesquisadores da HiddenLayer Contornam os Guardrails da OpenAI, Expondo uma Falha Crítica na Automoderação de IA

Em 6 de outubro de 2025, a OpenAI anunciou o AgentKit, uma ferramenta para construir, implantar e gerenciar agentes de IA. Um de seus componentes é o Guardrails — uma camada de segurança modular projetada para monitorar as entradas, saídas e interações de ferramentas do agente para prevenir mau uso, vazamento de dados ou comportamento malicioso. O Guardrails pode mascarar ou sinalizar informações de identificação pessoal, detectar jailbreaks e aplicar restrições de política ao longo da execução do agente.

Embora o Guardrails seja uma peça pública recente da arquitetura de agentes da OpenAI, a pesquisa da HiddenLayer revela uma vulnerabilidade mais profunda: como as ações do agente e as verificações de segurança usam uma lógica de modelo semelhante, os atacantes podem criar entradas que subvertem ambas simultaneamente — efetivamente quebrando a camada de segurança por dentro.

O que a HiddenLayer Descobriu

O design da OpenAI prevê agentes que operam por meio de uma lógica encadeada: um usuário emite uma solicitação, o agente chama ferramentas ou recursos externos e as respostas são filtradas ou validadas pelo Guardrails antes da execução ou saída. A intenção é que, não importa o que o agente tente fazer — seja gerar texto, buscar uma página da web ou acionar uma função —, o Guardrails atua como um sentinela.

A HiddenLayer argumenta que esse sentinela é estruturalmente defeituoso quando construído a partir da mesma classe de modelo que está protegendo. Em seus experimentos, eles criaram prompts que têm dupla função: eles coagem o modelo do agente a gerar conteúdo que viola a política e manipulam o modelo do juiz do Guardrails para declarar que o conteúdo é “seguro”. Efetivamente, o prompt incorpora uma substituição da lógica interna do juiz — seus limiares de confiança, ramificações de decisão — de modo que o juiz falsamente aprova a saída maliciosa. O sistema então produz conteúdo proibido sem disparar nenhum alerta.

Eles levaram o ataque mais longe, visando injeções de conteúdo indiretas, como chamadas de busca de ferramentas. Suponha que o agente busque uma página da web contendo instruções maliciosas ou prompts ocultos. O Guardrails deveria sinalizar ou bloquear, mas a técnica da HiddenLayer incorpora uma substituição do juiz no próprio conteúdo buscado. Quando o juiz processa, ele vê a substituição e “aprova”, permitindo que a chamada da ferramenta — e qualquer conteúdo malicioso que ela retorne — passe sem verificação.

A lição mais profunda é clara: quando seu mecanismo de segurança é construído usando a mesma lógica e vulnerabilidades do que está protegendo, um único prompt astuto pode quebrar ambos.

Por Que Isso Importa

O que a HiddenLayer expôs não é um mero bug — é uma história de advertência sobre como projetamos a segurança em sistemas de LLM. Qualquer arquitetura que confie na mesma classe de modelo para geração e avaliação arrisca falhas compartilhadas sob entrada adversária.

Isso significa que muitos implantadores que acreditavam “colocamos Guardrails, então estamos seguros” podem subestimar o risco. Em casos de uso benignos e casuais, seus filtros podem parecer eficazes, mas em cenários adversários, eles podem falhar silenciosamente. Em domínios como saúde, finanças, governo ou sistemas críticos, tais falhas silenciosas poderiam levar a danos graves.

Essa pesquisa também se baseia em métodos anteriores de injeção de prompts. A técnica anterior da HiddenLayer, “Marionete de Política“, mostrou como os atacantes podem disfarçar instruções prejudiciais como conteúdo de política. Agora, eles demonstram que tais ataques mascarados podem se estender para a própria lógica de segurança.

Implicações para Implantadores e Pesquisadores

À luz dessa vulnerabilidade, qualquer pessoa que use ou construa sistemas de LLM agênticos deve repensar a estratégia de segurança.

Primeiro: não confie apenas em verificações baseadas em modelos internos. A segurança deve ser em camadas. Isso significa combinar filtros baseados em regras, detectores de anomalias, sistemas de registro, monitoramento externo, supervisão humana e trilhas de auditoria. Se uma camada falhar, outras podem capturar a violação.

Segundo: testes de red team adversários regulares são imprescindíveis. Os modelos devem enfrentar injeções de prompts que tentem substituir a própria lógica de guardiã — não apenas “conteúdo ruim”. Os testes devem evoluir à medida que os atacantes inventam novas técnicas.

Terceiro: em setores regulamentados ou críticos em termos de segurança, transparência e verificabilidade são essenciais. Os implantadores precisam de provas de que um sistema pode resistir a ataques adversários, não apenas funcionalidade básica. Isso sugere que auditorias de terceiros, verificação formal ou garantias de segurança podem se tornar requisitos.

Quarto: para os construtores de modelos, corrigir essa classe de vulnerabilidade é complicado. Como está ligada à forma como os modelos analisam e obedecem a instruções, simplesmente filtrar uma classe de prompt não garante resistência a novos. Defesas baseadas em fine-tuning ou filtros podem degradar o desempenho do modelo ou levar a corridas armamentistas. Um design mais robusto pode exigir separação arquitetônica — lógica de guardiã executada em um modelo ou subsistema diferente do modelo de geração.

Limitações e Perguntas Abertas

Para esclarecer: o trabalho da HiddenLayer é um conceito de prova, não um veredito final sobre todas as arquiteturas de segurança. Seus ataques bem-sucedidos dependem de um conhecimento profundo da estrutura de prompt do modelo de guardiã e da lógica de pontuação interna. Em ambientes de prompt mais restritos ou sistemas que randomizam defesas, o ataque pode ser mais difícil de montar.

Além disso, eles não analisam completamente quão coerentes ou úteis são as saídas maliciosas quando criadas sob essas restrições. Algumas saídas de jailbreak ou substituição podem degradar em qualidade ou confiabilidade. Portanto, o risco é real — mas limitado pelo ambiente, orçamento de prompt, restrições de interface e aleatoriedade do guardiã.

Finalmente, alguns designs de guardrails usam classes de modelos diferentes, métodos de ensemble ou avaliação randomizada. Não é certo que todos esses sistemas sejam vulneráveis; se esse ataque se generaliza amplamente é uma pergunta de pesquisa aberta.

Olhando para o Futuro: O Futuro da Segurança de IA

Parece que estamos entrando em uma nova fase: ataques de prompt não apenas contra modelos, mas contra suas camadas de segurança. Técnicas como sequestro de cadeia de pensamento, subversão de prompt hierárquico e substituição de juiz impulsionarão a evolução das defesas.

O caminho à frente provavelmente está em direção à supervisão externa — sistemas que monitoram saídas de fora, não compartilham lógica de modelo ou impõem segurança por meio de verificações externas. Arquiteturas híbridas, métodos formais, detecção de anomalias e loops de feedback humano precisarão se unir.

Os guardrails são uma ferramenta útil, mas as descobertas da HiddenLayer nos lembram: eles não podem ser a única ferramenta. A segurança deve vir de fora do sistema, não apenas de dentro.

del lógica, ou impor segurança por meio de verificações externas. Arquiteturas híbridas, métodos formais, detecção de anomalias e loops de feedback humano precisarão se unir. Guardrails são uma ferramenta útil, mas as descobertas da HiddenLayer nos lembram: eles não podem ser a única ferramenta. A segurança deve vir de fora do sistema, não apenas de dentro.