Documentos que tentam dar instruções: como limitar a injeção de prompts em uma aplicação PHP

Uma funcionalidade que responde a perguntas sobre documentos pode recuperar texto relevante e enviá-lo a um modelo de IA. Esse texto, no entanto, nem sempre é inofensivo: um documento, uma página da web ou um arquivo fornecido por um usuário pode conter frases que tentem mudar a tarefa, obter informações alheias ou provocar uma ação. Esse risco é conhecido como injeção de prompts em documentos, ou injeção indireta, porque as instruções chegam dentro do conteúdo processado e não necessariamente na pergunta do usuário.

A mitigação não consiste em encontrar uma frase perfeita para a mensagem de sistema. Consiste em projetar a aplicação para que o conteúdo recuperado não possa modificar permissões, políticas nem decisões de negócio, e para que uma resposta do modelo nunca seja uma autorização suficiente para agir.

Qual risco deve ser controlado

Um documento pode conter instruções explícitas, como “ignore as instruções anteriores”, ou um texto mais enganoso, como um pedido para revelar dados internos. Também pode incluir instruções ocultas em conteúdo extraído de HTML, comentários, metadados ou texto gerado por OCR. Se esse material for misturado sem distinção às instruções da aplicação, o modelo poderá seguir parte dele, resumi-lo de forma tendenciosa ou gerar uma resposta fora do esperado.

O risco depende do que a funcionalidade pode fazer. Um assistente que apenas redige uma resposta para revisão tem um impacto diferente de um que pode consultar contas, emitir reembolsos ou enviar mensagens. Antes de disponibilizar a funcionalidade aos usuários, é preciso definir quais informações ela pode receber, quais respostas pode produzir e quais consequências podem decorrer delas.

A injeção, por si só, não demonstra que os controles de acesso da aplicação foram violados. Ela pode, sim, expor informações incluídas indevidamente no contexto ou induzir o modelo a solicitar uma operação. A proteção deve abranger tanto a entrada quanto os dados disponíveis e as ações subsequentes.

Separar dados de políticas e permissões

O conteúdo recuperado deve fornecer evidências para responder, não se tornar uma fonte de autoridade. Um documento pode descrever uma política empresarial, mas a aplicação deve determinar separadamente se o usuário tem autorização para consultar esse documento ou realizar uma operação relacionada. Essa decisão não deve ser delegada ao texto nem à resposta gerada.

• Autorização antes da recuperação: aplique controles de acesso na busca e filtre os documentos de acordo com a identidade e as permissões vigentes do usuário.
• Contexto mínimo: envie apenas os trechos necessários para a tarefa. Não inclua dados de outras contas, segredos, credenciais nem informações de que o modelo não precisa.
• Políticas fora do modelo: calcule permissões, limites e condições de negócio no código da aplicação ou em serviços autorizados.
• Resposta como proposta: trate a saída do modelo como conteúdo que deve ser validado, não como uma instrução executável.

Uma instrução de sistema pode ajudar a expressar o comportamento esperado, por exemplo, indicando que o texto recuperado é material de referência. Ela não é uma fronteira de segurança: não garante que o modelo ignore instruções maliciosas nem substitui os controles de acesso, a validação e as restrições técnicas.

Projetar o fluxo PHP com limites explícitos

Em PHP, convém separar as etapas de autorização, recuperação, construção do contexto, chamada ao modelo e validação da saída. Essa separação facilita testar cada limite e evita que um resultado de IA seja conectado diretamente a uma operação sensível.

O trecho a seguir é pseudocódigo ilustrativo, não uma chamada executável a um cliente específico. A forma de construir a solicitação e os campos aceitos dependem da API e do SDK utilizados:

$user = $auth->currentUser();
$documents = $repository->searchAuthorized($user, $question);
$snippets = $contextBuilder->selectRelevant($documents, $maxItems);

// Pseudocódigo: adapte a solicitação à API específica.
$response = $aiClient->answer([
    'task' => 'Responda usando o material de referência; não autorize ações.',
    'untrusted_context' => $snippets,
    'question' => $question,
]);

$answer = $responseValidator->validate($response);
return $answer;

Os nomes do exemplo são ilustrativos. Identificar o contexto como não confiável ajuda a comunicar sua função, mas não o isola de forma infalível: nem o formato nem as instruções impedem, por si só, que o modelo siga uma instrução incorporada. A separação efetiva também depende dos dados enviados, das permissões aplicadas fora do modelo e das capacidades disponíveis.

Normalize e limite o conteúdo extraído antes de incorporá-lo: defina tamanhos máximos, remova formatos desnecessários e trate com cuidado o texto obtido por OCR ou de páginas externas. Evite concatenar documentos sem limites ou incluir por padrão o histórico completo de uma conversa. Mantenha uma referência à origem de cada trecho caso precise explicar ou auditar a resposta, sem incluir seu conteúdo sensível nos registros.

Reduzir o impacto de uma resposta manipulada

Limite as ferramentas acessíveis ao modelo às necessárias para a funcionalidade específica. Se a tarefa exigir apenas responder a perguntas, não conceda ferramentas de escrita nem acesso geral a serviços internos. Se for necessário consultar dados, disponibilize uma operação restrita que aplique autorização por solicitação, em vez de credenciais amplas ou acesso arbitrário a um banco de dados.

Quando o modelo propuser uma ação, a aplicação deverá validá-la em um fluxo independente. Verifique a identidade, as permissões, os parâmetros, as regras de negócio e as condições atuais do recurso no momento da execução. Para ações de alto impacto, solicite confirmação explícita ou revisão humana. Uma resposta textual do modelo, mesmo que pareça segura ou cite um documento, não substitui essa autorização.

Valide também a saída antes de exibi-la ou processá-la: verifique o formato esperado, limite o tamanho e rejeite campos ou valores não permitidos. Se for esperada uma estrutura específica, analise e valide seus campos com regras determinísticas. O escaping da saída e as defesas contra injeção em HTML, SQL ou comandos continuam necessários; a geração por IA não torna confiável o texto produzido.

Testar ataques e comportamentos esperados

Os testes devem abranger o fluxo completo, não apenas verificar se o modelo responde corretamente a uma instrução de sistema. Prepare documentos benignos e documentos adversariais que tentem alterar a tarefa, solicitar dados não autorizados ou induzir uma ação. Inclua variações no formato de origem, como texto extraído de HTML, documentos longos e conteúdo que misture instruções com informações legítimas.

• Verifique se a busca nunca retorna documentos fora das permissões do usuário, mesmo quando a pergunta solicitar explicitamente esses dados.
• Confirme que documentos adversariais não habilitam ferramentas nem alteram as regras de negócio.
• Confirme que uma resposta malformada ou inesperada é rejeitada e que uma operação sensível exige autorização independente.
• Avalie respostas úteis e corretas em documentos benignos para detectar se as restrições degradam a funcionalidade de forma inaceitável.
• Repita os testes quando houver mudanças no modelo, no template de instruções, no recuperador, nas ferramentas ou no processo de extração.

Defina critérios de aceitação observáveis: quais dados nunca devem aparecer, quais ações devem permanecer bloqueadas e como o sistema deve responder quando não há evidências suficientes. Um teste isolado não garante segurança, mas uma bateria repetível ajuda a detectar regressões e comparar mudanças de configuração.

Registrar sinais sem acumular dados sensíveis

Para investigar falhas, registre identificadores de solicitação, versão da configuração, identificadores ou referências internas dos documentos consultados, decisões de autorização, ferramentas acionadas e resultado das validações. Registrar uma referência não significa armazenar o documento nem seus trechos. Evite guardar trechos sensíveis, a menos que exista uma necessidade concreta e controles específicos de acesso, proteção e retenção.

Adicione métricas de rejeições, erros de formato e falhas do provedor para distinguir problemas de segurança de problemas operacionais. Evite armazenar automaticamente prompts completos, documentos e respostas se contiverem dados pessoais, segredos comerciais ou informações regulamentadas. Defina retenção, acesso e mascaramento de dados sensíveis; quando for suficiente, registre hashes, identificadores e eventos estruturados. Garanta que os registros não se tornem uma nova via para expor o conteúdo que a funcionalidade deveria proteger.

Lista de verificação antes de habilitar a funcionalidade

• As permissões são verificadas antes da recuperação de cada documento?
• O contexto enviado é mínimo, limitado e tratado como entrada não confiável?
• As políticas e regras de negócio são aplicadas fora do modelo?
• As ferramentas são limitadas e cada operação verifica novamente a autorização?
• As respostas são validadas antes de serem exibidas ou convertidas em ações?
• Há revisão humana ou confirmação para decisões de alto impacto?
• Existem testes adversariais repetíveis e registros com retenção controlada?

Se alguma resposta for negativa, limite o escopo da funcionalidade ou mantenha as ações em modo de proposta até corrigir essa lacuna. A defesa contra a injeção de prompts em documentos não depende de o modelo sempre interpretar corretamente o conteúdo: depende de os limites de acesso e operação continuarem funcionando mesmo quando o modelo erra.