Threat Modelling at Design Time
Before the agent is built, enumerate the attacker, attack surface, and likely attack paths — and design defences accordingly.
This page is the complete instruction page for one pattern called "Threat Modelling at Design Time." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
Guardrails retrofitted after launch address yesterday's incidents, not tomorrow's. Threat modelling at design flips the discipline: what could go wrong, and what makes it harder?
Problem
Reactive security patches are always one incident behind.
Forces
- Design-time effort vs incident response cost
- Completeness vs analysis paralysis
Solution
Conduct a structured threat-modelling workshop using OWASP LLM Top 10 and agent-specific threat catalogues as inputs. Identify: adversary profiles, assets, attack vectors, likelihood/impact. Rank threats; specify controls; encode controls as patterns below. Review quarterly and after material changes.
Applicability
- All production agents
- Particularly high-risk use cases
- Agents handling regulated data
Anti-Patterns
- "Security is the SRE team's job"
- One-time threat model never revisited
Consequences
- +Proactive defensive posture
- +Clear control-to-threat mapping
- −Specialist effort
- −Requires current threat intelligence