Systematically identifies threats to a system by mapping data flows, defining trust boundaries, and enumerating adversaries and misuse cases before shipping. This produces a security-focused diagram and prioritized mitigation list that makes subsequent security reviews faster and more substantive than starting from a generic checklist.
Use cases
- Designing a new microservice that will handle user authentication and personal data
- Before launching a new feature that exposes an API to third-party developers
- Evaluating the security implications of an AI agent's tool access permissions
- Preparing for a compliance audit (SOC 2, ISO 27001) that requires documented threat assessments
- Reviewing a proposed architecture for a payments integration where financial data is in scope
Key features
- Draw the system as actors, data stores, data flows, and trust boundaries—focus on where data crosses a boundary between trusted and untrusted zones
- For each data flow across a trust boundary, identify what could go wrong: interception, tampering, spoofing, repudiation, information disclosure, denial of service, and elevation of privilege (STRIDE)
- List the most likely misuse cases for the system based on the actors involved and the value of the data at stake
- Prioritize mitigations based on the severity of the threat and the cost and complexity of the mitigation, focusing on systemic fixes over compensating controls
- Assign an owner and a timeline to each mitigation and verify the fix is implemented before the feature ships
When to Use This Skill
- When designing a new service or feature that handles sensitive data or exposes new attack surfaces
- When an AI agent is being granted tool access that could be abused if the agent is compromised
- When preparing for a compliance audit that requires documented threat assessments
Expected Output
A threat model diagram with trust boundaries, enumerated misuse cases using STRIDE, and a prioritized list of mitigations with owners and timelines.
Frequently Asked Questions
- Does threat modeling need to be elaborate and formal?
- No—a lightweight session of 1-2 hours with the right people (architect, security-minded engineer, product manager) produces better results than a months-long formal process that becomes outdated before it is finished.
- What is the difference between threat modeling and a penetration test?
- Threat modeling is a proactive, structured analysis of what could go wrong before building. Penetration testing is a reactive verification of what an adversary can actually exploit after building. Do threat modeling first; penetration testing validates the mitigations.
- How do I handle threats from the AI agent itself, not just external adversaries?
- Treat the AI agent as an untrusted actor in your threat model. Define what the agent is permitted to do, what data it can access, and what confirmation is required before it takes high-stakes actions. Model the consequence of a compromised or misprompted agent.
Related
Related
3 Indexed items
Brainstorming before build
Explores goals, constraints, risks, and design options before committing to a specific implementation path. This technique is most valuable when facing product or UX decisions where the wrong choice is expensive to reverse—new features with uncertain user value, architectural pivots, or cross-functional dependencies where each team has a different mental model of the problem.
Context-Aware QA Skill
Context-Aware QA is a prompting technique where an AI model is instructed to retrieve and cite authoritative sources before answering factual questions. By combining retrieval-augmented generation (RAG) with explicit verification instructions, it dramatically reduces hallucinations in production AI systems.
OpenAI documentation lookup
Prioritizes official OpenAI documentation, model cards, and API references when researching integration details, model capabilities, or API behavior changes. This avoids the noise and staleness of third-party blog posts that may summarize older model versions or incomplete information.