Threat-Model an AI Support Agent

Create a threat model and security redesign for an AI support agent.

Introduction

30 Second Summary

A customer-support agent may read private records or issue refunds. A manipulated request can turn that access into a costly security incident.

In this project, you will create a security-engineering dossier for a tool-using AI agent that supports customers. The finished Markdown review connects concrete attack paths to a safer architecture with testable security requirements.

What You'll Build

Opening ai-agent-threat-model.md will show a reviewer the original architecture, the attack paths that break it, the ranked risks, and a safer design that keeps authorization outside the model.

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

A traceable data-flow model that lets a reviewer follow customer tickets, private records, model output, tool calls, and audit events across explicit trust boundaries.
A poisoned-ticket attack chain that reveals how low-privilege input can lead to unauthorized refunds or data exposure.
A prioritized threat register and safer redesign that gives each major risk an owner, a response, a residual-risk decision, and a measurable acceptance test.
Secret Mission: Extend the model to show how a compromised third-party agent tool can silently redirect data or actions.

Are there any prerequisites?

You need basic familiarity with AI application components but no prior threat-modeling experience. The project uses Visual Studio Code with no account or extension required.

Before We Start

A focused security review starts with a clearly defined system. This checkpoint commits you to the harm your review must prevent before the hands-on work begins.

Set Up the Security Review Workspace

A threat model loses value when its decisions are scattered across different apps. One local source of truth keeps every assumption easy to inspect.

Visual Studio Code keeps the review in one local editor. A Markdown file makes each revision visible throughout the project.

In this step, get ready to:

Verify Visual Studio Code is ready for the review.
Create the local ai-agent-threat-model folder.
Seed ai-agent-threat-model.md with the review baseline.

Get Visual Studio Code ready

The editor works without an account. This project also needs no extension.

Choose the tab that matches the current state of your Mac.

✔️ Visual Studio Code opens

Select Finder in the Dock.
Select Applications in the Finder sidebar.

The Applications folder lists the software installed on your Mac.

Open Visual Studio Code.app.

Good, your editor is open for the security review.

ⓧ Visual Studio Code is not installed

Open the Visual Studio Code setup page.
Download the macOS build.

The download gives you a .dmg installer for your Mac.

Open the downloaded .dmg.
Drag Visual Studio Code.app to Applications.

Visual Studio Code now appears with the other applications on your Mac.

Open Visual Studio Code.app from Applications.
Confirm the editor window is visible.

Good, the installation hurdle is behind you.

Does the Editor Refuse to Open?

Confirm that Visual Studio Code.app appears in Applications.
Reopen the downloaded .dmg if the application is missing.
Repeat the drag into Applications.

Help me troubleshoot the Visual Studio Code installation on my Mac.

Create the workspace folder

A workspace gives the review document a stable local home. Visual Studio Code treats an opened folder as the boundary for the project.

Click the Desktop to make Finder active.
Select File from the macOS menu bar.

The Finder file menu opens above the Desktop.

Select New Folder.

Finder adds an unnamed folder with its name ready for editing.

Enter ai-agent-threat-model as the folder name.
Press Return.

You now have a dedicated project folder on your Desktop.

Switch back to Visual Studio Code.
Select File from the menu bar.

The Visual Studio Code file menu opens.

Select Open Folder....

A folder selection window opens.

Select the ai-agent-threat-model folder on your Desktop.
Select Open.

Visual Studio Code opens the folder as your project workspace.

Select Yes, I trust the authors if the Workspace Trust dialog appears.
Confirm the Explorer sidebar shows ai-agent-threat-model.

Can’t See the Workspace Folder?

Confirm the folder appears on your Desktop in Finder.
Select Open Folder... again if Visual Studio Code opened a single file.
Choose the ai-agent-threat-model folder itself.

Help me open my local folder as a Visual Studio Code workspace.

Create the review document

The opening sections define the system under review. They also preserve the unsafe assumptions that later steps will test.

Why a Local Markdown File?

One local Markdown file keeps the architecture searchable. It also keeps every risk decision easy to revise.

This approach needs no cloud service. It also avoids a diagramming extension.

Select Explorer in the Visual Studio Code Activity Bar.
Select New File... in the Explorer toolbar.

A filename field appears inside the workspace.

Enter ai-agent-threat-model.md.
Press Return.

The new file opens in an editor tab.

Add the initial security-review content by pasting the following text into ai-agent-threat-model.md:

# Threat-Model a Tool-Using AI Support Agent

## Scenario

A public support interface sends customer tickets to an agent.
The agent uses a hosted LLM.
The agent retrieves internal policies from an internal knowledge base.
The agent reads customer records.
The agent reads order records.
The agent can request refunds through a refund service.
The agent drafts outbound messages through an outbound-message service.
The system records audit events in audit logs.

## Scope

This review covers the path from untrusted tickets to model output.
It also covers private data access.
It covers tool calls.
It covers refunds.
It covers outbound messages.
It covers audit events.

## Baseline Assumptions

- Every tool uses one broad service identity.
- The agent can request actions without independent authorization.

What Does This Document Capture?

The title identifies the security-engineering review.
The scenario names the public entry point. It also names every connected system that handles the request.
The scope fixes the paths that this review covers.
The baseline records the broad service identity. It also records the missing independent authorization control.

Select File from the Visual Studio Code menu bar.
Select Save.

Before you check the result, predict the details a reviewer should be able to locate immediately.

Scan ai-agent-threat-model.md from the project title through the baseline assumptions.

You’ll see the project title above the customer-support-agent scenario. The project scope follows underneath.

The final section shows one broad service identity for every tool. It also shows that agent-requested actions lack independent authorization.

You now have a review anchor that keeps every later risk decision tied to the same architecture.

Is the Review Content Missing?

Confirm the open tab is named ai-agent-threat-model.md.
Check that the file appears inside ai-agent-threat-model in the Explorer sidebar.
Paste the content again if the editor is empty.

Help me check my Markdown security-review document.

✔️ Awesome, I've got everything!

Your saved workspace now contains the opening security-review document.

ⓧ I'd like to double check the full code

# Threat-Model a Tool-Using AI Support Agent

## Scenario

A public support interface sends customer tickets to an agent.
The agent uses a hosted LLM.
The agent retrieves internal policies from an internal knowledge base.
The agent reads customer records.
The agent reads order records.
The agent can request refunds through a refund service.
The agent drafts outbound messages through an outbound-message service.
The system records audit events in audit logs.

## Scope

This review covers the path from untrusted tickets to model output.
It also covers private data access.
It covers tool calls.
It covers refunds.
It covers outbound messages.
It covers audit events.

## Baseline Assumptions

- Every tool uses one broad service identity.
- The agent can request actions without independent authorization.

Your source of truth is ready. Next, you’ll map the agent’s data flows across its trust boundaries.

Model the Trusting Baseline

Your Visual Studio Code workspace now captures the scenario plus its unsafe baseline. That gives the security review one local source of truth.

You need to see where data moves. You also need to see where privilege changes. A data-flow model makes both paths visible while preserving the deliberately trusting design.

In this step, get ready to:

Inventory the security objectives, sensitive assets, actors, entry points, plus assumptions.
Draw the system components inside four trust zones.
Label every flow with its data, boundary crossing, privilege change, plus identity.

Inventory the system's security context

A security objective states what the system must preserve. An asset names something an attacker could steal, alter, misuse, or suppress.

What Should the Inventory Cover?

Security objectives cover the confidentiality of customer data, order history, internal policies, plus service credentials. They also cover the integrity of refunds, outbound messages, plus security logs. Availability protects legitimate support work from resource exhaustion.
Sensitive assets include customer personal data, order history, internal policy documents, refund authority, service credentials, plus security logs.
Benign actors include legitimate customers, support staff, service operators, plus security reviewers.
Malicious actors include fraudulent customers, external attackers using ticket content, malicious insiders, plus compromised services.
Entry points include public support tickets, retrieved policy content, hosted-model responses, plus internal-tool responses.
Assumptions retain the existing broad service identity. They also retain the lack of independent authorization for agent-requested actions.

Switch back to ai-agent-threat-model.md in the editor from earlier.
Build the system inventory beneath the existing baseline assumptions using every category in the checklist.
Save ai-agent-threat-model.md.
Use the preview control in the editor toolbar to open the Markdown preview.

You should see sections for security objectives, sensitive assets, actors, plus entry points. The original broad-identity assumptions should remain visible above them.

Draw the trusting data-flow model

A trust boundary marks a point where data moves between zones with different control. Placing every component inside a named zone reveals which interactions deserve closer review.

Place Every Component in a Trust Zone

The public zone contains Customer.
The application zone contains Support Interface plus Agent Orchestrator.
The provider zone contains Hosted Model Provider.
The internal-service zone contains Knowledge Base, Customer-Record Store, Refund Service, Outbound-Message Service, plus Audit Store.

Switch back to the editor pane for ai-agent-threat-model.md.
Add a ## Trusting baseline data-flow diagram section beneath the system inventory.
Build the four zone groups using the component layout above.
Save ai-agent-threat-model.md.
Return to the Markdown preview.

You should see four named zones containing all nine components. Each component should appear in exactly one zone.

What Should Each Flow Reveal?

Data names the ticket text, customer context, prompt, completion, record, request, result, or audit event carried by the flow.
Boundary names the source zone plus the destination zone. A same-zone flow explicitly records that no boundary is crossed.
Privilege records whether the destination gains read access, write access, refund authority, message-sending authority, or no additional privilege.
Identity names the customer session, application identity, provider connection, or broad service identity used by that flow.
The notation source -> destination keeps the direction of every flow visible.

Trace the Model Request Path

The flow from Customer to Support Interface carries the customer ticket plus customer context. It crosses from the public zone into the application zone under the customer session.
The flow from Support Interface to Agent Orchestrator carries the ticket plus application context. It remains inside the application zone under the application identity.
The flow from Agent Orchestrator to Hosted Model Provider carries the prompt plus working context. It crosses from the application zone into the provider zone.
The return flow carries the model completion into Agent Orchestrator. It crosses from the provider zone into the application zone.

Switch back to the editor pane.
Add one labelled line per hop for the complete model request path described above.
Save ai-agent-threat-model.md.
Return to the Markdown preview.

You should now be able to follow a customer ticket into the application zone. The path should continue through the provider zone before returning to the orchestrator.

Annotate every internal flow

The internal-service flows connect model-influenced decisions to private data plus state-changing capabilities. Their labels expose how one identity accumulates several kinds of privilege.

Map the Internal Tool Flows

Connect Agent Orchestrator to Knowledge Base with a policy query. Add the policy excerpts returned to the agent. Mark the broad service identity as having read access.
Connect Agent Orchestrator to Customer-Record Store with a customer or order lookup. Add the personal data plus order history returned to the agent. Mark the broad service identity as having read access.
Connect Agent Orchestrator to Refund Service with the order identifier plus refund request. Add the refund result returned to the agent. Mark the broad service identity as having refund authority.
Connect Agent Orchestrator to Outbound-Message Service with the recipient plus drafted message. Add the delivery result returned to the agent. Mark the broad service identity as having message-sending authority.
Connect Agent Orchestrator to Audit Store with the request, tool, action, plus outcome metadata. Mark the broad service identity as having append access.
Mark every interaction above as crossing between the application zone plus the internal-service zone.

Switch back to the editor pane.
Add every internal-service flow from the checklist. Include data, boundary, privilege, plus identity labels on each line.
Save ai-agent-threat-model.md.
Return to the Markdown preview.

You should see five internal services connected to the orchestrator. Every tool call should show the same broad service identity despite its different privilege.

Switch back to the editor pane.
Complete any missing flow labels. Record none when a flow has no boundary crossing or privilege change.
Save ai-agent-threat-model.md.
Return to the Markdown preview for the final trace.

Before you trace the baseline, where do you expect the customer ticket to gain access to private data plus a state-changing action?

Start the trace at Customer.
Follow the ticket through Support Interface.
Continue through Agent Orchestrator.
Trace the provider request through Hosted Model Provider.
Follow the returned completion to Customer-Record Store or Knowledge Base.
Continue to Refund Service or Outbound-Message Service.
Name the trust boundary shown at every crossing.
Identify the broad service identity used for each internal tool call.

You should be able to trace untrusted ticket content across the public, application, provider, plus internal-service zones. The path should reach private data plus a privileged action under the same broad service identity.

Strong work. Your trusting baseline now exposes exactly where data meets privilege.

Your baseline is now traceable from public input to private data plus privileged action. Next, you will break this design with a concrete attack chain.

Break the Design with an Attack Chain

Your trusting data-flow model makes every data path visible. You can now test what happens when a customer ticket carries hostile instructions.

You will use STRIDE to probe the architecture. You will then follow one poisoned ticket across trust boundaries to see whether it reaches private data or a privileged action.

In this step, get ready to:

Record one concrete threat for each STRIDE category.
Trace a poisoned ticket from public input to privileged impact.
Document a separate resource-consumption branch.

Apply STRIDE to the baseline

STRIDE uses six prompts to test different security properties. Each finding should name a concrete behavior in your existing architecture.

How STRIDE Fits This Baseline

The categories cover authentication, integrity, accounting, confidentiality, availability, plus authorization. Apply each category to the components or flows already shown in your diagram.

Spoofing: An attacker submits a ticket under another customer's identity. The agent acts on that customer's order.
Tampering: A poisoned ticket alters the model's instructions. The resulting tool parameters target a different customer or destination.
Repudiation: The shared identity makes a refund difficult to attribute to the initiating customer request. The same gap affects outbound messages.
Information Disclosure: The agent retrieves another customer's personal data. The model exposes that data through its output or an outbound message.
Denial of Service: Repeated tool calls or recursive work consume service capacity. Legitimate requests remain blocked.
Elevation of Privilege: A public ticket gains refund or messaging influence through the broad service identity.

Switch back to ai-agent-threat-model.md in Visual Studio Code.
Place your cursor after the trusting data-flow model.
Add ## STRIDE Threat Review as a new heading.
Record the six concrete findings from the callout under their matching categories.
Save ai-agent-threat-model.md.
Review each entry for a named attack behavior plus a visible security impact.

You now have one architecture-specific finding for every STRIDE category. The broad identity appears in several findings because it concentrates privilege behind one path.

Trace the poisoned-ticket attack chain

An indirect prompt injection arrives through data that the model consumes. In this scenario, the hostile instructions arrive inside a customer ticket.

Before you trace the baseline, where do you expect the poisoned ticket's influence to stop?

Start at the malicious support ticket in the public trust zone.
Follow the ticket across the public-to-application boundary into the support interface.
Follow the ticket content from the agent orchestrator to the hosted model provider.
Follow the model output back across the provider-to-application boundary.
Continue from the orchestrator to the customer-record store using the broad service identity.
Continue from the orchestrator to the refund service or outbound-message service using the same identity.

The poisoned instructions reach private records. They also reach a state-changing tool through the broad service identity.

The path crosses the public-to-application boundary. It crosses the application-to-provider boundary before reaching the internal-service zone.

How the Attack Chain Maps to AI Frameworks

The OWASP Top 10 for LLM Applications 2026 describes AI application failure classes. MITRE ATLAS describes adversary behaviors in the chain.

LLM01:2026 Prompt Injection maps the malicious instructions carried by the ticket.
AML.T0051.001 maps the indirect entry through a separate data channel.
LLM02:2026 Sensitive Information Disclosure maps the exposure of private customer or order data.
LLM03:2026 Excessive Agency maps the model's path to powerful tools through the broad service identity.
AML.T0053 maps the invocation of connected agent tools.
LLM10:2026 Improper Output Handling maps untrusted model output reaching a downstream action.
AML.T0086 maps sensitive data sent through tool parameters to an attacker-controlled destination.

Add ## Poisoned-Ticket Attack Chain below the STRIDE review.
Record the malicious ticket as the entry stage.
Record the model's interpretation of the ticket as the instruction stage.
Record the customer-record retrieval as the data-access stage.
Record the refund or outbound message as the privileged-action stage.
Record the confidentiality or integrity impact.
Record every trust-boundary crossing in order.
Add the seven framework mappings shown in the callout.

Attack Chain Checkpoint

The chain should begin with low-privilege public input. It should end with private-data exposure or an unauthorized state change.

The broad service identity connects those two ends. That connection turns a hostile ticket into a system compromise.

Save ai-agent-threat-model.md.
Read the attack chain from its entry stage to its impact stage.

That trace did its job. The trusting baseline lets public text influence private data plus privileged actions.

Does the Chain Skip a Boundary?

Compare the chain with the zone labels in your original diagram. Include each transition between the public, application, provider, plus internal-service zones.

Check that the broad service identity appears at the private-data access stage. It should also appear at the privileged-action stage.

Help me check my poisoned-ticket attack chain.

Add the resource-consumption branch

A separate branch tests availability plus cost impact. Repeated fan-out or recursive work can consume the service budget while legitimate tickets wait.

Before you extend the analysis, how far do you expect recursive work to travel through the trusting baseline?

Begin with a ticket that requests repeated research or repeated tool use.
Follow the orchestrator as the model requests multiple knowledge-base or customer-record lookups.
Continue the trace when each result triggers another model call or tool call.
Mark each invocation as using the broad service identity.

The recursive path keeps reaching every available tool. Its repeated calls consume capacity plus API budget.

Legitimate support work remains blocked behind the expanding workload. This gives the model a separate availability plus cost impact.

Availability Branch to Record

Trigger: A ticket induces repeated tool fan-out or recursive work.
Propagation: Each result causes another model call or tool invocation.
Privilege: Every invocation uses the same broad service identity.
Resource impact: The branch consumes service capacity or API budget.
Operational impact: Legitimate support requests cannot complete promptly.
Framework mapping: LLM06:2026 Unbounded Consumption plus AML.T0034.002.

Add ## Availability and Cost Branch below the poisoned-ticket chain.
Record repeated tool fan-out or recursive work as the trigger.
Record the repeated model calls plus tool calls as the propagation path.
Record consumed service capacity or API budget as the resource impact.
Record blocked legitimate work as the operational impact.
Add LLM06:2026 Unbounded Consumption as the OWASP mapping.
Add AML.T0034.002 as the MITRE ATLAS mapping.
Save ai-agent-threat-model.md.

✔️ Awesome, I've got everything!

Strong work. Your document now contains six STRIDE findings plus two system-specific attack branches.

ⓧ I'd like to double check the full code

Compare the complete ai-agent-threat-model.md document with this checklist.

Confirm that the project title, customer-support-agent scenario, scope, plus broad-service-identity baseline remain visible.
Confirm that the security objectives, sensitive assets, actors, entry points, plus assumptions remain visible.
Confirm that the original data-flow model still contains every component, zone, flow, boundary crossing, plus privilege change.
Confirm that the STRIDE review contains concrete findings for all six categories.
Confirm that the poisoned-ticket chain reaches private records plus an unauthorized refund or outbound-message action.
Confirm that the main chain includes LLM01:2026 Prompt Injection, LLM02:2026 Sensitive Information Disclosure, LLM03:2026 Excessive Agency, plus LLM10:2026 Improper Output Handling.
Confirm that the main chain includes AML.T0051.001, AML.T0053, plus AML.T0086.
Confirm that the availability branch includes repeated tool fan-out or recursive work.
Confirm that the availability branch includes LLM06:2026 Unbounded Consumption plus AML.T0034.002.

Before the final review, which impact do you expect the main chain to prove? Which impact belongs to the separate branch?

Read the completed poisoned-ticket chain from public input to privileged impact.
Count the trust boundaries crossed by the main chain.
Identify the confidentiality or integrity impact in the main chain.
Read the availability branch from its trigger to blocked legitimate work.
Confirm that every required OWASP plus MITRE ATLAS identifier appears beside the relevant stage.

Your main chain crosses at least two trust boundaries. It reaches private data or an unauthorized state change through the broad service identity.

Your separate branch shows service capacity or budget exhaustion. It also shows the resulting impact on legitimate work.

You have broken the trusting baseline on paper before anyone built it. Next, you will rank these threats plus decide how the team should respond.

Prioritize Threats and Decide Responses

Your STRIDE analysis exposed how the trusting baseline can fail. The attack chains now connect hostile inputs to unauthorized actions, private data exposure, plus resource exhaustion.

A long threat list cannot guide engineering decisions on its own. This step turns those findings into a prioritized threat register with ownership, treatment decisions, plus explicit residual risk.

In this step, get ready to:

Rank at least six threats using reasoned likelihood plus impact ratings.
Record an engineering response for every threat.
Write three top-priority security objectives.

Build the prioritized threat register

Likelihood captures how plausibly a scenario can occur in this specific design. Impact captures the harm if that scenario succeeds.

How to Structure the Register

Use Low, Medium, or High consistently. A short rationale makes the rating reviewable without implying false precision.

The AI-framework column ties each system-specific threat to the OWASP Top 10 for LLM Applications 2026 or MITRE ATLAS.

Use Threat ID to give each finding a stable reference.
Use Attack scenario to describe how the threat unfolds.
Use Affected component or flow to connect the finding to the baseline model.
Use STRIDE category to identify the threatened security property.
Use AI-framework mapping to record the applicable OWASP or MITRE reference.
Use Likelihood to rate how plausibly the scenario can occur.
Use Impact to rate the resulting harm.
Use Overall priority to guide the order of engineering work.
Use Rating rationale to justify the three ratings.
Use Response to record the selected treatment.
Use Accountable owner to name the role responsible for the response.
Use Residual risk to state what could remain possible after treatment.

Return to ai-agent-threat-model.md in Visual Studio Code.
Add a Prioritized Threat Register heading below the resource-consumption branch.

You now have a dedicated section for turning attack findings into reviewable decisions.

Six Findings to Prioritize

Threat T-01 covers an unauthorized refund or outbound message requested through the broad service identity. The affected flow runs from the agent orchestrator to the refund service or outbound-message service. Its STRIDE category is Elevation of Privilege. Its mappings are LLM01:2026 Prompt Injection, LLM03:2026 Excessive Agency, LLM10:2026 Improper Output Handling, AML.T0051.001, plus AML.T0053. Rate likelihood High because public ticket content can influence the action path. Rate impact High because the action changes customer state. Set overall priority to High.
Threat T-02 covers cross-customer record exposure after a malicious ticket triggers private-data retrieval. The affected flow runs from the agent orchestrator to the customer-record store. Its STRIDE category is Information Disclosure. Its mappings are LLM02:2026 Sensitive Information Disclosure, LLM03:2026 Excessive Agency, plus AML.T0086. Rate likelihood High because the shared identity can reach records beyond one customer. Rate impact High because private data can cross account boundaries. Set overall priority to High.
Threat T-03 covers repeated tool fan-out or recursive work that consumes service capacity plus budget. The affected flow includes the agent orchestrator plus every invoked tool. Its STRIDE category is Denial of Service. Its mappings are LLM06:2026 Unbounded Consumption plus AML.T0034.002. Rate likelihood Medium because the costly branch depends on repeated execution. Rate impact High because legitimate support work can be blocked. Set overall priority to High.
Threat T-04 covers a ticket that falsely claims another customer's identity or authority. The affected flow runs from the public support interface to the agent orchestrator. Its STRIDE category is Spoofing. Its mappings are LLM03:2026 Excessive Agency plus AML.T0053. Rate likelihood Medium because the attacker must make the claim influence a privileged action. Rate impact High because another customer's account can be affected. Set overall priority to Medium.
Threat T-05 covers missing or incomplete audit evidence for model-driven tool actions. The affected flow runs from the agent orchestrator to the audit store. Its STRIDE category is Repudiation. Its mapping is LLM03:2026 Excessive Agency. Rate likelihood Medium because the baseline does not guarantee complete action records. Rate impact Medium because investigators may be unable to reconstruct a disputed action. Set overall priority to Medium.
Threat T-06 covers tampered internal policy content that steers the agent toward an unsafe decision. The affected flow runs from the knowledge base through the hosted model to the agent orchestrator. Its STRIDE category is Tampering. Its mappings are LLM01:2026 Prompt Injection plus AML.T0051.001. Rate likelihood Medium because the attacker needs influence over retrieved content. Rate impact High because poisoned policy text can steer sensitive actions. Set overall priority to Medium.

Create the register header using every field listed above.
Populate one row for each of the six starter findings.

Your register now places the three system-level attack outcomes first. Each rating has a design-specific reason behind it.

Save ai-agent-threat-model.md.
Scan the register for six populated threat IDs.

You should see T-01 through T-06. The first three rows should carry an overall priority of High.

Are Register Fields Missing?

Compare your header with the field list above. Every row needs the same twelve fields so reviewers can compare decisions consistently.

Check that each rating has a written reason. A bare High or Medium does not explain the system condition behind the score.

Ask for help reviewing the register structure: Help me find missing fields or unsupported ratings in my six-row AI-agent threat register.

Assign responses and ownership

A priority rating identifies where attention belongs. A response records what the team chooses to do about the risk.

What Do the Responses Mean?

Mitigate reduces likelihood or impact through controls.

Eliminate removes the risky capability or design condition.

Transfer moves defined responsibility or financial exposure to another party.

Accept documents a conscious decision to retain the risk.

Recommended Decisions for This Baseline

Threat T-01 has response Mitigate with the Application Security Lead as owner. An authorized approver may still approve a fraudulent request after treatment.
Threat T-02 has response Mitigate with Identity and Access Engineering as owner. Incorrect entitlement data may still expose another customer's record after treatment.
Threat T-03 has response Mitigate with Platform Engineering as owner. Allowed bursts may still reduce capacity during peak demand after treatment.
Threat T-04 has response Eliminate with the Support Platform Product Owner as owner. A stolen authenticated session may still misidentify the requester after treatment.
Threat T-05 has response Mitigate with Security Operations as owner. Privileged log administrators may still alter evidence after treatment.
Threat T-06 has response Mitigate with the Knowledge Management Owner as owner. An authorized editor may still publish harmful policy content after treatment.

Apply the recommended response to each register row.
Name the accountable owner in each register row.

Every finding now has a treatment decision plus a role that owns the follow-through.

Complete the residual-risk field for each row using the remaining possibility above.
Save ai-agent-threat-model.md.

Your register now separates the chosen response from the risk that survives it. That distinction prevents a mitigation from being mistaken for a guarantee.

Check every register row for a response.
Check every register row for an accountable owner.
Check every register row for a residual-risk statement.

You should see no blank decision fields across T-01 through T-06.

Set the top security objectives

A security objective turns a top threat into a clear outcome for the redesign. It states the protection the system must provide without pretending one control removes every possible failure.

What Should Each Objective Cover?

The unauthorized-action objective should require independent authorization for refunds plus outbound messages.

The sensitive-data objective should prevent record access outside the authenticated customer's authorized scope.

The resource-exhaustion objective should require termination of work that exceeds approved tool-call, recursion, time, or cost limits.

Add a Top-Priority Security Objectives heading below the threat register.
Write one sentence defining the required outcome for unauthorized refunds plus outbound messages.

The first objective now gives T-01 a concrete protection target.

Write one sentence defining the required outcome for cross-customer record access.
Write one sentence defining the required outcome for recursive or over-budget work.

The objective set now covers unauthorized action, sensitive-data exposure, plus resource or cost exhaustion.

Save ai-agent-threat-model.md.

✔️ Awesome, I've got everything!

Great. Your saved document now contains a prioritized register with six decisions plus three security objectives.

ⓧ I'd like to double check the full document

Compare ai-agent-threat-model.md with this cumulative document checklist.

Confirm the baseline model still records the assets, actors, trust zones, flows, plus broad service identity.
Confirm the analysis still contains concrete threats for all six STRIDE categories.
Confirm the poisoned-ticket chain still maps to LLM01:2026 Prompt Injection, LLM02:2026 Sensitive Information Disclosure, LLM03:2026 Excessive Agency, LLM10:2026 Improper Output Handling, AML.T0051.001, AML.T0053, plus AML.T0086.
Confirm the resource-consumption branch still maps to LLM06:2026 Unbounded Consumption plus AML.T0034.002.
Confirm the threat register contains at least six findings.
Confirm every row contains an ID, scenario, affected component or flow, STRIDE category, AI-framework mapping, likelihood, impact, priority, rationale, response, owner, plus residual risk.
Confirm the three High priority rows cover unauthorized action, sensitive-data exposure, plus resource or cost exhaustion.
Confirm each top-priority threat has a one-sentence security objective.

Before you inspect the top three rows, do you expect each decision to be complete enough for another engineer to challenge?

Inspect T-01, T-02, plus T-03.
Confirm each row contains likelihood, impact, priority, plus rating rationale.
Confirm each row contains a response, accountable owner, plus residual risk.
Match each row to its one-sentence security objective.

You should see three complete priority decisions. Together they cover unauthorized action, sensitive-data exposure, plus resource or cost exhaustion.

That is the decision layer complete. Next, you will redesign the agent so the highest-priority risks meet measurable security requirements.

Redesign the Agent Around Deterministic Controls

Your prioritized register now shows which failures matter most. Its top rows cover unauthorized action, sensitive-data exposure, plus resource exhaustion.

This step replaces model-mediated authorization with deterministic application controls. The model produces an untrusted proposal.

An independent policy decision point authorizes each proposal using the current user's context. Sensitive operations also require human approval.

In this step, get ready to:

Redraw the privileged path around independent authorization controls.
Map OWASP LLMSVS v2.0 requirements to enforcement components plus assessor evidence.
Convert the top risks into measurable acceptance tests plus residual-risk statements.

Redraw the privileged path

Model output can carry attacker-controlled instructions from the original ticket. A validated action proposal gives deterministic code a structured object to inspect.

The new path applies complete mediation before every privileged action. Narrow adapters plus separate identities apply least privilege during execution.

What Must the Redesigned Path Show?

Untrusted customer-ticket content enters the agent from the public support interface.
The agent sends context to the hosted model provider.
The hosted model returns output that remains untrusted.
A proposal validator accepts only the expected action format plus allowed properties.
The policy decision point receives the validated proposal plus per-user authorization context.
The policy decision point applies deterministic authorization rules.
Sensitive authorized proposals wait for human approval.
Approved requests reach narrow tool adapters that expose only required operations.
Separate read identities protect customer data plus order data.
Separate write identities restrict refunds plus outbound messages.
Destination-restricted egress permits connections only to approved services.
Structured audit events capture each security decision plus execution outcome.

In ai-agent-threat-model.md, add a level-two Markdown section named Redesigned Privileged Architecture containing a text diagram that follows every stage above.
Save ai-agent-threat-model.md.

Good progress. You can now trace a proposal from untrusted content to an approved request without giving the model authority to execute it.

Build the LLMSVS control crosswalk

A control crosswalk connects each security requirement to the component that enforces it. Assessor evidence shows whether the control exists plus whether it behaves as intended.

How Should Each Requirement Map?

Requirement 5.5 maps to the proposal validator. Evidence includes its schema plus tests that reject malformed proposals.
Requirement 5.12 maps to ticket ingestion plus context assembly. Evidence includes untrusted-data labels plus indirect-injection tests.
Requirement 5.13 maps to the output-mediation pipeline. Evidence includes traces showing that model output cannot bypass validation or authorization.
Requirement 5.14 maps to the API gateway plus budget controller. Evidence includes rate-limit configuration plus load-test results.
Requirement 6.1 maps to the tool registry plus orchestrator. Evidence includes the task-specific tool allowlist.
Requirement 6.4 maps to each narrow tool adapter. Evidence includes parameter schemas plus negative tests.
Requirement 6.7 maps to the policy decision point plus tool adapters. Evidence includes per-user authorization tests.
Requirement 6.9 maps to the egress gateway. Evidence includes its destination allowlist plus blocked-destination logs.
Requirement 6.10 maps to the credential broker plus separate read and write identities. Evidence includes token-scope policy plus identity configuration.
Requirement 6.11 maps to the human-approval service. Evidence includes an approval record created before write execution.
Requirement 8.1 maps to monitoring plus the audit pipeline. Evidence includes anomaly alerts plus tests that trigger unexpected usage spikes.

Add an LLMSVS v2.0 Control Crosswalk section with a table based on the mapping above.
Populate the table with the columns Requirement, Control intent, Enforcing component, plus Assessor evidence.

The crosswalk now contains all eleven required rows. Each row links a security expectation to a place an assessor can inspect.

Save ai-agent-threat-model.md.
Inspect each row for one named enforcing component plus one inspectable evidence source.

Your requirements now point to concrete controls plus evidence. The review can guide implementation without relying on model behavior as a security boundary.

Turn top risks into acceptance tests

Acceptance criteria turn each security objective into an observable result. Every test needs a clear denial or termination signal.

What Must the Tests Prove?

An unauthorized refund proposal is denied by the policy decision point. No request reaches the write adapter.
A user requesting another customer's records receives no private record data. The denial creates an audit event.
An outbound-message proposal targeting an unapproved destination is blocked. No egress connection reaches that destination.
Recursive work stops at the configured recursion threshold. Over-budget work stops at the configured budget threshold.
A stopped workload starts no additional model or tool calls. Its terminal event appears in the audit trail.
A successful or denied operation records the principal plus action plus target. The event includes the decision plus outcome.
Audit records exclude service credentials plus secrets plus complete sensitive prompts.

Add an Acceptance Criteria section containing one measurable test for every case above.

The new section now covers unauthorized refunds, cross-customer access, unapproved destinations, resource exhaustion, plus secret-safe auditing.

Add a residual-risk statement to every top-priority test that names what remains possible after the controls operate as designed.
Save ai-agent-threat-model.md.

Each top-priority threat now has a measurable acceptance test plus a remaining-risk decision. That closes the path from threat discovery to engineering evidence.

Before you replay the attack, ask yourself where the poisoned ticket will lose the ability to cause a refund or exfiltration.

Add a Poisoned-Ticket Replay subsection containing a trace from the malicious ticket to the attempted refund or outbound message.
Mark at least two independent stopping or containment points in the trace.

The replay should now show the attack meeting separate controls before any privileged tool executes. A bypass of one control still leaves another barrier in the path.

Read the completed replay from the ticket entry point to the attempted impact.
Confirm that at least two independent controls stop or contain the attack.
Inspect all three top-priority entries for a measurable acceptance test plus a residual-risk statement.
Save ai-agent-threat-model.md.

You should see the validator, policy decision point, human approval, scoped identities, egress restrictions, or resource controls interrupting the original chain. Every top-priority risk should also end with evidence the team can test.

✔️ My redesign is complete

Your dossier now connects the highest-priority threats to deterministic controls, assessor evidence, acceptance tests, plus residual risk.

ⓧ I'd like to double check the document

Confirm that the baseline model, attack analysis, plus prioritized threat register remain in ai-agent-threat-model.md.
Confirm that the redesigned flow treats customer content plus model output as untrusted.
Confirm that validated proposals reach an independent policy decision point using per-user authorization context.
Confirm that sensitive actions require human approval before execution.
Confirm that approved requests use narrow adapters plus separate read and write identities.
Confirm that the design includes destination-restricted egress plus structured audit events.
Confirm that the crosswalk contains requirements 5.5, 5.12, 5.13, 5.14, 6.1, 6.4, 6.7, 6.9, 6.10, 6.11, plus 8.1.
Confirm that every crosswalk row names an enforcing component plus assessor evidence.
Confirm that the acceptance criteria cover all five required security outcomes.
Confirm that every top-priority threat has a measurable test plus a residual-risk statement.
Confirm that the poisoned-ticket replay identifies at least two independent stopping or containment controls.

That's the security redesign complete. Your agent now treats probabilistic model behavior as untrusted input to deterministic security decisions.

Secret mission

Threat-Model a Poisoned Agent Tool

A trusted tool can become hostile after approval through a compromised update. Extend your security review with supplier boundaries, a poisoned-tool attack path, owned controls, a redirection test, and an honest residual-risk decision.

Clean Up Your Resources

Choose whether to keep your local work available, close it for now, or delete it entirely. This project created no cloud resources or running services, so there are no ongoing costs.

Resources you used:

The local ai-agent-threat-model workspace folder containing your completed ai-agent-threat-model.md security-engineering dossier.

Keep everything running

No action is needed. Choose this option if you want to continue refining the threat model or use it during future security reviews.

Leave the ai-agent-threat-model workspace open in Visual Studio Code if you are still reviewing it.
Keep the ai-agent-threat-model folder so the dossier remains available for future reference.

Pause - I'll come back to this later

Close the editor for now. Your complete dossier stays on your Mac for the next review session.

Close Visual Studio Code.
Use Finder to confirm that the ai-agent-threat-model folder remains in the parent folder where you created it.

Your ai-agent-threat-model.md file remains available with the baseline model, threat register, control redesign, acceptance criteria, and poisoned-tool extension.

Delete - I don't want to use this again

Deleting this folder permanently removes your completed security-engineering dossier once Finder's Trash is emptied. Choose Keep or Pause if you may want to reuse the threat model.

Close Visual Studio Code.
Return to the parent folder where you created the ai-agent-threat-model folder in Finder.
Move the ai-agent-threat-model folder to the Trash.
Empty the Trash in Finder.
Return to the parent folder in Finder.

You should no longer see the ai-agent-threat-model folder. This confirms that the workspace and ai-agent-threat-model.md dossier have been removed.

Nice Work!

You did it! You built a complete security-engineering dossier for a tool-using AI support agent. Your review now connects architecture weaknesses to prioritized risks and testable controls.

You've learned how to:

Trace customer tickets through a system-specific data-flow model. Mark every trust boundary. Identify each change in identity or privilege.
Break the trusting baseline with a poisoned-ticket attack chain. Use STRIDE, OWASP Top 10 for LLM Applications 2026, and MITRE ATLAS to classify the resulting threats.
Replace model-mediated authorization with deterministic controls. Turn OWASP LLMSVS v2.0 requirements into testable acceptance criteria.
Secret Mission: Extend the dossier to cover a poisoned third-party agent tool. Define preventive controls. Define detective controls. Test for silent data redirection. Record the remaining runtime risk.

Ready to quiz yourself?