04/10 edition: the system prompt is not a secret vault

The problem is not merely the disclosed phrase

An SME has an assistant querying order information. During review, the team finds a credential in the system instruction and a textual rule stating who may see each customer's data. We select this hypothetical scenario for a practical question: what should be corrected before allowing queries again?

We propose separating information needed to guide answers, secrets used by the application and access decisions. An instruction can explain the task without carrying the credential. A function can query data without accepting the model as the authority on identity. Concealing the same phrase more effectively will not be our remediation criterion.

OWASP's position

OWASP LLM07 states that the system prompt should not be treated as a secret or used as a security control. LLM02 warns that prompt restrictions can be bypassed. LLM06 recommends downstream authorisation. These are technical guidelines, not reports of a leak at this SME.

First, discover what enters context

The original plan starts by inventorying instructions, configuration, tool examples and error messages sent to the model. The application owner describes each origin; the credential owner identifies what cannot remain there. Review should not copy real values into another dossier or support chat.

If exposure of a real credential is possible, we propose following the authorised revocation or rotation process and identifying dependencies before resumption. Removing text does not establish that previous exposure has disappeared. Logs, stored conversations and configuration copies need separate handling with stated limits and owners.

Then correct the authorised query

In the proposed design, the application stores and uses the credential without including it in context. The model receives only the operation description and non-secret parameters required for the task. The query service checks identity, customer scope and permitted operation before returning information.

The failure scenario asks the assistant to query another customer using a different identifier. The tester does not need to know the original prompt. The expected result is refusal at the tool with a minimal decision record. A polite refusal in the answer fails acceptance if the service already returned data the identity was not allowed to receive.

Three remediation checks

This matrix does not demonstrate an executed correction. We propose replacing secrets with synthetic markers in the trial environment and checking where they appear. The objective is to locate inappropriate copies and observe authorisation, not publish real prompts or keys as proof that the team investigated.

Resumption does not depend on obfuscation

Before resumption, the application owner collects the revised inventory, permitted-query test and refused-query test. The credential owner confirms applicable treatment of the previous credential without disclosing its value. The team explicitly records what it could not verify, particularly historical copies.

For a Portuguese SME, the useful result is an application that still limits access when its instructions are no longer confidential. Review this plan when tools, context assembly or secret origins change. We do not promise a prompt that cannot be extracted: we propose removing anything whose disclosure or interpretation must not determine service security.