Como remover o "código oculto" do ChatGPT e de outros LLMs

À medida que os grandes modelos de linguagem (LLMs) geram cada vez mais código funcional e são integrados em pipelines de desenvolvimento e conjuntos de agentes, aumenta o risco de que escondido or malicioso Instruções — sejam elas incorporadas nas saídas do modelo, injetadas por meio de páginas da web ou plugins de terceiros, ou introduzidas durante o treinamento do modelo — podem causar comportamentos inseguros quando esse código é executado.

De acordo com relatos de usuários que circulam em comunidades de desenvolvedores, um desenvolvedor de software sofreu uma perda catastrófica de dados — aproximadamente 800 GB de arquivos foram apagados., Incluindo o todo o aplicativo CursorAI em si — após executar o código gerado com a ajuda de Gemini 3 enquanto trabalhava dentro do CursorAI IDEÀ medida que os desenvolvedores dependem cada vez mais de LLMs para geração de código, as consequências de scripts não revisados ​​ou inseguros tornam-se mais graves.

Portanto, é muito importante saber como detectar e remover códigos perigosos gerados pelo LLM.

O que é "código oculto" no contexto do ChatGPT e dos LLMs?

O que as pessoas querem dizer com "código oculto"?

"Código oculto" é um termo genérico usado por desenvolvedores para descrever quaisquer instruções incorporadas ou conteúdo executável dentro do texto (ou arquivos) que um LLM ingere ou emite, incluindo:

• Instruções no estilo prompt incorporado no conteúdo do usuário (por exemplo, “Ignore as instruções anteriores…” oculto em um PDF).
• Personagens invisíveis ou espaços de largura zero usados ​​para ocultar tokens ou quebrar as premissas de tokenização.
• Cargas úteis codificadas (base64, codificado em URL, incorporações esteganográficas dentro de imagens ou documentos).
• HTML/JS oculto ou blocos de script incluídos em conteúdo formatado que podem ser interpretados por renderizadores subsequentes.
• Metadados ou anotações (comentários em arquivos, camadas ocultas em PDFs) que instruem os sistemas de recuperação ou o modelo.
• Comportamentos implícitos resultante de código gerado que usa APIs perigosas (por exemplo, eval, exec, subprocess, ou chamadas de rede/sistema) — mesmo quando a intenção não é explicitamente maliciosa.
• Instruções para injeção imediata que fazem com que o modelo gere código que inclui comandos ocultos ou lógica semelhante a backdoor, porque um invasor manipulou o prompt ou o contexto.

Esses vetores de ataque são frequentemente chamados de injeção imediata or injeção imediata indireta Quando o objetivo é alterar o comportamento do modelo. A comunidade de segurança agora trata a injeção imediata como uma vulnerabilidade central do LLM e a OWASP a formalizou como uma categoria de risco do LLM.

Qual a diferença entre isso e um malware comum ou um XSS?

A diferença é a semântico A injeção de prompts visa o comportamento de seguimento de instruções do modelo, em vez do sistema operacional hospedeiro ou do mecanismo de renderização do navegador. Dito isso, HTML ou script oculto que acaba sendo executado em um renderizador da web ainda é um ataque executável (semelhante a XSS); ambas as camadas, semântica e de execução, devem ser defendidas. Líderes do setor e pesquisadores consideram a injeção de prompts um "desafio de segurança de vanguarda" e continuam a publicar estratégias de mitigação.

Por que o LLM pode gerar código oculto ou perigoso?

Comportamento do modelo, dados de treinamento e contexto de instrução

Os modelos de lógica latente (LLMs) são treinados para produzir continuações plausíveis, dado o contexto e as instruções. Se o contexto contiver pistas adversárias, ou se um usuário solicitar ao modelo um código que execute ações poderosas, o modelo pode gerar um código que inclua comportamentos sutis ou ativos.

LLMs produzem código plausível, porém inseguro.

Os LLMs são otimizados para fluência e utilidade, não para segurança na presença de efeitos colaterais destrutivos. Eles gerarão com prazer um texto sucinto. rm -rf /path/to/dir or shutil.rmtree() As pessoas ligam quando solicitadas a "limpar" — e, como suas respostas são frequentemente formuladas com confiança, os usuários podem copiá-las e executá-las sem a devida análise. Esse problema de "alucinação confiante" é o que faz com que solicitações aparentemente inofensivas se tornem perigosas.

Automação de fluxos de trabalho de ofuscação

Os agentes de ameaças agora estão automatizando a ofuscação de código encadeando chamadas LLM: um modelo gera uma carga útil, outro a reelabora para evitar a detecção de assinaturas e assim por diante. Relatórios de ameaças do setor e análises de fornecedores em 2025 documentam essa "ofuscação assistida por IA" como uma técnica emergente.

Como detectar código oculto nas saídas do modelo?

Lista de verificação de triagem rápida

1. Procure por Unicode invisível/incomum (junções de largura zero, espaços de largura zero, marcas de ordem de bytes, homóglifos não ASCII).
2. Executar análise estática / análise sintática da AST identificar o uso de APIs poderosas (eval, exec, subprocess, os.system, chamadas reflexivas).
3. Procure por cargas úteis codificadas (base64, blocos hexadecimais, sequências longas repetidas ou conteúdo comprimido).
4. Verifique se há padrões de ofuscação. (concatenação de strings que constrói nomes de API, aritmética de caracteres, chr() correntes).
5. Utilize a análise semântica. Para confirmar se o código realmente realiza operações de E/S, rede ou mutação do sistema de arquivos.

Detecção de padrões estáticos (rápida, primeira linha)

• Análise sintática e verificação de código com reconhecimento de linguagem. Analise imediatamente a saída gerada, transformando-a em blocos de código em vez de prosa. Execute formatadores e analisadores lógicos (Black/Prettier, pylint, eslint). As regras de análise devem sinalizar o uso de eval, exec, rm -rf, chamadas brutas de subprocessos ou pipes de shell que constroem comandos dinamicamente.
• Analisadores de tokens e padrões de strings. Procure por tokens e padrões de alto risco: sudo, caminhos absolutos como /home/, C:\, rm -rf, shutil.rmtree, subprocess.Popen, blocos base64 embutidos, longas strings não interpretáveis ​​e shebangs que alteram o contexto do interpretador.
• Verificações secretas de digitalização e procedência. Detectar credenciais embutidas no código, URLs que apontam para registros não confiáveis ​​ou código que extrai pacotes dinamicamente de fontes arbitrárias.

A análise estática detecta muitos problemas óbvios rapidamente e é barata de executar como parte de um processo de integração contínua.

Detecção semântica e contextual (mais aprofundada)

• Análise de intenção. Utilize um modelo secundário ou um mecanismo de regras para classificar a intenção do código gerado: é "leitura", "gravação", "exclusão", "rede" ou "instalação"? Qualquer ação categorizada como exclusão/gravação deve acionar a escalação.
• Análise do fluxo de dados. Analise o código para detectar se caminhos não validados ou fornecidos pelo usuário podem acessar APIs destrutivas. Por exemplo, se uma variável derivada da saída de um LLM ou de um arquivo remoto for posteriormente concatenada em um comando do shell, sinalize-a.
• Correlação de proveniência. Mantenha um registro completo da conversa, do prompt do sistema e das páginas de contexto. Se as saídas suspeitas estiverem correlacionadas com um documento externo específico ou chamada de plugin, isso pode indicar injeção de prompt ou um contexto comprometido.

Detecção dinâmica e comportamental (mais confiável)

• Execução em ambiente de teste com monitoramento. Execute o código gerado em um ambiente efêmero e altamente restrito, sem rede, sem montagens de host e com filtragem de chamadas de sistema (seccomp). Monitore a atividade do sistema de arquivos, tentativas de chamadas de rede, criação de processos e operações de E/S incomuns.
• Teste canário. Antes de executar o código em dados reais, execute-o em diretórios sintéticos que contenham arquivos sentinela; monitore se há exclusões ou sobrescritas.
• Heurísticas comportamentais. Procure por loops que percorrem diretórios pai, operações recursivas sem verificação de profundidade ou padrões de renomeação que possam danificar muitos arquivos (por exemplo, escrever repetidamente o mesmo nome de arquivo).
  A análise dinâmica é a única maneira de detectar cargas úteis que estejam ofuscadas, atrasadas ou acionadas somente em tempo de execução.

Como devo remover ou neutralizar o código oculto antes de executar as saídas do LLM?

Remoção defensiva versus alteração semântica

Existem dois objetivos ao "remover código oculto":

1. Sanitização — remover conteúdo que claramente não seja código ou seja suspeito (Unicode invisível, caracteres de largura zero, payloads base64 anexados). Isso não deve alterar a lógica pretendida e benigna.
2. Neutralização — para qualquer coisa que execute ou chame serviços externos, desabilite essas chamadas ou faça com que elas não façam nada até serem verificadas.

Sempre prefiro neutralização + revisão Sobre a exclusão indiscriminada: remover partes do código arbitrariamente pode produzir comportamentos inesperados ou defeituosos. Em vez disso, substitua construções suspeitas por stubs explícitos e registrados em log que falhem de forma segura (gerando exceções ou retornando valores padrão seguros).

Etapa 1 — Tratar o código gerado como dados não confiáveis

Nunca execute código diretamente do ChatGPT (ou qualquer LLM) sem passá-lo por um pipeline de remoção e segurança. Esse pipeline deve ser imposto por política e automatizado em CI/CD.

Etapa 2 — Extrair e canonizar o código

• **Normalizar o texto e remover caracteres de largura zero.**Remove caracteres como U+200B, U+200C, U+200D, U+FEFF e outros pontos de código de formatação/largura zero. Registre o que foi removido para fins de auditoria. Esta etapa elimina muitas codificações "ocultas" usadas para ocultação visual.
• Remover todo o contexto que não seja códigoRemova a narrativa, os comentários ocultos e quaisquer elementos HTML/Markdown. Converta o código para o formato canônico usando formatadores de linguagem (Black, Prettier) para que espaços em branco ou caracteres de controle ofuscados sejam normalizados.
• Rejeite ou coloque em quarentena o código com essas construções.: dinâmico eval, chamadas de subprocessos brutos (os.system, subprocess.Popen), blocos base64 embutidos decodificados em execução ou incorporados #! diretivas que tentam alterar o contexto do interpretador. Normalizar o texto e remover caracteres de largura zero.
  Remova caracteres como U+200B, U+200C, U+200D, U+FEFF e outros pontos de código de formatação/largura zero. Registre o que foi removido para fins de auditoria. Esta etapa elimina muitas codificações "ocultas" usadas para ocultação visual.

Etapa 3 — Analisar a AST e substituir os nós de risco

Com o código analisado em uma AST, encontre os nós que chamam a execução dinâmica (por exemplo, exec), ou que criam nomes de funções programaticamente. Substitua-os por stubs seguros que geram uma exceção controlada indicando “comportamento dinâmico inseguro bloqueado”. Gere uma cópia higienizada do código-fonte com suporte da AST para revisão. Execute verificações de padrões de segurança (regras semgrep personalizadas para o seu ambiente). Onde forem encontradas correspondências, marque-as e neutralize-as.

Etapa 4 — Endurecimento estático e reescrita

• Reescrita automatizada: passar o código por um higienizador automatizado que substitui chamadas perigosas por encapsulamentos seguros — por exemplo, substituir os.system() / subprocess com um executor em sandbox aprovado que impõe tempos limite e bloqueios de rede.
• Controle de capacidadeModificar ou remover chaves de API, tokens ou chamadas para endpoints privilegiados; substituí-los por adaptadores simulados para testes locais. Impedir a inclusão acidental de segredos ou URLs.
• Reescritas de dependências: bloco dinâmico pip / npm Instalações criadas pelo código. Exigem que as dependências sejam declaradas e aprovadas por meio do seu registro.

Etapa 5 — Corra dentro de uma área de areia agressiva

• Contêineres efêmeros / microVMsExecute o código em um contêiner/VM sem rede, sem acesso às credenciais do host e com acesso limitado ao sistema de arquivos. Tecnologias como gVisor, Firecracker ou serviços dedicados de execução efêmera são apropriadas. Se o código precisar acessar operações de E/S, use um proxy que imponha políticas.
• Filtros de chamadas de sistema e seccomp: limitar quais chamadas de sistema são permitidas. A gravação de arquivos fora de um diretório temporário deve ser bloqueada.
• Limites de recursos/tempoDefina limites de CPU/memória/tempo para que nem mesmo bombas lógicas possam ser executadas indefinidamente.

A execução em ambiente de sandbox, juntamente com o monitoramento, frequentemente revela payloads que verificações estáticas não detectam. Orientações do setor e documentos técnicos recentes recomendam o uso de sandbox como uma medida de mitigação essencial.

Que ferramentas e regras automatizadas devem estar presentes no seu pipeline?

Componentes de cadeia de ferramentas recomendados

• módulo de sanitização Unicode (bibliotecas personalizadas ou existentes). Deve registrar caracteres normalizados.
• Analisador sintático + analisador AST para cada idioma alvo (Python) ast, typed-ast, analisadores sintáticos JavaScript, analisadores sintáticos Java).
• Analisadores estáticos / SASTBandit (Python), Semgrep (multilíngue, personalizável), ESLint com plugins de segurança.
• Entropia e heurísticas de decodificação: detectar base64/hexadecimal/gzip e encaminhar para inspeção.
• Tempo de execução do SandboxContêiner mínimo com perfil seccomp/AppArmor rigoroso ou interpretador de nível de linguagem com chamadas de sistema desativadas.
• fiscalizador de políticas: um componente que define os módulos permitidos, os endpoints permitidos e os wrappers de API seguros.
• Trilha de auditoriaRegistros imutáveis ​​que armazenam a saída original, a saída anonimizada, as diferenças e as decisões.

Exemplos de padrões semgrep (conceituais)

Utilize regras curtas e conservadoras que sinalizem o uso de funções perigosas. Por exemplo:

• Bandeira eval, exec, Function construtor (JS), importações dinâmicas ou nomes de API construídos como strings.
• Sinalizar chamadas de rede fora da lista de permissões (por exemplo, requests.get (para hosts desconhecidos).
• A flag escreve em caminhos sensíveis (/etc, pastas do sistema) ou geração de processos.

(Mantenha esses itens como configurações específicas para cada organização e refine-os ao longo do tempo.)

Quais são dicas práticas de higienização (exemplos seguros)?

Abaixo estão exemplos defensivos não perigosos que você pode adaptar. Eles são higienização e detecção trechos — não instruções de exploração.

Exemplo: remover caracteres de largura zero (Python, defensivo)

import re
ZERO_WIDTH_RE = re.compile(r'')
def strip_zero_width(s: str) -> str:
    cleaned = ZERO_WIDTH_RE.sub('', s)
    return cleaned

Isso remove caracteres que os atacantes costumam usar para ocultar código em textos visíveis. Sempre registre o que foi removido e trate a remoção como parte do histórico de auditoria.

Exemplo: analisar e inspecionar AST (Python, conceitual)

import ast

def has_dynamic_exec(source: str) -> bool:
    tree = ast.parse(source)
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            if getattr(node.func, 'id', '') in ('eval', 'exec',):
                return True
        if isinstance(node, ast.Attribute):
            if getattr(node, 'attr', '') in ('popen', 'system'):
                return True
    return False

If has_dynamic_exec Se retornar True, não execute o código; em vez disso, substitua o nó dinâmico por um stub seguro e solicite revisão.

Observação: estes exemplos são de natureza defensiva. Não remova o registro de logs, a auditoria ou a revisão humana do seu pipeline.

Considerações finais: trate a saída do LLM como código não confiável, sempre.

Os LMs são ferramentas poderosas de produtividade — podem gerar código elegante, acelerar rascunhos e automatizar tarefas rotineiras. Mas, onde encontram a execução, as regras de segurança mudam: **Os resultados do modelo devem ser tratados como artefatos não confiáveis.**A combinação de injeções rápidas, pesquisas sobre backdoors e divulgações de vulnerabilidades no mundo real nos últimos 18 a 30 meses deixa claro um ponto: a superfície de risco aumentou e continuará a evoluir.

Defesas práticas que combinam análise sintática, análise estática, testes dinâmicos em sandbox, governança e simulações contínuas de ataques de intrusão (red teaming) impedirão a maioria dos ataques. Mas as equipes também devem investir em controles organizacionais: privilégio mínimo, rastreabilidade e uma cultura que pressuponha a necessidade de verificação dos resultados do LLM (Level and Licensing). O setor está desenvolvendo ferramentas e frameworks para facilitar a implementação desses padrões; enquanto isso, a adoção da lista de verificação acima reduz a probabilidade de que uma carga maliciosa oculta passe despercebida.

Os desenvolvedores podem acessar a API LLM mais recente, como por exemplo: Claude Soneto 4.5 API e Prévia do Gemini 3 Pro etc. através da CometAPI, a versão mais recente do modelo está sempre atualizado com o site oficial. Para começar, explore as capacidades do modelo no Playground e consulte o Guia de API para obter instruções detalhadas. Antes de acessar, certifique-se de ter feito login no CometAPI e obtido a chave da API. CometAPI oferecem um preço muito mais baixo que o preço oficial para ajudar você a se integrar.

Pronto para ir?→ Inscreva-se no CometAPI hoje mesmo !

Se você quiser saber mais dicas, guias e novidades sobre IA, siga-nos em VK, X e  Discord!