Template
A threat model template for one agent.
A one-page structure for modeling an agent before it reaches production: what it is, what it can reach, and how its authority is bounded. Run it in a 60–90 minute workshop with the agent owner, a security architect, and the engineer who ships it.
How to use it
One agent. One page. One owner.
Pick a single agent that can take a real action. Bring the person who owns it, someone who can read the architecture, and the engineer who controls its tools. Fill the template together, out loud.
The goal is not a perfect document. It is to make three things explicit: what the agent can reach, who it acts for, and what happens when it is wrong. Version the result; the model only stays useful if it changes when the agent does.
Scope
- Agent name, owner, and purpose
- Who it acts for, and who can invoke it
- Environment and autonomy level
- Model provider and version
Tools and data
- Every tool it can call, and what each one changes
- Data classes it can read, and where they live
- Side effects that cannot be undone
- Least-privilege scope per tool
Identity and delegation
- Workload identity and credential lifetime
- Delegation chain, and where it stops
- Human approval gates for consequential actions
- Revocation path and who can trigger it
Trust boundaries
- Entry point and caller authentication
- Tool gateway and policy enforcement point
- Data services and model provider
- Where logs and attribution are captured
Threats and abuse cases
- Threat and abuse case, in one sentence
- Mapping to STRIDE and MITRE ATLAS
- Impact if it succeeds
- Control and named owner
Evidence
- Model version and date
- Assumptions and open decisions
- Test cases that prove the controls
- Monitoring and re-model triggers
Worked example
A payment support agent, filled in.
A hypothetical agent with one tool that can move money. Notice how much of the model is identity and permission, not prompt text.
- Agent and owner
- Payments support agent · Payments Platform
- Purpose
- Answer customer questions and issue small refunds
- Tools
- order.read, customer.read, refund.create
- Identity
- Workload identity, 15-minute credentials
- Delegation
- On behalf of a support rep; approval above $500
- Boundaries
- Tool gateway, data service, model provider
- Revocation
- Scoped token revoked at the gateway; agent disabled in minutes
Threat register
| Threat | Mapping | Control | Owner |
|---|---|---|---|
| Goal hijack via injected content | ASI01 / AML.T0051 | Scoped tools, approval gate | Agent Platform |
| Refund limit bypass | ASI02 / tool misuse | Gateway policy, dual approval | Payments Platform |
| Delegated token outlives the session | ASI03 / T1550 | 15-minute credentials, revocation | Identity |
Keep the model alive
What good looks like
Three tests for the finished model.
- 01
It names a limit
Every tool has a scope, and every consequential action has a gate or a documented reason it does not.
- 02
It survives an incident
You can answer who acted, on whose behalf, with what credential, and how it was revoked.
- 03
It changes
The model has a version and a trigger, and the current version matches the deployed agent.
Bring one agent
Run the template against a real agent.
A scoped pilot models one agent, its tools, and its delegation chain, then reviews the output with your security architects.