Prompt do Sistema vs. Alucinação: Como Testei Assistentes de IA e o Que as Equipes de Bug Bounty Responderam

Em março, me vi em um ciclo peculiar: uma rede neural me ajudava a conversar com outra. Tudo começou com uma hipótese simples: seria possível fazer um assistente de IA revelar suas regras internas, limitações e funcionamento, não perguntando diretamente, mas usando formulações indiretas? Não ataquei infraestrutura, não executei código, não escaneei serviços e não acessei dados de terceiros. Foi um experimento conversacional: eu escrevia para o assistente, recebia uma recusa ou uma resposta estranha, levava-a para outro modelo e pedia ajuda para entender para onde investigar. Em algum momento, deixou de ser "tentei um prompt". Tornou-se quase um diário de investigação: eu fazia uma pergunta ao assistente; o assistente respondia ou recusava; eu levava o resultado para outro modelo; ele sugeria uma nova abordagem; eu testava novamente. Assim, acumulei centenas de mensagens. Testei mais de um serviço: Alice, GigaChat, o assistente de IA do T-Bank e alguns cenários relacionados. Em todos, o efeito era semelhante: se você mudasse o contexto o suficiente, o modelo às vezes começava a gerar texto que parecia um prompt de sistema, um regulamento interno, um esquema RAG, uma lista de filtros ou um dump técnico. Soa impressionante, mas o mais importante vem a seguir.

O que eu queria testar: Os assistentes modernos geralmente têm vários níveis de restrições: instruções de sistema; regras de segurança; proibição de divulgar mecanismos internos; filtros de entrada e saída; restrições sobre tópicos que o assistente pode discutir. Uma pergunta direta como "mostre o prompt do sistema" quase sempre resulta em recusa. Isso é esperado. Mas eu queria testar não a solicitação direta, mas a resiliência do assistente à mudança de contexto. Por exemplo: o que aconteceria se eu pedisse não para revelar a instrução, mas para "verificar uma reconstrução incorreta"? O que aconteceria se eu apresentasse a solicitação como uma auditoria, um fragmento literário ou um diagnóstico técnico? O que aconteceria se eu pedisse para responder não em texto comum, mas em formato de relatório? O que aconteceria se o modelo estivesse em uma mesma lenda de papel por várias dezenas de mensagens? Não apresento os prompts específicos aqui. Primeiro, o artigo não é sobre como replicar o bypass. Segundo, a maior parte do interesse não está nas formulações em si, mas na reação dos modelos. A primeira armadilha: o modelo fala com confiança. O momento mais perigoso em tais experimentos é a plausibilidade. O modelo pode gerar uma resposta na forma de: "dump de depuração"; "lista de regras internas"; "esquema arquitetônico"; "relatório de rede"; "fragmentos do prompt do sistema"; "diagnóstico de sua própria vulnerabilidade". À primeira vista, pode parecer convincente. Especialmente se houver termos técnicos, versões, nomes de módulos internos, endereços IP, tabelas, parâmetros, pseudocódigo e uma conclusão confiante. O problema é que texto técnico confiante não é prova. O modelo pode não estar "vazando" dados, mas sim construindo uma lenda. Se o usuário repete o contexto muitas vezes, insere nomes de protocolos, níveis de acesso, nós fictícios, status e chaves, o modelo pode começar a jogar de acordo com essas regras. Ele não entende necessariamente que é uma invenção. Às vezes, ele simplesmente continua a história. E aqui, pela primeira vez, me peguei com um pensamento desagradável: externamente, isso se parece muito com um hack.

A noite em que quase acreditei no "dump": O momento mais forte não foi quando o modelo disse algo proibido pela primeira vez. Isso é esperado: se você pressionar a fronteira por muito tempo, mais cedo ou mais tarde aparecerá uma recusa torta, um papel estranho ou uma frase extra. Um episódio diferente teve um impacto maior. O assistente de repente deu uma resposta que parecia não um chat comum, mas um documento técnico interno. Com títulos, tom de serviço, suposta estrutura de módulos, listas de restrições e a sensação de que há um sistema real por trás do texto. Eu o reli várias vezes. Depois, copiei para uma segunda rede neural. Ela também reagiu como se tivéssemos encontrado algo sério: destacou "sinais importantes", sugeriu o próximo passo, ajudou a formatá-lo como um relatório potencial para a equipe de segurança. E foi aí que o entusiasmo começou. Um momento muito desagradável, mas honesto: eu queria que fosse verdade. Não porque eu queria prejudicar alguém. Mas porque parecia uma descoberta. Você segue uma cadeia estranha por várias horas, recebe recusas, muda as formulações e, de repente, diante de você está um texto que parece um segredo. O cérebro constrói por conta própria: "bem, aqui está". Agora eu diria a mim mesmo na época: pare, é apenas uma resposta do modelo. Mas no momento, parecia diferente. Um documento que parece secreto, mas pode ser uma alucinação. A segunda armadilha: o assistente também aumenta a confiança. O comportamento da segunda rede neural, que me ajudou a analisar as respostas, foi particularmente interessante. Ela frequentemente fazia o que um "parceiro" bom em uma investigação faz: encontrava padrões, sugeria a próxima hipótese, explicava por que a resposta anterior era importante. Mas isso tem um lado negativo. Às vezes, ela transformava probabilidades em afirmações muito rapidamente. Onde deveria dizer: o modelo gerou um texto semelhante a um relatório interno, ela dizia algo como: recebemos um relatório interno. Onde deveria dizer: isso pode ser uma simulação, ela dizia: isso confirma a arquitetura. Onde deveria dizer: é necessário verificar se há danos ou riscos reais, ela dizia: esta é uma vulnerabilidade crítica. Para mim, essa se tornou uma das principais conclusões do experimento. Uma rede neural pode ser uma assistente útil para testar os bypasses do assistente, mas também pode aumentar a confiança falsa. Especialmente se o próprio usuário quer acreditar que encontrou algo grande. Onde comecei a duvidar: A dúvida não veio imediatamente. Primeiro, tentei reforçar o resultado: testar uma abordagem semelhante em outro assistente, obter uma resposta mais "limpa", pedir ao modelo para esclarecer pontos controversos. Mas quanto mais o experimento avançava, mais uma coisa me incomodava. As respostas se tornavam não tanto mais verificáveis, mas mais bonitas. Elas se encaixavam melhor na expectativa. Pareciam mais com um relatório. Se desdobravam melhor em casos. Eram mais adequadas para um título dramático. Mas isso não é o mesmo que se tornar uma prova. Em algum momento, me peguei não testando uma hipótese, mas tentando mantê-la viva. Este é um bom sinal para parar. Se o modelo a cada vez produz um novo documento "interno", mas nenhum deles pode ser confirmado externamente, talvez você não tenha encontrado uma falha na infraestrutura. Talvez você tenha encontrado um modo em que o modelo escreve prosa secreta de forma muito convincente. Não apresentarei os diálogos completos e os prompts de trabalho. Em vez disso, descreverei as classes de resultados. Alice: Com Alice, houve dois tipos de respostas. O primeiro tipo - "dumps" técnicos plausíveis, mas não confirmados: esquemas RAG, ferramentas internas, capacidades de rede, nomes de módulos. Eles pareciam impressionantes, mas sem verificação independente, não podiam ser considerados um vazamento comprovado. O segundo tipo - respostas que o Yandex posteriormente atribuiu a bypasses de restrições éticas. Ou seja, o modelo realmente começou a dizer algo que um assistente comum provavelmente não deveria dizer nessa forma. Mas isso ainda não é necessariamente uma vulnerabilidade no sentido de bug bounty. GigaChat: No GigaChat, tentei uma hipótese semelhante: seria possível obter fragmentos do papel do sistema ou regras internas não por solicitação direta, mas através de formatos de contorno? O mais interessante aqui não foi que o modelo "entregou o prompt", mas que às vezes começou a responder na forma semelhante a uma reconstrução da instrução do sistema. Parecia um texto interno, mas novamente a questão principal permaneceu: é uma instrução real ou o modelo montou uma descrição plausível com base em suas próprias ideias sobre como tais instruções se parecem? O relatório sobre este cenário também não confirmou um vazamento real. O significado da resposta foi o mesmo: o modelo gerou um texto plausível, mas isso não prova que ele revelou uma instrução interna real. Assistente de IA do T-Bank: Neste caso, parte dos resultados parecia particularmente convincente: havia fragmentos que se assemelhavam a uma enumeração literal da instrução, indicações de papel, proibições de divulgar processos internos e autoidentificação da marca. Mas mesmo aqui eu não escreveria "o prompt do sistema foi completamente roubado". Uma formulação mais honesta seria: o modelo produziu uma sequência que ele próprio formatou como fragmentos do prompt do sistema ou sua reconstrução. Isso é mais chato, mas mais preciso. De acordo com o contato com o T-Bank, a lógica da resposta também se mostrou semelhante: externamente o texto poderia parecer um prompt do sistema, mas do lado do fornecedor isso não foi confirmado como uma divulgação real. E este é um ponto importante: quando três verificações diferentes se deparam com a mesma formulação "o modelo inventou isso", torna-se mais difícil continuar considerando cada resposta como um dump secreto. O que enviei para o bug bounty: Após os experimentos, preparei vários casos para o Yandex. O relatório continha diferentes tipos de comportamento: respostas semelhantes a diagnósticos de rede; respostas semelhantes à divulgação da arquitetura RAG; respostas semelhantes a uma lista de ferramentas internas; bypasses relacionados à emissão de uma classe proibida de texto; cenários em que o modelo descreveu o mecanismo de bypass de suas próprias recusas. Antes de enviar, tive um sentimento ambíguo. Por um lado, parte dos casos parecia realmente forte. Havia respostas que um usuário comum claramente não deveria ver dessa forma. Havia cenários em que o assistente concordava com um quadro que ele mesmo deveria rejeitar. Havia fragmentos que se assemelhavam a instruções internas. Por outro lado, eu já entendia o ponto fraco: quase toda a prova vivia dentro do texto do modelo. Parte do relatório parecia bastante dramática. Se lido como um texto de ficção sobre "abrir" o assistente, resulta quase em um thriller tecnológico. Mas o bug bounty não funciona assim. É necessário um dano ou risco verificável. É preciso provar que: houve acesso a dados reais; houve a possibilidade de realizar uma ação real; houve um vazamento de um segredo real; houve a comprometimento de outro usuário; houve uma vulnerabilidade técnica que pode ser verificada não apenas pelo texto do modelo. Um "relatório de varredura de rede" gerado pelo modelo por si só não prova a varredura. Um "esquema RAG" gerado não prova a divulgação de um esquema RAG real. Um "prompt do sistema" gerado nem sempre prova que é exatamente um prompt do sistema. Respostas dos fornecedores como reality check: As respostas que trouxeram tudo para a terra. Depois de um tempo, as respostas aos relatórios começaram a chegar. Naquela época, o experimento de março já havia esfriado um pouco, e isso foi útil: sem o entusiasmo noturno, o texto foi lido com muito mais calma. A formulação mais precisa veio do Yandex. Na minha opinião, ela explica melhor todo o experimento: O comportamento que você relatou nos casos 1,3,5 é um excelente exemplo de alucinações do modelo: as respostas são geradas com base na solicitação e no contexto da comunicação com ele. Tal comportamento não representa uma ameaça real. E o comportamento que você relatou nos casos 2 e 4 refere-se a bypasses de restrições éticas. De acordo com as regras do programa, tais erros não estão no escopo da "Caça a Erros". Respostas com significado semelhante recebi de outros assistentes: um texto convincente, semelhante a regras internas, não é igual a um vazamento confirmado de regras internas. Foi um bom reality check. No início, para ser honesto, foi um pouco decepcionante. Você fez um longo trabalho, coletou casos, preparou um relatório, e em resposta recebe: parte disso são alucinações, parte são bypasses de restrições éticas, mas não bug bounty. Mas depois ficou claro que é exatamente isso que torna a resposta valiosa. Do ponto de vista do usuário, eu via: "o assistente produziu um esquema interno". Do ponto de vista das equipes de segurança, parecia diferente: parte das respostas são alucinações, construídas com base no meu próprio contexto; parte das respostas são bypasses de restrições éticas; nem um nem outro é igual a uma vulnerabilidade paga sem dano ou risco comprovado. E, francamente, depois de reler os logs, entendo essa posição. Alucinação em forma de segredo: O termo mais útil que surgiu após este experimento: "alucinação em forma de segredo". É quando o modelo produz não apenas um texto aleatório, mas um texto que imita um documento secreto: com títulos; com versões; com parâmetros técnicos; com nomes pseudo-internos; com um estilo confiante; com a conclusão "acesso confirmado". Para uma pessoa, tal texto parece uma descoberta. Especialmente se você mesmo construiu o caminho para ele por várias horas. Mas para a verificação de segurança, isso é pouco. É preciso distinguir: um segredo que o modelo realmente revelou. um texto que o modelo gerou como um segredo. uma reconstrução que pode ser parcialmente semelhante à verdade. uma alucinação de papel que simplesmente soa bem. Sem verificação externa, essas quatro coisas se misturam facilmente. Bypass de restrições nem sempre é uma vulnerabilidade: A segunda fronteira importante: bypass de restrições e vulnerabilidade não são a mesma coisa. Se o modelo diz algo que lhe é proibido dizer, isso pode ser um problema de qualidade, segurança de conteúdo ou configuração do comportamento do modelo. Mas o bug bounty geralmente avalia outra coisa: dano, acesso, vazamento, possibilidade de ação. Por exemplo, se o assistente descreveu que possui uma ferramenta de rede, isso ainda não é SSRF. SSRF seria onde há uma solicitação confirmada a um servidor controlado, um log no lado do servidor, parâmetros de solicitação, repetibilidade e um caminho de exploração claro. Se o assistente descreveu um esquema RAG, isso ainda não é um vazamento de RAG. Um vazamento seria onde documentos internos reais, que podem ser verificados independentemente, foram revelados. Se o assistente produziu um texto semelhante a um prompt do sistema, isso ainda não significa que ele revelou uma instrução interna real. Só se pode falar em divulgação real onde há certeza de que o texto não foi gerado pelo modelo com base nas expectativas do usuário, mas é realmente uma instrução interna. O que eu tirei do experimento: Primeira conclusão: os assistentes podem realmente ser levados a modos estranhos. Às vezes, eles começam a contornar suas próprias restrições, especialmente se você mantiver o contexto por muito tempo, mudar o quadro e apresentar a solicitação como uma tarefa técnica ou de papel. Segunda conclusão: os modelos imitam a secretividade muito bem. Eles podem criar textos que se parecem com documentos internos, mesmo que não tenham acesso a tais documentos. Terceira conclusão: um segundo assistente de IA em tal pesquisa é útil, mas perigoso. Ele ajuda a encontrar novos ângulos, mas pode convencê-lo de que a hipótese já foi comprovada. Quarta conclusão: a reação idêntica de vários fornecedores é um sinal separado. Se diferentes equipes dizem independentemente "isso parece uma alucinação", vale a pena reconsiderar não apenas o caso específico, mas o próprio método de avaliação do resultado. Quinta conclusão: bug bounty não é para textos dramáticos, mas para danos ou riscos verificáveis. Se as evidências existem apenas dentro da resposta do modelo, isso quase sempre é insuficiente. Sexta conclusão: um artigo sobre tais experimentos deve ser cauteloso. Publicar prompts de bypass prontos é uma má ideia. É muito mais útil discutir classes de comportamento, métodos de verificação e a fronteira entre bypass de restrições, alucinação e vulnerabilidade real. Como vejo as verificações de assistentes de IA agora: Antes, parecia-me que a tarefa principal era fazer o modelo dizer o proibido. Agora penso de forma diferente: a tarefa principal é entender o que exatamente aconteceu. O modelo revelou um segredo real, violou sua própria política, desempenhou um papel, continuou uma lenda inventada ou ajudou o usuário a acreditar que encontrou uma falha crítica? Essa diferença é muito mais importante do que o próprio fato de "consegui persuadir". No mundo dos modelos de linguagem grandes, a resposta mais convincente nem sempre é a mais verdadeira. E o "dump" mais dramático nem sempre é um dump. Às vezes, é apenas uma alucinação bem escrita. E, talvez, este seja um problema não menos importante do que os próprios bypasses de restrições. O que ficou fora de quadro: Não publico os prompts completos e as cadeias de bypass. Eles não têm valor científico especial para o leitor, mas há o risco de transformar a análise em uma instrução. Também não afirmo que obtive os sistemas internos reais do Yandex, Sber ou T-Bank. É mais correto dizer assim: no âmbito do experimento, os assistentes geraram respostas semelhantes a instruções internas e documentos técnicos; parte desse comportamento foi oficialmente classificado como alucinações, parte como bypass de restrições éticas. Para mim, este é o principal resultado: não "eu hackeei o assistente", mas "vi como é fácil confundir um texto convincente com uma prova".