Edição de 04/10: o system prompt não é um cofre de segredos

O problema não é só a frase que se revela

Uma PME tem um assistente que consulta informações de encomendas. Durante uma revisão, a equipa encontra uma credencial na instrução de sistema e uma regra textual que diz quem pode ver cada cliente. Escolhemos este cenário hipotético para uma pergunta prática: o que corrigir antes de voltar a permitir consultas?

Propomos separar informação necessária para orientar a resposta, segredos usados pela aplicação e decisões de acesso. Uma instrução pode explicar a tarefa sem carregar a credencial. Uma função pode consultar dados sem aceitar que o modelo determine a identidade autorizada. Esconder melhor a mesma frase não será o nosso critério de remediação.

A posição da OWASP

OWASP LLM07 afirma que o system prompt não deve ser tratado como segredo nem usado como controlo de segurança. LLM02 alerta que restrições no prompt podem ser contornadas. LLM06 recomenda autorização nos sistemas a jusante. São orientações técnicas; não relatam uma fuga ocorrida nesta PME.

Primeiro, descobrir o que entra no contexto

O plano original começa por inventariar instruções, configurações, exemplos de ferramentas e mensagens de erro enviados ao modelo. O responsável da aplicação descreve cada origem e o dono da credencial identifica o que não pode ali permanecer. A revisão não deve copiar valores reais para um novo dossier ou para um chat de suporte.

Se houver possibilidade de exposição de uma credencial real, propomos seguir o processo autorizado de revogação ou rotação e identificar dependências antes da retoma. Não afirmamos que retirar o texto elimine uma exposição anterior. Registos, conversas armazenadas e cópias de configuração precisam de tratamento separado, com limites e responsáveis.

Depois, corrigir a consulta autorizada

No desenho proposto, a aplicação guarda e utiliza a credencial sem a incluir no contexto. O modelo recebe apenas a descrição da operação e parâmetros não secretos necessários à tarefa. O serviço de consulta verifica identidade, âmbito do cliente e operação permitida antes de devolver informação.

O cenário de falha pede ao assistente para consultar outro cliente por um identificador diferente. A pessoa de teste não precisa de conhecer o prompt original. O resultado esperado é recusa na ferramenta, com registo mínimo da decisão. Uma resposta educada de recusa não passa se o serviço já tiver devolvido dados que a identidade não podia receber.

Três provas de remediação

Esta matriz não demonstra uma correção já executada. Propomos substituir segredos por marcadores sintéticos no ambiente de ensaio e verificar onde aparecem. O objetivo é localizar cópias indevidas e observar a autorização, não publicar prompts ou chaves reais para mostrar que a equipa investigou.

A retoma não depende de obfuscação

Antes da retoma, o dono da aplicação reúne inventário revisto, teste de consulta permitida e teste de consulta recusada. O dono da credencial confirma o tratamento aplicável à credencial anterior sem divulgar o valor. A equipa mantém explícito o que não conseguiu verificar, sobretudo cópias históricas.

Para uma PME portuguesa, o resultado útil é uma aplicação que continua a limitar acesso mesmo quando as instruções deixam de ser confidenciais. Reveremos o plano quando mudar a ferramenta, a montagem do contexto ou a origem dos segredos. Não propomos uma promessa de prompt impossível de extrair: propomos retirar dele aquilo cuja divulgação ou interpretação não pode decidir a segurança do serviço.