AI Threat Modeler
Create a review-ready threat model that distinguishes documented architecture from
assumptions. Stop at test design unless the approved scope explicitly authorizes execution.
Workflow
- Record the system owner, approved scope, environment, build, model/provider and version,
prompt/configuration revision, data stores, tools, and supplied architecture artifacts.
- Map assets, actors, entry points, data flows, trust boundaries, external providers,
retrieval, memory, tool calls, logs, and administrative paths. Mark absent details
Not specified.
- Derive abuse cases for instruction manipulation, unauthorized access, data disclosure,
unsafe output, excessive agency, availability, and supply-chain dependencies. Tie every
case to a documented component or label it
Hypothesis.
- Map each abuse case to an existing control, a safe staging test, evidence to capture,
impact, likelihood rationale, and residual risk. Use synthetic identities, records,
secrets, and canaries.
- Prioritize a test charter without claiming complete coverage. Route prompt injection,
leakage, tool authorization, content safety, and fairness cases to their specialist skills.
- Present the model and charter as a draft for the security and system owners to approve.
Evidence register
Classify every statement as Observed, Inferred, Hypothesis, or Not tested.
| Classification |
Source / run ID |
Expected control |
Observed result |
Evidence artifact |
Unresolved gap |
| Not tested |
architecture section or test ID |
documented control |
no run performed |
source link or none |
missing fact or planned validation |
Record exact build, model, prompt, policy, guardrail, tool, corpus, and environment versions
where applicable. Use Not tested for all proposed cases until execution evidence exists.
--- HUMAN REVIEW GATE ---
Unverified items:
Remaining risks:
Required approver:
Decision: approve / revise / reject
Guardrails
- Run only in an explicitly authorized staging or sandbox environment using synthetic inputs.
If authorization or isolation is absent, stop at the draft charter.
- Never fabricate an architecture fact, policy, control, test result, metric, source, trace,
or evidence link. Record missing information as
Not specified.
- Never claim the system is safe, secure, compliant, certified, or fully covered from a threat
model, an incomplete test set, or missing evidence.
- Treat risk ratings and control effectiveness as proposals until the named human approvers
confirm them.
1---2name: ai-threat-modeler3description: Build an evidence-backed threat model and authorized test charter for an AI, LLM, RAG, or agent system. Use when a tester needs to map assets, actors, trust boundaries, model and provider dependencies, memory, retrieval, tools, abuse cases, controls, and residual risk before safety or security testing begins.4license: MIT5---67# AI Threat Modeler89Create a review-ready threat model that distinguishes documented architecture from10assumptions. Stop at test design unless the approved scope explicitly authorizes execution.1112## Workflow13141. Record the system owner, approved scope, environment, build, model/provider and version,15 prompt/configuration revision, data stores, tools, and supplied architecture artifacts.162. Map assets, actors, entry points, data flows, trust boundaries, external providers,17 retrieval, memory, tool calls, logs, and administrative paths. Mark absent details18 `Not specified`.193. Derive abuse cases for instruction manipulation, unauthorized access, data disclosure,20 unsafe output, excessive agency, availability, and supply-chain dependencies. Tie every21 case to a documented component or label it `Hypothesis`.224. Map each abuse case to an existing control, a safe staging test, evidence to capture,23 impact, likelihood rationale, and residual risk. Use synthetic identities, records,24 secrets, and canaries.255. Prioritize a test charter without claiming complete coverage. Route prompt injection,26 leakage, tool authorization, content safety, and fairness cases to their specialist skills.276. Present the model and charter as a draft for the security and system owners to approve.2829## Evidence register3031Classify every statement as `Observed`, `Inferred`, `Hypothesis`, or `Not tested`.3233| Classification | Source / run ID | Expected control | Observed result | Evidence artifact | Unresolved gap |34|---|---|---|---|---|---|35| Not tested | architecture section or test ID | documented control | no run performed | source link or none | missing fact or planned validation |3637Record exact build, model, prompt, policy, guardrail, tool, corpus, and environment versions38where applicable. Use `Not tested` for all proposed cases until execution evidence exists.3940--- HUMAN REVIEW GATE ---41Unverified items:42Remaining risks:43Required approver:44Decision: approve / revise / reject4546## Guardrails4748- Run only in an explicitly authorized staging or sandbox environment using synthetic inputs.49 If authorization or isolation is absent, stop at the draft charter.50- Never fabricate an architecture fact, policy, control, test result, metric, source, trace,51 or evidence link. Record missing information as `Not specified`.52- Never claim the system is safe, secure, compliant, certified, or fully covered from a threat53 model, an incomplete test set, or missing evidence.54- Treat risk ratings and control effectiveness as proposals until the named human approvers55 confirm them.
PramodDutta