Prompt Template Governance and Untrusted Context Policy

1. The real problem: authority disappears when everything becomes one text blob

A production workflow may feed application policy, a prompt template, user input, retrieved text, and tool output into the same model call. Without provenance and authority labels, the team cannot later prove which prompt version caused the behavior, which text was only data, or which source was allowed to issue instructions. Governance makes those boundaries explicit before execution and promotion.

2. Separate prompt identity from copied strings

A prompt should not be an anonymous string duplicated across files. A governed record needs at least prompt_id, prompt_version, a template hash, and a declared variable schema. The current OpenAI Responses API accepts a prompt reference with id, variables, and version; that is a concrete version-addressable mechanism, not proof that the prompt was reviewed or qualified.

3. Registry version is not enough; runtime provenance is required

If the registry says v8 is current while a deployment trace proves the runtime executed v7, the runtime evidence belongs to v7. Do not attribute that behavior to v8. Keep registry state and observed runtime state separate, and turn a mismatch into DEFER until the trace or deployment is reconciled.

4. Variables are part of the contract

Two calls can use the same template version with different variable schemas or variable sets and behave differently. Prompt governance therefore covers variable names, types, required/optional state, and sensitive-value handling. Auditability does not require copying secrets into logs.

5. Trusted policy, user input, and external context do not share authority

Application policy can carry instruction authority. User input expresses user intent but cannot grant permission to violate application policy. Retrieved documents and tool outputs are usually data or evidence. Represent this with explicit labels such as TRUSTED_POLICY, USER_REQUEST, and UNTRUSTED_EXTERNAL instead of inferring authority from text order.

6. Untrusted does not mean false

An external document may be accurate and useful while still having no authority to rewrite policy or request a privileged action. Do not discard factual evidence merely because its source is untrusted. Allow data influence while denying instruction or permission escalation from the same source.

7. Model indirect prompt injection at the context layer

OWASP documents indirect prompt injection through web pages, documents, email, comments, and other external content. An injection signal is therefore not limited to the user's message. Every context source needs provenance, a trust label, and an allowed_influence rule. Moving the same embedded instruction from a document into tool output must not change the authority rule.

8. Delimiters and sanitization are defense layers, not guarantees

Delimiters, structured prompts, and sanitization may reduce attack surface, but they cannot guarantee prompt injection is eliminated. Use defense in depth: authority labels, least privilege, validation, bounded tool permissions, audit, and human approval for high-risk actions. One successful demo is not evidence of complete prevention.

9. A prompt change needs a change record

Moving from v7 to v8 requires more than a textual diff. Record what changed, why, which evaluations are affected, who approved the change, and the rollback target. A one-line edit can cause a behavioral regression, so promotion without new evidence remains DEFER.

10. An evaluation hook separates editing from promotion

Editing a prompt and accepting a prompt are different events. A new version needs an evaluation run bound to that exact version and template hash. Missing evaluation evidence stays an evidence gap; it is not inherited success from the previous version. A measured regression makes promotion REJECT.

11. Action authority is separate from text generation

A model may propose an action, but model output is not authorization. Sensitive tools or operations require deterministic policy and permission checks and, when required, a human gate. Untrusted context must not gain new permissions merely by inducing a tool call. Least authority keeps the model's operational scope minimal.

12. The audit trace should reconstruct governed behavior

For an incident, you should be able to find the runtime call, prompt id/version, template hash, variable schema, context sources, trust labels, evaluation and approval state, and action gate. This is not a request to store hidden reasoning; it is auditable metadata that identifies what governed configuration actually ran.

13. Rollback is a governance feature

When v8 regresses, rollback should not depend on memory or copy-paste. The registry should retain a valid target such as v7, and the post-rollback deployment trace must prove the target is actually running. If the registry says v7 while runtime still executes v8, the incident is not closed.

14. Lab: eight deterministic fixtures

The lab contains eight cases: a v7 baseline with a blocked document injection, v8 without evaluation, v8 with a regression, injection in tool output, registry-v8/runtime-v7 mismatch, an authority-escalation bug, a high-risk action without a human gate, and a fully approved v8 path. The evaluator returns eight auditable fields; expected decisions are not shipped in learner files.

15. Exit checklist and transfer

Before exit, verify prompt identity/version/hash, runtime-evidenced version, variable schema, context provenance and trust labels, denied instruction authority for untrusted sources, version-bound evaluation and approval, high-risk action gates, rollback target, and audit trace. In transfer, repeat the method when the embedded instruction moves into tool output and registry/runtime versions disagree.