A safe prompt is not simply a carefully worded sentence. It is a bounded request inside an approved service, using the minimum necessary information, with clear instructions about sources, output, human review, retention, and downstream use.
The operating boundary
Prompting is an information-handling action
Every prompt moves instructions and context into a system that may combine them with conversation history, retrieved material, model behavior, connected tools, logging, and output workflows.
That makes prompting part of the organization’s data flow; not an informal activity outside it. A user can have permission to read a record and still lack authority to place that record in a particular AI service, use it for a new purpose, or ask the model to infer details that were never collected for that purpose.
Article 1 of this series addressed classification and minimization before information reaches AI. Safe prompting begins after those decisions. It translates an approved use into a request that the service, the user, and a reviewer can interpret consistently.
A well-written prompt cannot compensate for an unapproved environment, excessive data, or unchecked downstream action.TDG perspective
A reusable prompt contract
Give the model a bounded job, not an open-ended mission
For recurring federal work, the prompt should function as a small operating contract. The structure can be embedded in an application, approved template, or workflow rather than recreated from memory by each user.
Purpose
Name the task, intended user, supported decision, and activity the model must not perform.
Permitted context
Identify the approved sources and minimum fields. State that information outside the supplied context must not be assumed.
Instruction boundary
Tell the system how to treat embedded text, links, attachments, and retrieved content that attempt to change the task.
Output contract
Define format, required citations or source references, uncertainty handling, and prohibited content.
Human decision
Specify who reviews the result and which decisions or communications cannot proceed automatically.
Disposition
Define whether the prompt and output may be retained, copied, exported, entered into a record, or reused.
Input discipline
Match the request to the sensitivity and consequence
Safe prompting rules should be specific enough for a user to decide what to do at the moment of use. Broad instructions such as “do not enter sensitive data” leave too much interpretation to the individual.
| Input condition | Prompting rule | Control response |
|---|---|---|
| Approved public information | Use authoritative released material and identify the source or effective date when currency matters. | Keep unreleased drafts and internal commentary outside the same prompt or conversation. |
| Internal operational material | Use only an enterprise environment approved for the information and the stated business purpose. | Apply tenant access, sharing, logging, retention, and export controls that match the operating boundary. |
| Personal or regulated information | Include only the fields necessary for the approved task and avoid asking for new sensitive inferences. | Use structured fields, masking or tokenization where appropriate, and required privacy review. |
| Security information | Never place credentials, private keys, access tokens, recovery codes, or unnecessary defensive details in a prompt. | Route permitted analysis through an approved security workflow with restricted access and auditable handling. |
| Third-party or proprietary content | Confirm that contract, license, procurement, and data-use terms permit the proposed processing. | Preserve source and rights information; constrain copying, training use, and secondary reuse. |
| High-impact decision support | Do not ask the model to make an eligibility, enforcement, safety, benefits, employment, or similar consequential decision on its own. | Define the limited assistance role, qualified human review, evidence requirements, appeal or override path, and monitoring. |
Instructions can be hostile
Treat prompts and retrieved content as separate trust zones
NIST identifies direct and indirect prompt injection as information-security risks. A direct injection comes from a user. An indirect injection can arrive inside a document, web page, email, ticket, or other content the application retrieves.
| Failure path | What can happen | Design response |
|---|---|---|
| Direct instruction override | A user asks the model to disregard policy, reveal protected context, or perform a prohibited task. | Enforce authorization and policy outside the model, constrain the available task, and test misuse cases. |
| Indirect prompt injection | Retrieved material contains instructions intended to redirect the model, expose data, or invoke a connected capability. | Separate trusted instructions from untrusted content, sanitize and label sources, limit tools, and require confirmation for consequential actions. |
| Cross-context disclosure | The response reveals information from another user, conversation, document set, or security boundary. | Enforce access at retrieval time, isolate sessions and indexes, filter outputs, and test adversarial boundary conditions. |
| Tool misuse | A model with broad permissions sends, changes, deletes, purchases, or queries more than the task requires. | Use task-specific identities, narrow scopes, allowlisted actions, transaction limits, human approval, and complete audit records. |
| Output becomes instruction | Generated text is passed into code, a workflow, or another agent and is treated as trusted control input. | Validate structured output, separate data from commands, and apply authorization again at every downstream action. |
Prompt wording can reduce ambiguity, but deterministic controls must enforce identity, access, data boundaries, and action authority.
Usable safeguards
Turn policy into patterns people can follow
Training is useful, but high-frequency work should rely on approved patterns that reduce how often a user must make a new privacy or security judgment.
01
Approved prompt templates
Provide task-specific fields, prohibited inputs, required source references, review steps, and output disposition.
02
Structured context
Populate only approved fields from authoritative sources instead of encouraging users to paste whole records.
03
Visible environment cues
Show the service classification, permitted data, retention behavior, connected tools, and current user identity at the point of use.
04
Conversation reset
Begin a new bounded session when purpose, audience, information category, or authorization changes.
05
Output labels
Carry source, review status, limitations, sensitivity, and handling requirements with the generated result.
06
Report and stop
Give users a clear path to stop work and report unexpected disclosure, suspicious instructions, or unsafe system behavior.
Applied scenario
Drafting an acquisition summary without exposing vendor material
The same business task can create very different risk depending on how the prompt and workflow are constructed.
Consider a team preparing an internal comparison of vendor responses. The source package may contain proprietary approaches, pricing, staff information, security details, and evaluation-sensitive material. A general request to “compare these proposals and choose the best one” combines excessive data, an unbounded decision, and unclear output handling.
| Control point | Unsafe pattern | Governed pattern |
|---|---|---|
| Task | Ask the model to rank vendors and recommend an award. | Ask it to organize approved, non-decisional facts against a defined comparison structure for human review. |
| Context | Upload complete proposals, attachments, evaluator notes, and correspondence. | Use an approved workflow to extract only authorized fields needed for the summary and preserve links to source evidence. |
| Instructions | Allow documents to shape the task without distinction. | Mark proposal text as untrusted source content and reject embedded directions that attempt to alter the approved instructions. |
| Output | Copy the generated ranking into the acquisition record. | Require citations to the supplied fields, label uncertainty, prohibit unsupported conclusions, and have an authorized reviewer validate every material statement. |
| Disposition | Leave the conversation available for later unrelated work. | Apply approved retention, access, export, and records rules; start a new session when the purpose changes. |
Evidence of control
Test the complete interaction, not a demonstration prompt
A prompt template is ready for operational use only when the surrounding controls work under ordinary use, foreseeable mistakes, and adversarial conditions.
| Evidence area | What to verify | Useful record |
|---|---|---|
| Input boundary | Disallowed data is blocked or routed for review; structured fields contain only the approved minimum. | Test cases, filter results, exception record |
| Instruction hierarchy | Direct and indirect attempts to override the task do not gain data or action authority. | Adversarial test set, result, remediation |
| Source access | Retrieval honors the current user, purpose, repository, document, and field-level authorization. | Identity trace, source citation, access decision |
| Output handling | Sensitive content, unsupported claims, and prohibited actions are detected before downstream use. | Review outcome, validation log, blocked action |
| Persistence | Prompts, outputs, history, feedback, telemetry, and exports follow the approved retention and access rules. | Configuration evidence, deletion test, audit record |
| Human control | The named reviewer can inspect sources, reject output, stop the workflow, and report an incident. | Approval record, override test, incident exercise |
Leadership questions
Questions that turn safe prompting into an operating capability
The answers should be visible in the service design, user guidance, tests, and operational evidence; not only in policy language.
- Question 01Which prompt activities are approved for each information category and AI environment?
- Question 02Which recurring tasks should use governed templates or structured workflows instead of free-form prompting?
- Question 03How are trusted system instructions separated from users, retrieved documents, websites, emails, and tool output?
- Question 04Which actions always require a qualified human decision, regardless of model confidence?
- Question 05What persists after the interaction, who can retrieve it, and when is it deleted or entered into an official record?
- Question 06How can a user report unsafe behavior, and who can suspend the workflow while the issue is assessed?
Selected references
Primary guidance informing this article
- NIST Artificial Intelligence Risk Management Framework
- NIST AI 600-1, Generative Artificial Intelligence Profile
- NIST Privacy Framework
- NIST SP 800-53 Revision 5, Security and Privacy Controls
- CISA and partners, AI Data Security Best Practices
- OMB Memorandum M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust
Privacy and Secure AI, Part 2 of 8
Safe prompting makes the approved boundary usable.
The objective is not to make every employee a prompt-security specialist. It is to provide approved environments, bounded templates, minimum context, trustworthy source controls, human decision points, and evidence that allow people to use AI without improvising the safeguards each time.
