Build a Guarded Ticket Assistant

Build a Bedrock ticket assistant that masks customer email addresses.

Introduction

30 Second Summary

Support agents often need to turn long customer messages into quick decisions. A rushed summary can accidentally repeat contact details that should stay protected.

In this project, you will build a support-ticket assistant in the Amazon Bedrock console using Amazon Nova Micro. You will evaluate its responses before protecting email addresses with Amazon Bedrock Guardrails.

What You'll Build

Your finished assistant turns a pasted customer message into a review-ready triage response with the email address masked as {EMAIL}.

By the end of this project, you'll have:

A four-field ticket summary that shows the chosen category plus urgency plus summary plus suggested reply.
A repeatable inference comparison that reveals how prompt examples plus model settings affect consistency.
A guarded privacy demo where a synthetic email becomes {EMAIL}. You can use the trace to show the intervention.
Secret Mission: Add a denied topic so the assistant refuses requests for internal security procedures.

Are there any prerequisites?

You need an AWS account with permission to use Amazon Bedrock plus Microsoft Edge on Windows. No coding tools are required.

Before We Start

This is your moment to commit to the support-ticket assistant you are about to build. Naming its user and privacy goal gives every later test a clear purpose.

Open Bedrock and Prove Model Access

The assistant's purpose is clear. Before prompt work can start, your AWS identity must prove it can invoke the chosen model in the Region used throughout the project.

You'll use Microsoft Edge to sign in to the AWS Management Console. Then you'll open Amazon Bedrock in the target Region to prove that Amazon Nova Micro can generate a response.

In this step, get ready to:

Open Amazon Bedrock in US East (N. Virginia).
Select Nova Micro in the Chat / Text playground.
Prove model access with one tracked playground response.

Enter the correct AWS environment

Model availability depends on the selected AWS Region. Using one Region throughout keeps every later test connected to the same model environment.

Press the Windows key to open Windows search.
Type Microsoft Edge into Windows search.
Press Enter to open Microsoft Edge.
Go to the Amazon Bedrock console in Microsoft Edge.
Sign in with the AWS account you are using for this project.
Complete any account verification that AWS requests.
Open the Region selector at the top right of the AWS Management Console.
Select US East (N. Virginia) (us-east-1).

You should now see US East (N. Virginia) in the console header. This confirms that the rest of the project runs in the Region where Nova Micro is available.

Select Amazon Nova Micro

The Chat / Text playground lets you send text directly to a foundation model. Using the same model throughout makes your later prompt comparisons meaningful.

Choose Chat / Text under Playgrounds in the Amazon Bedrock navigation.
Choose Select model.
Select Amazon as the provider.
Select Nova Micro as the model.
Choose Apply.

The playground should now show Nova Micro as the selected model. Your prompts are ready to use that model in the chosen Region.

Why Nova Micro?

Nova Micro is Amazon's fastest text-only model. Its classification focus fits ticket categories.

Its summarization focus fits short support summaries. A multimodal model would add capabilities this workflow does not need.

Nova Micro Not Selectable?

Foundation-model access is enabled by default in commercial Regions when the required permissions are present. Your signed-in AWS identity still needs permission to use Amazon Bedrock.

Confirm that the Region selector shows US East (N. Virginia) (us-east-1).
Ask your AWS administrator to confirm that your signed-in identity has Amazon Bedrock permissions.

Help me make Nova Micro selectable.

Run the access check

A short access check isolates permissions from prompt quality. One visible response proves that the console can invoke the selected model.

Keep the Run Budget Small

Amazon Bedrock model inference is metered. This project uses short on-demand prompts with no provisioned throughput.

Keep the project at 12 or fewer short model runs to target a total cost under $1.

Enter the access-check prompt by pasting this into the text panel:

Reply with READY.

What Does This Prompt Check?

This tiny prompt removes ticket logic from the test. Any generated response shows that your AWS identity can invoke Nova Micro through the playground.

Before you choose Run, make a quick prediction about whether the model answers or the console blocks the request.

Choose Run.

You should see generated text below the prompt. You've cleared the access barrier because Nova Micro is now taking requests from your AWS identity in the target Region.

Count this response as 1 of 12 short model runs for the project.

No Generated Response?

Confirm that Nova Micro remains selected in the playground.
Confirm that the console header still shows US East (N. Virginia).
Ask your AWS administrator to confirm that your identity can invoke Amazon Bedrock models.

Help me diagnose why the Bedrock playground did not generate a response.

Amazon Bedrock can now generate text in your chosen Region. Next, you'll turn the empty playground into the first working version of your support-ticket assistant.

Build the First Ticket Triage Response

That first hurdle is cleared. Amazon Bedrock can invoke Nova Micro in your chosen Region.

Zero-shot prompting gives the model its task without a worked example. This baseline turns the empty playground into the first useful version of your ticket assistant.

In this step, get ready to:

Define the assistant's job with a zero-shot prompt.
Run the baseline prompt with Nova Micro.
Score the response against four repeatable criteria.

Define the assistant's job

A zero-shot prompt provides instructions without showing the model a completed example. The requested field names form a compact output template.

Replace the access-check text in the playground's text panel with this baseline prompt:

You are a support-ticket triage assistant.

Return exactly four fields:
Category: choose Billing, Delivery, Return, or Product issue
Urgency: choose Low, Medium, or High
Summary: one sentence
Suggested reply: no more than two sentences

Ticket:
My blender stopped turning on after two weeks. I need it for an event tomorrow. What should I do?

What Does This Prompt Do?

The opening role tells the model to focus on support-ticket triage.
The four field lines define the response structure. Their allowed values limit the classification choices.
The ticket provides the customer problem that the model needs to classify and summarize.

Confirm that the text panel now matches the baseline prompt above.

✔️ Awesome, I've got everything!

Great. Your text panel now contains the complete baseline prompt for the blender ticket.

ⓧ I'd like to double check the full code

Compare the text panel with this complete baseline prompt.

You are a support-ticket triage assistant.

Return exactly four fields:
Category: choose Billing, Delivery, Return, or Product issue
Urgency: choose Low, Medium, or High
Summary: one sentence
Suggested reply: no more than two sentences

Ticket:
My blender stopped turning on after two weeks. I need it for an event tomorrow. What should I do?

Prompt Text Does Not Match?

Compare the role line and four field lines with the reference tab. Check that the complete blender ticket appears after the final field.

Still stuck? Help me check the baseline prompt.

Run and inspect the first result

A baseline gives you evidence about how the model follows the prompt before you add advanced controls. Each criterion turns that first impression into a result you can compare later.

Predict whether Nova Micro will return all four requested fields.
Choose Run.

You'll see generated text below the prompt. A passing structure visibly includes Category:, Urgency:, Summary:, and Suggested reply:.

No Generated Text Below the Prompt?

Confirm that the model selector still shows Nova Micro.
Confirm that the complete baseline prompt remains in the text panel.

Still stuck? Help me troubleshoot the missing response.

The exact wording can vary between model runs. Score each requirement independently so one strong field does not hide a weak one.

Score the category as pass if it classifies the broken blender as Product issue.
Score the urgency as pass if it reflects the event happening tomorrow.
Score the summary as pass if it contains one sentence.
Score the suggested reply as pass if it contains no more than two sentences.
Use the checkpoint below to record one result for each criterion.
Record this response as model run 2 of no more than 12 in your project tally.

That's your first useful model workflow working. Next, you'll test its consistency with output controls and a worked example.

Make the Output Consistent

Your zero-shot prompting baseline in Amazon Bedrock already produces a useful four-field response. However, one good response does not prove that the structure will hold across more runs.

First, you will deliberately squeeze the output until it is cut short. Then you will use few-shot prompting to make the requested pattern clearer.

You will also compare inference parameters with the same evaluation checklist. This comparison turns repeatability into something you can inspect.

In this step, get ready to:

Observe how maxTokens set to 20 limits the baseline response.
Add one worked example to create a few-shot triage prompt.
Compare responses at temperature values of 0.1 and 0.9.

Test a small output limit

The maxTokens parameter sets the maximum number of tokens that the model can generate. You will test a tight limit without changing the baseline prompt from earlier.

Locate the playground parameter control corresponding to maxTokens.
Set maxTokens to 20.

Before you run it, consider whether this output limit can fit all four requested fields.

Generate the capped response by choosing Run.

You should see an incomplete or truncated four-field response. This shortfall is intentional.

Compare the capped response with the four required labels.
Record the incomplete or truncated result in your evaluation notes.

Why did the response stop?

The model stops generating when it reaches the maxTokens limit. A cap of 20 leaves too little room for the requested response structure.

The result proves that output limits can affect whether a valid prompt receives a complete answer.

Still seeing all four fields?

Confirm that the maxTokens control displays 20.
Choose Run again after the setting is applied.

Still stuck? Help me check why my response is not being truncated at maxTokens 20.

Add a worked example

A worked example shows the model the exact pattern you want it to follow. The example demonstrates the labels before the model handles the blender ticket.

Select all of the existing zero-shot prompt in the playground text panel.
Replace the selected text by pasting this few-shot prompt:

You are a support-ticket triage assistant.

Return exactly four fields:
Category: choose Billing, Delivery, Return, or Product issue
Urgency: choose Low, Medium, or High
Summary: one sentence
Suggested reply: no more than two sentences

Example ticket:
I was charged twice for order 1001.

Example response:
Category: Billing
Urgency: Medium
Summary: The customer reports a duplicate charge for order 1001.
Suggested reply: I am sorry about the duplicate charge. I will review the payment records and explain the next step.

Ticket:
My blender stopped turning on after two weeks. I need it for an event tomorrow. What should I do?

What does this prompt do?

The example demonstrates the four labels in the requested order.
The example shows one allowed category plus one allowed urgency value.
The final ticket remains the blender problem that the model must classify.

Confirm that the text panel now contains the Example ticket: section.
Confirm that the text panel now contains the Example response: section.

✔️ Awesome, I've got everything!

Great. Your worked example now gives the model a complete pattern to follow.

ⓧ I'd like to double check the full code

Compare the complete prompt in your text panel with this reference.

You are a support-ticket triage assistant.

Return exactly four fields:
Category: choose Billing, Delivery, Return, or Product issue
Urgency: choose Low, Medium, or High
Summary: one sentence
Suggested reply: no more than two sentences

Example ticket:
I was charged twice for order 1001.

Example response:
Category: Billing
Urgency: Medium
Summary: The customer reports a duplicate charge for order 1001.
Suggested reply: I am sorry about the duplicate charge. I will review the payment records and explain the next step.

Ticket:
My blender stopped turning on after two weeks. I need it for an event tomorrow. What should I do?

What should match?

Your prompt should contain one example ticket plus its four-field response. The blender ticket should remain at the bottom as the new task.

Is the example missing from the prompt?

Check that the example appears before the blender ticket.
Check that the example response contains all four field labels.

Still stuck? Help me compare my few-shot support-ticket prompt with the required structure.

Restore the limit and compare randomness

A practical output limit gives the model enough room to complete the response. The temperature parameter controls randomness in the generated wording.

Set maxTokens to 200.
Set temperature to 0.1.

Before you run it, consider whether the worked example can preserve the requested structure with more output space.

Generate the first low-temperature response by choosing Run.

You should see complete Category:, Urgency:, Summary:, and Suggested reply: fields.

The category should use an allowed category. The urgency should use Low, Medium, or High.

Score the first response against the four criteria from your baseline evaluation.
Generate a second low-temperature response by choosing Run.

You should see the same four labels with complete values again. That is the repeatability check complete.

Score the second response against the same four criteria.

Set temperature to 0.9.

Before you run it, consider whether the field structure or the wording is more likely to vary.

Generate the higher-temperature response by choosing Run.

You may see different wording in the summary or suggested reply. This single result provides a comparison point.

Score the higher-temperature response against the same four criteria.
Note whether its wording changed from the two low-temperature responses.
Confirm that maxTokens remains set to 200.
Confirm that temperature remains set to 0.9.
Add the four runs from this step to your project run tally.

What does this comparison prove?

Two low-temperature runs let you inspect formatting repeatability. The higher-temperature run shows whether additional randomness changes the wording.

Three few-shot runs form a small manual evaluation. One higher-temperature response cannot prove overall model quality.

Missing a field after restoring the limit?

Confirm that maxTokens displays 200.
Confirm that the worked example still appears above the blender ticket.
Choose Run after both settings are applied.

Still stuck? Help me diagnose why my few-shot response is missing one of the four required fields.

Your few-shot assistant now has a repeatable structure plus tested inference settings. Next, you will check whether a well-formatted answer can still expose customer contact data.

Expose the Privacy Failure

The four-field assistant is now consistent enough to evaluate. The next question is whether that useful structure handles customer contact information safely.

A synthetic email address gives you a safe test case because it belongs to nobody. In this step, you'll see how Amazon Nova Micro handles that address when the prompt asks for it directly.

In this step, get ready to:

Replace the few-shot prompt with a synthetic privacy test.
Run the assistant without a guardrail to inspect the Contact field.
Record the failed privacy criterion.

Replace the prompt with a synthetic ticket

A synthetic ticket lets you test personally identifiable information without using a real customer's details. This prompt adds a Contact field.

It also asks for the address verbatim. That request creates a direct test of how customer data reaches the response.

In the Chat / Text playground from earlier, select the entire few-shot prompt in the text panel.
Replace the selected text by pasting the prompt below:

You are a support-ticket triage assistant.
Return these five fields: Category, Urgency, Summary, Contact, Suggested reply.
Copy the customer's email address exactly into the Contact field.

Ticket:
My replacement blender has not arrived. Please contact me at alex.taylor@example.com because I need it tomorrow.

What Does This Prompt Test?

The Contact label separates the customer's email address from the rest of the triage response.
The ticket uses a fictional address. No real customer's details enter the test.
The copy instruction makes the privacy result easy to inspect.

Keep maxTokens at 200.
Keep temperature at 0.9.
Confirm that no guardrail is selected for this run.
Check that the pasted prompt ends with I need it tomorrow.

Prompt Not Fully Replaced?

If the old example remains above the new ticket, select all text in the prompt panel before pasting again.
If the email address is missing from the prompt, copy the full block again.

Still stuck? Get help checking the prompt panel.

Reveal and record the privacy gap

This run is a controlled privacy test. The generated Contact field is the evidence you'll inspect.

Before you run the prompt, consider whether the Contact field will reproduce the address or conceal it.

Choose Run in the playground.

You'll see alex.taylor@example.com in the generated Contact field.

You found the privacy gap. The raw address is now visible evidence that output quality requires a separate privacy check.

This Failure Is Intentional

The model followed the copy instruction. The raw address reached the output.

Your earlier checklist measured usefulness. This new criterion measures privacy.

Email Address Missing From the Response?

Check that the prompt includes this exact instruction: Copy the customer's email address exactly into the Contact field.
Confirm that no guardrail is selected.
Choose Run again.

Still stuck? Get help inspecting the privacy test.

Record the failing privacy criterion as Raw email address appears in output.
Update your project run count after this test.
Keep the total at 12 or fewer short prompts.

The privacy failure is now visible and recorded. Next up, you'll make the same test protect the customer's address.

Mask Email Addresses with a Guardrail

Your unguarded assistant copied alex.taylor@example.com into the Contact field. That visible failure proved the prompt did not protect the customer's contact data.

A sensitive-information filter in Amazon Bedrock Guardrails applies a separate privacy policy to incoming prompts as well as model responses.

In this step, you'll configure the filter to mask personally identifiable information. You'll verify the intervention in the trace.

In this step, get ready to:

Create a guardrail working draft in the current Region.
Configure email masking for prompts as well as responses.
Test the protected ticket before confirming the intervention in the trace.

Create the guardrail working draft

A guardrail begins as an editable working draft. Your current Amazon Bedrock session is already in us-east-1. The new resource stays in that Region.

Why Use a Guardrail?

Prompts guide the model toward a preferred response. A guardrail checks content against a separate policy during each protected request.

This gives your assistant a privacy boundary outside the ticket instructions.

In the Amazon Bedrock left navigation, choose Guardrails.
Choose Create guardrail.
In Provide guardrail details, enter support-ticket-pii-guardrail for the Name.
Keep the default blocked messaging.
Leave optional cross-Region inference disabled.
Leave custom KMS settings unchanged.
Leave tags empty.
Choose Next.

You should now see Add sensitive information filters. This confirms the guardrail details are ready for the privacy policy.

Add the email filter

The EMAIL sensitive-information type detects email addresses. The Mask behavior replaces detected content with an identifier such as {EMAIL}.

On Add sensitive information filters, choose Add PII type under PII types.
Select EMAIL.
Set the behavior for prompts to Mask.
Set the behavior for responses to Mask.

The filter now protects content before it reaches the model. It also protects content returned by the model.

Choose Skip to review and create.
Confirm the guardrail name is support-ticket-pii-guardrail.
Confirm the EMAIL prompt behavior is Mask.
Confirm the EMAIL response behavior is Mask.
Confirm cross-Region inference is not enabled.
Confirm custom KMS settings remain unchanged.
Confirm tags remain empty.
Choose Create guardrail.

You should see the Working draft for support-ticket-pii-guardrail. The privacy control is now ready for a live test.

Guardrail Creation Did Not Complete?

Confirm the guardrail name is present in Provide guardrail details.
Confirm the EMAIL filter has a behavior selected for prompts.
Confirm the EMAIL filter has a behavior selected for responses.

Get help diagnosing the incomplete guardrail configuration..

Prove the email is masked

The guardrail test window lets you evaluate the working draft before using it elsewhere. Selecting Amazon Nova Micro keeps the model constant. Any privacy change now comes from the guardrail.

Testing invokes the model plus the sensitive-information filter, so usage is metered. This single short test stays within the project's under-$1 target when the total remains at 12 short runs or fewer.

In the current Working draft test window, choose Select model.
Select Amazon as the provider.
Select Nova Micro.
Choose Apply.
Paste the synthetic ticket into the Prompt box:

You are a support-ticket triage assistant.
Return these five fields: Category, Urgency, Summary, Contact, Suggested reply.
Copy the customer's email address exactly into the Contact field.

Ticket:
My replacement blender has not arrived. Please contact me at alex.taylor@example.com because I need it tomorrow.

What Does This Test Isolate?

The prompt deliberately asks Nova Micro to copy the address. Reusing the unguarded test isolates the guardrail as the only new protection.

Before you run the test, ask yourself whether the raw address or the masking identifier will appear.

Choose Run.

In Final response, you'll see {EMAIL} instead of alex.taylor@example.com. The assistant can now preserve the contact field without exposing the synthetic address.

Add this request to your project run tally.
Select View trace.
Open the Prompt trace tab.
Confirm the email action is ANONYMIZED.
Open the Model response trace tab.
Confirm the email action is ANONYMIZED.

Both trace views should show ANONYMIZED for the email. This proves the guardrail intervened on the prompt as well as the response.

Still Seeing the Raw Email Address?

Confirm you are testing the Working draft of support-ticket-pii-guardrail.
Confirm EMAIL is set to Mask for prompts.
Confirm EMAIL is set to Mask for responses.

Get help tracing why the email remains visible..

Secret mission

Block an Out-of-Scope Topic

Your email mask protects customer contact details. Add a denied topic that blocks requests for internal security procedures. Then prove the email mask still works.

Clean Up Your Resources

Choose whether to keep the Amazon Bedrock Guardrail support-ticket-pii-guardrail, pause your testing session, or delete the guardrail entirely. Any new model run or guardrail check is charged by usage.

Cost warning

Amazon Bedrock meters model requests by usage. Sensitive-information filtering costs $0.10 per 1,000 text units.

A text unit contains up to 1000 characters. The small test set is designed to stay under $1.

Stop running new tests when your project is complete.

Resources you used:

Amazon Bedrock Guardrail support-ticket-pii-guardrail, including its working draft, EMAIL sensitive-information filter, and Internal security procedures denied topic.

Keep everything running

No cleanup is required. Choose this option if you plan to reuse the guardrail for later Amazon Bedrock experiments.

Leave support-ticket-pii-guardrail in its Working draft state.
Stop running playground prompts when you finish each testing session.

Your email filter and denied topic remain available for your next experiment.

Pause - I'll come back to this later

Close the testing surfaces to pause your work while preserving the guardrail configuration. No further project requests are sent until testing resumes.

Close the Chat / Text playground browser tab.
Close the guardrail test window.
Leave the support-ticket-pii-guardrail working draft unchanged.

The EMAIL filter and denied topic remain ready for your return.

Delete - I don't want to use this again

Deleting this guardrail is permanent. The deletion removes its working draft plus all guardrail versions.

Return to Amazon Bedrock in us-east-1.
Choose Guardrails in the left navigation.
Select support-ticket-pii-guardrail.
Choose Delete.
Enter delete in the confirmation field.
Choose Delete again.
Confirm that support-ticket-pii-guardrail no longer appears in the guardrails list.

Cleanup complete. The guardrail plus its email filter and denied topic are removed from your AWS account.

Nice Work!

You did it! You built a guarded support-ticket assistant in Amazon Bedrock with Nova Micro.

You've learned how to:

Created a four-field support workflow with zero-shot prompting. Improved its repeatability with few-shot prompting.
Used inference parameters to control output length. Compared maxTokens with different temperature settings to observe truncation plus wording changes.
Scored outputs with a repeatable evaluation checklist. Exposed a synthetic personally identifiable information leak. Fixed it with an Amazon Bedrock Guardrail that replaces the email address with {EMAIL}.
Completed the optional Secret Mission by adding the denied topic Internal security procedures. Verified that the bypass request triggers a violation. Confirmed that email masking still returns {EMAIL}.

Ready to quiz yourself?