To threat model an AI agent, draw its architecture, mark every trust boundary, and then enumerate threats per component. Two frameworks do most of the work together. MAESTRO, from the Cloud Security Alliance, gives you a layered map of an agentic system, so you do not forget a layer such as the agent framework, the evaluation pipeline, or other agents in the ecosystem. STRIDE gives you a checklist of threat types (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) to apply at each component on that map. Then rank threats by what the agent can actually do with its tools and permissions, and record a control and owner for each.
Why classic threat modeling is not enough on its own
STRIDE was built for systems where code decides what happens and data is passive. In an agent, data can carry instructions. A document retrieved into context, a web page, a ticket comment or the output of another tool can steer what the agent does next. That collapses the line between data flow and control flow that most threat models rely on.
Agents also add actors classic diagrams lack: the model provider, the orchestration framework, MCP servers and their tool descriptions, memory stores, and other agents that delegate work. Each is a component with its own trust level. Applying STRIDE only to the API in front of the agent misses most of them.
MAESTRO in brief
MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome) was published by the Cloud Security Alliance in February 2025. It describes an agentic system in seven layers:
- Foundation models: the model itself and its provider.
- Data operations: training data, retrieval stores, embeddings and memory.
- Agent frameworks: orchestration code, prompts and tool-calling logic.
- Deployment and infrastructure: runtimes, containers, networks, secrets.
- Evaluation and observability: tests, monitoring and logs.
- Security and compliance: controls and policy, which cut across the other layers.
- Agent ecosystem: users, tools, external services and other agents the agent interacts with.
The value is coverage. It prompts you to look at threats inside a layer (a poisoned vector store) and across layers (a compromised tool output in layer 7 driving an action through the framework in layer 3).
MAESTRO vs STRIDE: how they fit together
| STRIDE | MAESTRO | |
|---|---|---|
| What it is | A taxonomy of six threat types | A layered reference model of agentic systems |
| Question it answers | What can go wrong at this component? | Where in the system can things go wrong? |
| Agent-specific | No; general software | Yes; built for agents and multi-agent systems |
| Strength | Familiar, systematic, easy to teach | Covers model, data, framework and ecosystem layers |
| Gap | No notion of instructions hidden in data | Less prescriptive about threat categories per component |
| Best use | Enumerating threats per box on the diagram | Making sure the diagram has all the boxes |
They are complementary. Use MAESTRO to build the diagram, then walk STRIDE over each component and each trust boundary.
Step by step: threat modeling one agent
1. Define the agent and its job
Write one paragraph: what the agent is for, who invokes it, and what a successful run looks like. Name the identity it acts as. An agent acting with a user's delegated rights has a different threat model from one using its own service credentials.
2. List what it can reach
Enumerate every tool, API, MCP server, data store and downstream agent, with the permission scope for each. This list sets the ceiling on damage. The over-broad MCP tool scope threat model shows how excess scope becomes attack surface.
3. Draw the system across MAESTRO layers
Place the model, retrieval, memory, framework, runtime, monitoring and external parties on one diagram. Mark trust boundaries wherever content from a less-trusted source enters the agent's context, and wherever the agent's output triggers an action.
4. Apply STRIDE per component and boundary
Agent-flavoured examples:
- Spoofing: a tool server or peer agent impersonates a trusted one; a stolen agent credential is replayed. See agent credential theft.
- Tampering: instructions planted in retrieved documents or tool descriptions; poisoned memory. See indirect prompt injection.
- Repudiation: no record of which agent called which tool with which arguments.
- Information disclosure: the agent sends sensitive context to an external tool, a model provider or an attacker-controlled URL.
- Denial of service: runaway loops, recursive delegation or token spend that exhausts budgets.
- Elevation of privilege: injected content makes the agent use permissions its invoker does not have, the confused-deputy pattern.
5. Rank by blast radius
Score each threat on likelihood and impact, where impact is bounded by what the agent can reach in step 2. A tampering threat against a read-only summariser and the same threat against an agent with payment tools are different rows with different priorities.
6. Assign controls and owners
For each ranked threat, pick a control class: reduce scope, filter input or output, require approval for the action, monitor and alert, or accept with justification. Give each one owner and a review date, and record it in your AI agent risk register.
7. Test the model
Turn the top threats into red team scenarios and regression tests, so the model is checked against behaviour, not only reviewed on paper. AI red teaming tools compared covers where scanners help and where agent context must be added.
Common mistakes
- Modelling the model, not the agent. Jailbreak resistance matters less than which tools a successful jailbreak can reach.
- Trusting tool output. Results from search, retrieval or another agent are attacker-reachable input, even when the tool itself is internal.
- One model per platform. Two agents on the same framework with different tools have different threat models. Model each agent, or each agent class with identical scope.
- A document nobody updates. A threat model written at launch is stale after the first new tool. Tie reviews to change events, not to the calendar alone.
Checklist: AI agent threat model
How Praesidia fits
Praesidia's published scenario threat models (indirect prompt injection, agent credential theft and over-broad MCP tool scope) are worked examples of steps 4 to 6. In the product, the work maps onto discover, secure and prove. Discover: the agent inventory and topology view answer step 2, listing what each agent connects to. Secure: scoped MCP connections, guardrails with block, redact and warn dispositions, human-in-the-loop approvals and a kill switch are the control classes you assign in step 6. Prove: tool calls and policy decisions that pass through Praesidia land in a signed, tamper-evident audit trail, which addresses repudiation for that traffic. For the wider control map, see the AI agent security guide.