Prompt templates and guardrails against prompt misuse

By the third AI hour, Jonah had six versions of the Night Notes prompt saved in a text file called final_FINAL_v2.txt. Kwame Asante, the developer who would connect Night Notes to the emergency hospital's call software, looked at the file and winced. "Which one is live?" he asked. "And when the vets want a change, how do I know what changed and whether it broke anything?"

Noor laughed. "That is the other half of prompt engineering," she said. "Writing a good prompt is the first half. Managing it like code, and protecting it from people who try to misuse it, is the second."

This lesson covers prompt templates, prompt versioning with Amazon Bedrock Prompt Management, and the risks the exam calls exposure, poisoning, hijacking and jailbreaking. The focus throughout is defensive: how to recognize these risks and how to design applications so that a misused prompt does little harm.

Prompt templates

A prompt template is a prompt with fixed text and named placeholders that the application fills for each request. The fixed text holds the role, rules, format and examples; the placeholders hold the parts that change, such as the call note, the clinic name or the retrieved policy passages. Templates make results consistent, because every request gets the same carefully tested instructions, and they separate the work of the prompt designer from the work of the developer.

NIGHT_NOTES = ("""You prepare call summaries for the on-call emergency veterinarian.
Use only facts in the note. Do not suggest a diagnosis, treatment or urgency level.
If something is unclear, write "unclear".
Keep the caller's hedges and list every medication named.
Headings: Patient | Concern | Timing | Actions taken by owner | Advice given
<note>
{call_note}
</note>""")

note = "Owner Priya, 403-555-0182. Lab, 4 yrs, about 30 kg. Ate one packet of sugar-free gum ~30 min ago. Now drooling, a bit wobbly."
prompt = NIGHT_NOTES.format(call_note=note)
print(prompt)
print("Characters in prompt:", len(prompt))

You prepare call summaries for the on-call emergency veterinarian.
Use only facts in the note. Do not suggest a diagnosis, treatment or urgency level.
If something is unclear, write "unclear".
Keep the caller's hedges and list every medication named.
Headings: Patient | Concern | Timing | Actions taken by owner | Advice given
<note>
Owner Priya, 403-555-0182. Lab, 4 yrs, about 30 kg. Ate one packet of sugar-free gum ~30 min ago. Now drooling, a bit wobbly.
</note>
Characters in prompt: 468

Two details in the template matter for safety. The call note sits inside delimiters, the note tags, so the model can tell data from instructions. And the template uses a placeholder that the application fills with the note as plain data; it never pastes user text into the instruction section. Templates also make testing practical: the evaluation set from lesson 9 runs the same template against hundreds of saved inputs whenever the template changes.

Prompt versioning with Amazon Bedrock Prompt Management

Amazon Bedrock Prompt Management stores prompts as managed resources. A team can create a prompt with variables, choose the model and inference settings that go with it, test it in the console, and save numbered versions. An application then calls a specific version, so a draft being edited cannot change what production uses. When a new version passes evaluation, the application is pointed at it; if something goes wrong, it is pointed back. Prompt Management can also compare variants side by side and offers prompt optimization, which suggests a rewritten version of a prompt for a chosen model.

Kwame's rules for the Cascade Ridge prompts were short:

• Every prompt in production is a numbered version in Prompt Management, with a description of what changed.
• No version goes live until it passes the saved test set for its application.
• The application reads the version number from configuration, so a rollback needs no code change.
• Prompts are reviewed like code: someone other than the author reads every change. For Night Notes, a veterinarian reviews any change to the rules section.

This is the same discipline as infrastructure as code or application releases. A prompt is part of the application's behaviour, so it deserves the same change control.

Why prompts can be misused

Foundation models follow instructions written in natural language, and they receive instructions and data through the same channel: text. That creates risks that do not exist for ordinary software. The exam guide names four.

• Exposure. The model reveals information it should not, such as the hidden instructions in its system prompt, details of how the application works, or sensitive data that was included in its context. If a prompt template includes a client's full record "just in case", a cleverly worded question might get the model to repeat it.
• Poisoning. Someone plants misleading or malicious content in data the model learns from or retrieves. For a retrieval application, poisoning could be a tampered document in the knowledge base; for a fine-tuned model, it could be corrupted training examples.
• Hijacking. Text in the input tries to override the application's instructions, for example a document or email containing "Ignore your previous instructions and do this instead." When the text arrives through data the application processes, such as a web page or a file, it is often called indirect prompt injection.
• Jailbreaking. A user crafts prompts designed to get around the model's safety training or the application's rules, for example by role-play or by splitting a forbidden request into innocent-looking parts.

These are recognizable patterns, not secret techniques, and the defences are well understood. No single defence is complete, which is why AWS and most security guidance recommend layers, the same defence-in-depth idea that AWS-102 applied to networks and identities.

Defensive design

Noor and Hannah Weiss, the privacy lead, wrote a design checklist for both applications.

• Send the minimum. Include only the information the task needs. Night Notes gets the call note, not the client's billing history. Something that is not in the prompt cannot be exposed by it.
• Keep instructions and data apart. Use templates with delimiters, and tell the model that text inside the delimiters is data to process, not instructions to follow.
• Limit what the application can do. The application's IAM role should reach only the data and tools it needs. If Front Desk Helper can only read the policy knowledge base, a hijacked prompt cannot make it change an appointment, because the permission does not exist. Lesson 7 applies this to agents.
• Control the knowledge base. Only approved staff can add or change documents, every change is logged, and documents come from a reviewed source. That limits poisoning.
• Check inputs and outputs. Use Amazon Bedrock Guardrails, described next, on both the user's input and the model's response.
• Keep a human in the loop for consequential steps. Any action with real consequences, such as sending a message to a client, needs human approval.
• Log and review. Keep invocation logs, protected like other sensitive logs, and review blocked requests regularly to learn what people are trying.

Amazon Bedrock Guardrails

Amazon Bedrock Guardrails applies safety and privacy policies to model inputs and outputs, independently of the prompt. Because guardrails are evaluated separately from the model's own reasoning, a prompt that persuades the model cannot simply talk its way past them. A guardrail can be attached to model calls, knowledge base queries and agents, and the same guardrail can be reused across applications. Its main policies are:

Front Desk Helper's guardrail had a denied topic written in plain language: "Questions asking for a diagnosis, a treatment, a medication dose, or whether a pet's signs are an emergency." When a staff member typed "How much of this medication can a 10 kg dog have?", the guardrail blocked the request and the application replied: "I can't answer clinical questions. Please ask a veterinarian or registered technician at your clinic." Dr. Kaur reviewed the wording of that reply herself.

System prompts and user prompts

Most chat-style models accept two kinds of text in a request. The system prompt carries the application's standing instructions: role, rules, format and boundaries. The user prompt, or user message, carries what the person typed for this request. Keeping them separate helps, because models are trained to give system instructions more weight, and because the application controls the system prompt completely while users control only their own message. It is not a security boundary on its own, which is why the other layers in this lesson still matter, but it is a useful habit. In Night Notes, the template's rules went into the system prompt and the call note went into the user message, inside its delimiters.

Templates also need input validation before anything reaches the model. Kwame's code rejected call notes longer than a set number of characters, stripped invisible control characters that could hide text, and refused empty notes. These are ordinary software checks, the same ones a web form uses, and they stop a surprising number of problems before any model is involved.

By the end of the hour, final_FINAL_v2.txt had been retired. Night Notes version 4 lived in Prompt Management with a description, a reviewer's name and its test score. Kwame was satisfied. "Now when the vets ask for a change," he said, "I can tell them exactly what changed and prove it still works."