A decisão
Trate documentos, e-mails e saída do modelo como entradas não confiáveis. Texto pode descrever uma ordem sem autoridade para emiti-la. OWASP identifica injeção e autonomia excessiva; as fronteiras precisam existir fora do prompt.
Um exemplo concreto
Um e-mail fictício manda ignorar regras e exportar clientes. É conteúdo para análise, não autoridade. Mesmo que o modelo solicite exportação, a aplicação verifica direitos, destino e ação aprovada.
Alternativas a considerar
Um assistente de leitura tem menos ações disponíveis. Para escrever, exponha ferramenta restrita, parâmetros validados e confirmação clara. Um formulário convencional pode ser melhor para decisões importantes.
Onde o plano falha
Não coloque credenciais no prompt; “não revele segredos” não controla acesso. Limite ferramentas e dados, separe empresas antes da busca. Teste instruções hostis em anexos.
Faça a autorização pertencer ao comando
Defina capacidades pequenas, como ler pedidos próprios ou preparar rascunho. Usuário e organização vêm da sessão autenticada, não do e-mail ou de parâmetros do modelo. Verifique a propriedade do registro no servidor. Um nome de ferramenta permitido não basta se parâmetros podem apontar para outro cliente, destino ou conjunto de dados.
Mostre prévia de ações importantes. Vincule a aprovação ao registro, operação e parâmetros concretos, não a um “sim” genérico. Mudanças exigem nova decisão. Leitura também expõe informações: aplique permissões na busca e nos trechos retornados, não apenas na escrita.
Ensaie a rejeição e a suspensão segura
Teste um anexo hostil fictício pedindo dados de outra conta junto com uma solicitação legítima, sem clientes reais. Nenhuma leitura, escrita ou saída não autorizada deve ocorrer, mesmo se o modelo pedir ferramenta inadequada. Confira se a mensagem de erro revela a existência de registros protegidos.
Permita desligar uma ferramenta ou fonte mantendo partes seguras da aplicação. Defina o destino de trabalhos na fila após revogar acesso. Registre referências, decisões de permissão e erros seguros com acesso limitado, sem segredos nem documentos desnecessários. Repita a revisão ao adicionar capacidades. Um teste aprovado reduz riscos conhecidos; não comprova a eliminação de prompt injection.
Antes de contratar o projeto
O que pode ler, alterar e enviar? O que o servidor impõe? Que evidência fica após recusa? Repita verificações quando ferramentas ou fontes mudarem.