W-03 · Case study
Threat-Modeling AI Workflows
A multi-framework threat model for AI-augmented engineering workflows — so an agent-adoption decision could be made on mapped risk instead of vendor marketing.
- Role
- Author — threat model, risk analysis, evidence packaging
- Timeframe
- 2026 — present
- Tags
- security · threat modeling · AI adoption
Context
Adopting AI across engineering workflows changes the threat surface in ways generic security checklists don’t capture. The interesting risks are rarely inside any one tool. They live in the seams: what an agent is trusted to do, what it can reach, what a human is assumed to be checking, and what happens when that assumption quietly stops holding.
That calls for two things at once — an honest technical account of what could go wrong, and an artifact rigorous enough to survive a reader who arrives with no context and no goodwill.
What I built
A full STRIDE analysis of AI-augmented engineering workflows, worked stage by stage across every STRIDE category — plus the cross-stage findings that only surface when the system is examined whole.
For one specific agent-adoption decision — integrating an AI coding agent with a source-code platform — I built a multi-framework evaluation combining STRIDE, MAESTRO, the OWASP LLM and Agentic Top 10s, LINDDUN, attack trees, and the NIST AI RMF.
The composition is the point. No single framework covers agentic risk: STRIDE has no real account of privacy, LINDDUN none of autonomy, and the OWASP lists are checklists rather than models. Running them together — and reconciling where they disagree — is what turns “the vendor says it’s secure” into a mapped, arguable risk picture.
The output is structured as a navigable evidence package rather than a single monolith: a landing page with focused child documents, each claim traceable to its supporting material. A document nobody can navigate protects nobody.
Design decisions
Threat models rot when they are written once and filed. This one went through repeated cold-auditor revision cycles — re-reading the whole package as that reader with no context and no goodwill, then fixing the places it leaned on an unstated assumption. It is the cheapest way I know to find the passages that are convincing only to their author.
The deeper choice is treating security work as an enablement function. A threat model does not exist to say no to AI adoption. It exists to make yes defensible.
Impact
An adoption decision that would otherwise have rested on vendor claims was instead grounded in risk mapped across frameworks — with the reasoning written down, navigable, and open to challenge.