Why STRIDE still helps, and where it needs extension
STRIDE remains useful because it gives teams a structured baseline for threat modeling. Generative AI applications, however, introduce assets and behaviors that traditional application diagrams may not capture clearly. Prompts, retrieved context, model outputs, memory, vector stores, agents, tool calls, permissions, and runtime behavior all need to be included in the model.
The key shift is to treat natural-language inputs, external knowledge, model decisions, and autonomous actions as assets that can cross trust boundaries. This keeps the threat model connected to how the AI system actually receives information, reasons over context, invokes tools, and produces outcomes.
A practical STRIDE worksheet should add AI-specific columns for context source, agent role, tool invoked, permission scope, output consumer, runtime control, and audit evidence.
Model the AI application before mapping STRIDE
Begin with a data-flow diagram that shows how a request becomes an AI-assisted decision or action. Include user input, system and developer prompts, orchestration logic, model endpoint, retrieval ingestion, retrieval query path, vector store, memory, tool gateway, external APIs, logging, monitoring, and human approval steps.
For agentic systems, separate the planner, executor, tool registry, credential boundary, and approval mechanism.
-
Trace the request path
Show how user input, system and developer prompts, orchestration logic, model endpoint, retrieval components, memory, tools, external APIs, logging, monitoring, and approval steps contribute to an AI-assisted decision or action.
-
Mark every trust boundary
Mark trust boundaries wherever natural language or external content enters the system. This includes direct user prompts, uploaded files, web pages, emails, tickets, database records, retrieved snippets, tool responses, and third-party knowledge sources.
-
Treat model output as untrusted
Treat model output as untrusted until validated, especially when it is used to generate code, database queries, API parameters, customer communications, production changes, or security decisions.
-
Separate identities and permissions
Separate user identity, application identity, agent identity, and tool identity. Authorization should not depend on the model saying that an action is allowed.
Retrieval should preserve document-level permissions, tenant boundaries, provenance, and ingestion controls. Tool calls should execute through governed interfaces with scoped permissions, schema validation, and policy checks.
STRIDE mapping for generative AI systems
After the application model is clear, apply STRIDE across the AI-specific assets, boundaries, and actions. The mapping should cover prompts, retrieved content, model output, memory, agents, tool invocations, permissions, and runtime controls rather than focusing only on conventional services and databases.
| Worksheet column | What it captures | Why it matters |
|---|---|---|
| Context source | The origin of retrieved context, uploaded files, web pages, emails, tickets, database records, snippets, tool responses, or third-party knowledge sources. | External content can cross trust boundaries and influence model behavior. |
| Agent role | The role of the agent, including planner, executor, or other application-specific agent responsibilities. | Agent behavior should be modeled separately from user identity, application identity, and tool identity. |
| Tool invoked | The governed interface, external API, or tool endpoint used by the AI application or agent. | Tool calls can turn model output into actions, including high-impact or irreversible operations. |
| Permission scope | The permissions granted to users, applications, agents, retrieval stores, tools, and external APIs. | Authorization should not depend on the model saying that an action is allowed. |
| Output consumer | The user, system, workflow, or downstream process that consumes the model response. | Model output should be validated before it is used for code, queries, API parameters, communications, production changes, or security decisions. |
| Runtime control | The policy check, schema validation, approval gate, monitoring control, or execution constraint applied at runtime. | Identified risks need enforceable controls in production. |
| Audit evidence | The user request, context sources, model response, agent decision, tool call, approval, and final action. | Audit trails are needed to connect AI behavior to the decision or action that followed. |
STRIDE extension points for generative AI
- New assets
- Prompts, retrieved context, embeddings, memory, model outputs, agents, and tool-call arguments.
- New trust boundaries
- User input, uploaded files, web pages, email, external APIs, vector stores, and tool responses.
- New controls
- Runtime policy checks, least-privilege tool access, scoped credentials, approvals, monitoring, and audit trails.
- New evidence
- Prompt metadata, retrieved source IDs, model versions, policy decisions, approvals, and tool-call records.
Build an AI-specific STRIDE worksheet
The worksheet should connect the modeled system to concrete runtime evidence. It should not stop at describing risks. It should identify where the relevant input came from, which identity or agent acted, which tool was invoked, what permissions were available, who or what consumed the output, which control was enforced, and what audit record proves the sequence.
This structure helps teams move from diagramming to implementation. It also makes it easier to review the relationship between retrieval, permissions, tool execution, approval workflows, monitoring, and investigation.
Runtime controls to include in the threat model
Runtime controls should be included directly in the threat model so the design shows how risks will be governed in production. These controls apply across users, agents, tools, retrieval stores, external APIs, model outputs, and audit evidence.
Enforce least privilege
Limit access separately for users, agents, tools, retrieval stores, and external APIs.
Inspect before action
Apply policy controls to prompts, retrieved context, model outputs, and tool-call arguments before execution.
Validate tool inputs
Use schemas, parameter constraints, allowlists, and rate limits for tool calls.
Gate sensitive actions
Require human approval or stronger policy checks for high-impact or irreversible operations.
Preserve audit trails
Connect user request, context sources, model response, agent decision, tool call, approval, and final action.
Avoid unsafe logging
Collect enough metadata for investigation while avoiding unnecessary storage of secrets or sensitive prompt content.
Governance implications and platform evaluation
AI threat modeling should connect design-time analysis to enforceable runtime governance. STRIDE helps identify the risks, then the implementation needs policies, permissions, approvals, monitoring, and audit evidence to govern enterprise AI agents in production.
For platform evaluation, the threat model should make the required controls explicit. Teams should be able to see whether the AI application can preserve document-level permissions, maintain tenant boundaries, keep provenance, control ingestion, scope credentials, validate tool parameters, apply policy checks, require human approval where needed, and retain enough audit evidence for investigation.
- Use STRIDE as a structured baseline for generative AI applications.
- Extend the model to prompts, retrieved context, model outputs, memory, vector stores, agents, tool calls, permissions, and runtime behavior.
- Mark trust boundaries wherever natural language or external content enters the system.
- Separate user identity, application identity, agent identity, and tool identity.
- Keep authorization outside the model response.
- Use scoped permissions, schema validation, policy checks, monitoring, and audit trails for tool execution.