Frame the decision and harm
Write the launch, authority, risk-acceptance or remediation decision the model must support. Name the highest credible impact to people, money, data, operations and trust.
Field guide / agentic threat modeling
AI agent threat modeling: map authority before production.
A threat model turns an agent's autonomy into an explicit decision: what can act, what can influence it, what can persist, what can leave the system and what evidence proves that the boundaries hold.
Direct answer
Model the control plane, not just the prompt
Start with the business decision and credible harm. Then map human, service and agent identities; delegated authority; tools, APIs and MCP/A2A boundaries; retrieved context and memory; secrets and egress; third parties; approvals; and recovery. Rank the paths that could cross those boundaries, attach evidence and assign an owner to each control gap.
Six moves for a useful model
Map assets and data flows
Draw the agent, model, tools, APIs, data stores, identities, queues and third parties. Mark where sensitive data enters, transforms, persists and leaves.
Inventory authority
For every human, service and agent identity, record what it can read, write, spend, publish or delegate. Prefer action-time least privilege, attribution and revocation over trust in a prompt.
Mark context and memory boundaries
Separate user instructions, retrieved content, tool output and policy. Identify prompt injection, cross-agent influence, poisoned retrieval and durable writes that could silently become future authority.
Trace tools, side effects and egress
Classify every tool and resource as read, write, spend, message, upload or control. Constrain destinations, secrets, payloads, retries and approvals; treat MCP and A2A as trust boundaries, not identity proof.
Model failure and recovery
Ask what happens when a tool lies, times out, partially succeeds or is unavailable. Prove pause, revocation, replay safety, incident ownership and a path to recover without duplicating irreversible effects.
Abuse cases worth ranking
Untrusted content becomes policy
Retrieved text, a tool response or a memory write is treated as an instruction and expands what the agent is allowed to do.
Delegated authority drifts
A service token, role or workflow gives the agent more access than the decision requires, with no independent revocation path.
Side effects hide behind reads
A tool that looks informational can spend, upload, message, alter durable state or trigger a second system without preview or approval.
Failure repeats the harm
Retries, queues or partial results duplicate an irreversible action because idempotency, correlation and recovery were not modeled.
Evidence to prepare
- A system, trust-boundary and data-flow diagram with environments and third parties.
- Identity, permission, tool/resource and approval inventories with revocation owners.
- Data classification, retention, secret-handling and egress rules for each path.
- Representative logs or traces showing caller, input, destination, result and side effect.
- Failure, incident, pause and recovery procedures, including replay and rollback assumptions.
- Known changes, dependencies and open questions that could invalidate the model.
What the deliverable says
A decision-grade threat model states scope, assumptions and exclusions; shows the control plane and trust boundaries; ranks plausible abuse cases by impact and preconditions; maps controls to evidence; and records residual risk with an accountable owner.
It is a living artifact. Revisit it before adding tools, memory, sensitive data, spend, autonomy or a material dependency, and after an incident or architecture change.
Need a bounded engagement?
Start with the five-minute readiness checklist → or compare the agentic threat-model sprint →
Safety boundaries
- Defensive work only, on systems owned by the requester or explicitly authorized in writing.
- Architecture and documentation come first; active techniques require exact scope, timing, contacts and stop rules in written Rules of Engagement.
- No unbounded scanning, denial of service, destructive testing, persistence, social engineering or third-party targeting by default.
- A threat model is not a certification, a guarantee or evidence that an unmodeled release is safe.
Further reading
Direct answers
What is an AI agent threat model?
It is a structured map of an agent system's assets, identities, authority, trust boundaries, tools, data flows, failure paths and credible abuse cases. The result is a prioritized set of controls and evidence for a real decision, not a generic list of threats.
How is threat modeling different from an AI agent security review?
Threat modeling frames risk from the architecture and intended authority before or alongside implementation. A security review verifies authorized behavior and evidence in a bounded scope. A model can define what the review must prove; it cannot replace that verification.
What should an AI agent threat model cover?
At minimum, map the decision and impact, identities and delegated authority, tools and side effects, prompt and retrieval trust, memory and durable writes, secrets and egress, third-party dependencies, human approvals, failure behavior and recovery.
Does threat modeling require active security testing?
No. Start with architecture, data flows, contracts and benign evidence. Any active technique must use owner-approved scope and written Rules of Engagement with exact assets, timing, contacts and stop conditions.
Does a threat model certify that an AI agent is secure?
No. It records assumptions, plausible abuse paths, controls, evidence gaps and residual risk for the modeled scope. It is not a certification, a guarantee or a substitute for ongoing verification after the system changes.