AI Agent Threat Model Template

Teams that threat model AI agents often produce a workshop diagram and a list of worries, but no record that says which assets are at stake, which threats were accepted and which controls must be in place before go-live. This template gives you that record and the policy that requires it. It sets out when an agent threat model is mandatory, who completes and approves it, and the minimum content: an asset and identity register, a threat register mapped to the OWASP Top 10 for Agentic Applications (ASI01 to ASI10), OWASP's agentic threat taxonomy (T1 to T15) and MITRE ATLAS, and a control register with owners and tests. It is written for security architects, AI platform owners and the risk or governance leads who sign agents off. For the workshop method itself, use the AI Agent Threat Modelling Guide; this page is the document you fill in.

How to use this template

Replace text in square brackets, such as [Organisation], [Security architecture team] and [AI governance board], with your own terms.
"Must" is mandatory; "should" is recommended practice where a documented exception may apply.
Section 4 contains the policy statements and, in 4.3 to 4.5, the three registers every threat model must contain. Copy the register tables into your own tooling (a spreadsheet, a threat modelling tool or the agent registry).
Answer the four questions of the Threat Modeling Manifesto in the record: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job?
Pair this template with the Agentic AI Risk Assessment Template (which tiers the agent) and the AI Agent Security Testing Checklist (which verifies the controls).

1. Purpose

This document sets the requirements for threat modelling AI agents at [Organisation]. It ensures that, before an agent receives access to production systems or data, [Organisation] has recorded what the agent can reach, what could go wrong, which controls reduce each risk, who owns them and how they will be tested, and that this record is kept current as the agent changes.

2. Scope

This document applies to every AI agent that can take actions, call tools or APIs, or hold credentials in [Organisation] systems, including:

Agents built in-house on any framework, and agents built by staff on low-code or no-code platforms.
Third-party agents and AI features that act on [Organisation] data through OAuth grants, API keys or connectors.
AI coding agents with access to [Organisation] repositories, pipelines or cloud accounts.
Multi-agent systems, including orchestrators and the agents they call.
MCP servers, tools and plugins used by in-scope agents.

Chat assistants with no tools, no memory beyond the session and no credentials are out of scope, unless [AI governance board] decides otherwise.

3. Roles and responsibilities

Role	Responsibility
[Agent owner]	Requests the threat model, provides purpose and "must never" statements, accepts residual risk up to their authority, keeps the record current
[Lead developer]	Supplies architecture, tool list, data flows and identity design; implements engineering controls
[Security architect]	Facilitates, completes the threat register, rates risks, proposes controls, signs the record as complete
[IAM or NHI team]	Validates the identity and credential register: scopes, lifetimes, storage, ownership
[Data owner]	Confirms data classification and the impact of disclosure, corruption or loss
[Test lead]	Turns each control into a test case and reports results
[AI governance board]	Approves threat models for high-risk agents, accepts residual high risks, approves exceptions

4. Policy statements

4.1 When a threat model is required

Every in-scope agent must have an approved threat model before it receives production credentials or production data.
The threat model must be updated, and re-approved where risk increases, when any of these change: model or model provider; system prompt or goals; tools, MCP servers or plugins; credential scopes or delegation model; data sources or memory design; autonomy level or approval points; connection to other agents.
Threat models for high-risk agents must be reviewed at least [every six months]; others at least [annually].
A significant incident or test finding involving the agent must trigger a review within [10 working days].

4.2 Minimum content

A one-sentence purpose and a list of actions the agent must never take.
An architecture diagram showing the agent, model, orchestrator, memory, tools and MCP servers, downstream systems, users, other agents and trust boundaries, with every untrusted input channel marked.
The asset and identity register (4.3), the threat register (4.4) and the control register (4.5).
A coverage statement confirming each of ASI01 to ASI10 was considered, with a reason for any marked not applicable.
Coverage of the seven layers of the CSA MAESTRO framework (foundation models; data operations; agent frameworks; deployment and infrastructure; evaluation and observability; security and compliance; agent ecosystem) and of threats that cross layers.
Residual risk, the person who accepted it, and the date.

4.3 Asset and identity register

Every asset the agent can read, change or act through must be listed. Identities and credentials must be listed as assets in their own right, because they set the impact of every threat.

Field	What to record	Example
Asset ID	Unique reference	A-04
Asset type	Data store, tool, MCP server, memory, model, credential, agent identity, downstream agent, approval channel	Credential
Description	What it is and where it lives	Identity provider API token for account unlock
Access the agent has	Read, write, execute, delete, send, approve; scopes or roles	Unlock and MFA reset for standard users
Lifetime and storage	Token lifetime, rotation, where held	1 hour, issued by workload identity, never stored
Classification and impact	Data classification; worst result if misused	Confidential; account takeover
Owner	Named person or team	[IAM team]
Trust source	Who can write to it or influence it	Internal only

4.4 Threat register

Each threat must be recorded with its entry point, the assets it affects, a rating and its framework mapping. The table below gives the minimum starting set; add threats specific to the agent.

Threat	OWASP Agentic 2026	OWASP T-ID	MITRE ATLAS	Typical assets affected
Planted instructions in email, documents, web or tool output redirect the agent's goal	ASI01 Agent Goal Hijack	T6	AML.T0051.001	Every tool and credential
Agent misuses an approved tool, for example to send data out or delete records	ASI02 Tool Misuse and Exploitation	T2	AML.T0053, AML.T0086, AML.T0101	Mailbox, file stores, business systems
Over-scoped or stolen agent credentials used beyond purpose	ASI03 Identity and Privilege Abuse	T3, T9	AML.T0083, AML.T0098	Agent identity, tool credentials
Malicious or altered MCP server, plugin, package or model	ASI04 Agentic Supply Chain Vulnerabilities	T2, T11	AML.T0010, AML.T0110	Tool credentials, all data the tool sees
Generated or retrieved code runs outside its sandbox	ASI05 Unexpected Code Execution	T11	AML.T0053	Host, environment secrets
Poisoned memory or RAG content alters later decisions	ASI06 Memory and Context Poisoning	T1	AML.T0080, AML.T0070	Memory store, vector database
Spoofed, tampered or replayed messages between agents	ASI07 Insecure Inter-Agent Communication	T12	AML.T0080.001	Downstream agents
One agent's error or compromise spreads through a workflow	ASI08 Cascading Failures	T5	AML.T0034.002	Shared systems, budgets
Approvers misled or overwhelmed into approving harmful actions	ASI09 Human-Agent Trust Exploitation	T10, T15	None mapped	Approval channel
Agent acts outside its purpose or monitoring, including actions no one can attribute	ASI10 Rogue Agents	T7, T8, T13	AML.T0081	Logs, every asset

Each threat must be rated for likelihood and impact on [Organisation]'s risk scale ([High / Medium / Low] or [1 to 5]). Impact must be judged from the access recorded in the asset and identity register, not from what the model is expected to do.
Each threat must also be checked against STRIDE for the components and flows it touches: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
Threats rated high must have at least one preventive control that does not rely on the model following instructions.

4.5 Control register

Each high and medium threat must have one or more controls recorded with: control ID, description, type (reduce access, enforce outside the model, isolate, detect and respond), owner, implementation status, the test that verifies it and the date last tested.
Controls held only in the system prompt must not be recorded as preventive.
Controls should prefer, in order: removing the tool or permission; narrowing scope or lifetime; enforcing policy at the gateway, tool or target system; human approval for named actions; detection and a tested kill switch.
Every control must be traceable to a test case in the AI Agent Security Testing Checklist or an equivalent.

4.6 Approval and storage

Threat models must be stored with the agent's registry entry and versioned.
Agents rated high risk require approval by [AI governance board]; others by the [Security architect] and agent owner.
Residual high risks may only be accepted by [AI governance board], with a review date no more than [six months] ahead.

5. Exceptions

An agent may go live without a completed threat model only for a time-limited pilot that uses no production credentials or production data. Any other exception must be requested by the agent owner, assessed by [Security architecture team], approved by [AI governance board], recorded with compensating controls (for example, read-only access and approval on every action) and an expiry date no later than [30 days], and reviewed before expiry.

6. Compliance and monitoring

Coverage: percentage of in-scope production agents with an approved, in-date threat model (target [100 per cent]).
Currency: number of agents whose tools, scopes or model changed since their last approved threat model.
Control completion: percentage of high-risk controls implemented and tested before go-live.
Test linkage: percentage of controls with a passing test in the last [quarter].
Escape rate: incidents or test findings involving a threat that was not in the register.

[Security architecture team] reports these measures to [AI governance board] [quarterly]. Agents found operating without an in-date threat model may be suspended. Compliance is checked through the agent registry, change records and internal audit.

7. Review and approval

This document is owned by [policy owner] and approved by [AI governance board]. It must be reviewed at least annually, and sooner when OWASP, MITRE ATLAS or [Organisation]'s agent platforms change significantly.

Version	Date	Author	Approved by	Summary of change
[1.0]	[Date]	[Name]	[Name, role]	[Initial version]

Implementation guidance

Start with agents already live. Complete the asset and identity register for the two or three agents with the broadest credentials. The register alone usually shows the highest risks.
Reuse the starting threat set. Use the threat register in 4.4 as a baseline and add agent-specific threats; do not invent new categories. OWASP's Agentic AI Threats and Mitigations document (T1 to T15) gives further detail on each threat and six mitigation playbooks.
Size the effort to the agent. A single agent with read-only tools can be recorded in an afternoon. Multi-agent systems need one record per agent plus a system-level record for cross-agent and cross-layer threats. Small organisations can keep the registers in a spreadsheet; large ones should link them to the agent registry so a change in scopes or tools flags the threat model as out of date.
Record MCP-specific threats. For agents using MCP, include confused deputy, token passthrough, session hijacking and local server compromise, which the MCP security best practices describe with required mitigations. See the MCP Security Guide.
Close the loop with testing. A threat model is complete only when each control has a test result. Feed confirmed findings back as new threats.

Framework mapping

Template section	NIST SP 800-53 Rev. 5	NIST CSF 2.0	NIST AI RMF
4.1, 4.2 Requirement and content	SA-11(2) Threat Modeling and Vulnerability Analyses, SA-8	PR.PS-06	Map
4.3 Asset and identity register	RA-3, AC-6	ID.RA-01	Map
4.4 Threat register and rating	RA-3	ID.RA-04	Measure
4.5 Control register and tests	SA-11, CA-8	ID.IM-02	Manage
4.6 to 7 Approval, monitoring, review	CA-2	GV.RM	Govern

This mapping is NHI Mgmt Group's reading of where each section fits. The NCSC Guidelines for Secure AI System Development also place threat modelling within secure design.

Common failure patterns

Identities left off the register: impact is guessed rather than read from scopes.
Prompt-only controls: "the system prompt forbids it" recorded as prevention.
No trigger for change: new tools added months after approval with no update.
Agents modelled in isolation: cross-agent and supply chain threats never recorded.

Standards and references

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: OWASP Top 10 for Agentic Applications Guide · Agentic AI Security Guide · MITRE ATLAS Guide · Prompt Injection Guide · Agentic AI Security Policy Template

AI Agent Threat Model Template: Assets, Threats and Controls