Injeção de Prompt como Confusão de Papéis
Ataques de injeção de prompt em grandes modelos de linguagem são cada vez mais vistos como consequência de “confusão de papéis”, em que os modelos inferem quem está falando (sistema, usuário, ferramenta, pensamentos internos) a partir do estilo de escrita, e não de metadados ou tags seguras. Comentaristas argumentam que os mecanismos atuais de marcação de papel e guardrails não fornecem nenhuma fronteira real de segurança, tornando fácil que prompts maliciosos ou saídas de ferramentas sobreponham políticas, especialmente em sistemas agentivos que podem tomar ações no mundo real. As mitigações propostas vão desde mudanças arquiteturais — como incorporar papel ou proveniência diretamente nas representações dos tokens e separar estritamente dados de controle — até um design de sistema mais conservador que coloque LLMs em sandbox, limite-os a tarefas de baixo risco e trate toda saída do modelo como não confiável.
Confusão de papéis e a natureza da injeção de prompt
- Muitos comentadores concordam que o artigo formaliza algo que os praticantes já sabiam: LLMs não têm “papéis” verdadeiros; tudo são apenas tokens em um único fluxo.
- O modelo infere “quem está falando” a partir do estilo e da posição, e não de tags seguras. Isso torna “falar como o sistema” uma tática poderosa de jailbreak.
- Vários comparam isso à engenharia social: se você fala no tom de autoridade, o modelo o trata como tal.
Ideias para sinalização de papéis mais robusta
- Várias pessoas sugerem “colorir” tokens: adicionar dimensões extras de embedding ou vetores modificadores codificando papel (system/user/tool/CoT) por token, de forma análoga a embeddings posicionais.
- Variantes incluem:
- Duplicar tokens para chain-of-thought interno.
- Embeddings de segmentos instrucionais e IDs de origem por token.
- Usar metadados explícitos de canal lateral em vez de tags no próprio fluxo.
- Outros observam desafios: necessidade de dados de treinamento rotulados, entrelaçamento de tópico/origem e risco de degradar o desempenho do modelo.
Segurança, sandboxing e limites dos LLMs como componentes seguros
- Há forte consenso: LLMs atuais não fornecem nenhuma fronteira real de segurança; papéis em APIs são formatação, não autorização.
- Alguns argumentam que qualquer sistema que permita a um LLM tomar ações irreversíveis é inerentemente inseguro; outros dizem que usos restritos e em sandbox (por exemplo, classificação, detecção de spam) são aceitáveis.
- Discute-se isolamento de sessão: modelos são, em princípio, stateless, mas o tratamento do contexto/cache KV e bugs de sessão web ainda podem vazar dados.
- Memória persistente de agentes é destacada como especialmente arriscada: instruções injetadas podem ser “lavadas” em notas “autoria própria” e se tornar altamente confiáveis depois.
Por que a sanitização clássica e as tags ficam aquém
- Comentaristas perguntam por que não simplesmente remover ou reforçar as tags. Respostas:
- APIs modernas muitas vezes já usam tokens especiais não falsificáveis para limites de papel.
- O problema central é que os modelos inferem papéis a partir do estilo; mesmo sem tags, texto do usuário que pareça chain-of-thought ou política do sistema pode sobrepor instruções.
- Benchmarks estáticos para injeção de prompt são criticados; red-teaming humano que adapta os ataques é muito mais eficaz.
Reflexões mais amplas e ceticismo
- Alguns acham que o rótulo “teoria” é exagerado; outros dizem que ele merece esse termo por fazer previsões testáveis e sugerir दिशões de pesquisa.
- Há uma preocupação recorrente de que tornar modelos “seguros” via treinamento tende a reduzir fortemente a utilidade, mas ainda assim não impede totalmente jailbreaks.