AI Threat Modeling: Agent-Driven Architecture Reviews Without Replacing Architects
Illustrated by Jeff Prymowicz
Architecture review still has a calendar problem and the calendar is usually losing.
Engineering teams can open a pull request, ship infrastructure, add a SaaS integration, and change data flows before the security architect has found a free hour. The design phase is where some of the cheapest security decisions happen. It is also where security still depends on a small number of senior people reading diagrams, ADRs, IaC, API specs, and tickets by hand.
The review queue loses.
Agents can help, but only if the job is framed honestly. An agent can draft the review packet. It can extract assets, list data flows, mark likely trust boundaries, generate STRIDE prompts, sketch attack trees, and propose mitigations. It cannot accept risk. It cannot know whether the diagram reflects production. It cannot decide that a payment flow is worth the business tradeoff.
The useful pattern is simple: the agent drafts, the architect judges.
That is the design-time companion to the previous post on AI agent code review security. Pull-request review catches risk when code changes. Architecture review catches risk while the system is still negotiable.
The bottleneck: architecture and threat-model reviews outgrow headcount
Threat modeling has never failed because architects dislike it. It fails because the math is bad.
One or two senior security people may be covering dozens of product teams. Each team is changing services, identity flows, cloud resources, data stores, and third-party integrations. The work that needs review grows with engineering velocity. The review capacity does not.
When the math breaks, teams get one of two outcomes.
Security becomes the department of no. Design reviews need weeks of lead time, architects sit in every meeting, and product teams learn to avoid the process until late in the cycle.
Or the risk goes invisible. Teams ship unreviewed designs because nothing in the delivery path made the review real. The failure shows up later as tenant isolation bugs, unclear data ownership, missing audit events, overbroad IAM, weak egress controls, or a SaaS integration nobody threat-modeled.
Neither outcome is a maturity model.
CSP's article on risk assessments makes the point that risk work exists to support decisions. The follow-up on maturity models explains why security programs need repeatable practices, not heroic one-off reviews.
Agent-assisted threat modeling fits there. The practice stays intact; the intake gets less painful.
What an agent can and cannot do in a design review today
Treat the agent like a fast junior analyst with no sign-off authority.
That analyst can read a pile of design material and come back with a useful first draft. The agent can turn an architecture description into an inventory of actors, processes, data stores, data flows, external dependencies, trust boundaries, and sensitive data. It can compare the design against a known framework such as OWASP's threat modeling guidance or Microsoft's STRIDE-centered Threat Modeling Tool.
It can catch boring omissions. No TLS on a boundary-crossing flow. No clear owner for a sensitive data store. A Terraform change that creates public reachability next to a permissive role. A webhook without replay protection. A RAG system that indexes support tickets without permission-aware retrieval.
Boring omissions consume review time senior architects should spend elsewhere.
The agent is weaker where threat modeling gets interesting.
It lacks the context behind an internal API bypassing the normal gateway for a legacy migration. It cannot read the product team's risk appetite from the diagram. A low-revenue workflow with a manual fallback may justify a higher denial-of-service risk. A privacy harm may outrank the exploit path that looks more obvious on paper. A mitigation may also collapse once the delivery team tries to build it.
It also hallucinates. It can invent controls, cite the wrong component, misunderstand a diagram, or treat a placeholder architecture as production truth.
The output is a security hypothesis. Good hypotheses are valuable. They still need evidence.
Feeding the agent: diagrams, ADRs, IaC, and data-flow inputs
Generic prompts produce generic reviews.
"Review this AWS design for security" will usually return a cloud security checklist. Useful once. Dead weight after that.
The agent needs the design record. Keep the packet small enough that reviewers can inspect it:
- Architecture diagrams or data-flow diagrams, ideally in a structured format such as draw.io XML, Mermaid, JSON, YAML, or a threat-modeling tool export.
- Architecture Decision Records that explain why the team chose a service, protocol, trust model, or integration.
- IaC from Terraform, CloudFormation, Pulumi, Kubernetes, or Helm.
- OpenAPI, AsyncAPI, GraphQL, or protobuf definitions.
- Data classification notes, retention rules, tenant boundaries, and privacy constraints.
- Identity flows, role mappings, service accounts, token exchange patterns, and approval paths.
- Prior incidents, pentest findings, risk exceptions, and security standards.
Several tools already point in this direction. STRIDE-GPT can generate STRIDE-style threat models, attack trees, DREAD scoring, and reports from descriptions, diagrams, and codebase context. OWASP Threat Dragon remains a useful open-source baseline for diagram-driven threat modeling. OWASP pytm and Threagile take the "threat model as code" path. AWS Threat Composer gives teams a structured way to capture threat statements and mitigations.
The market is moving too. On June 17, 2026, AWS announced threat modeling support in AWS Security Agent, describing an agentic capability that analyzes design documents or source code and generates STRIDE-based threats with mitigations. Keep judgment with the team. Treat the announcement as a signal that AI threat modeling is becoming a normal part of security tooling.
The input quality still decides the output quality.
A diagram without trust boundaries is a sketch. An ADR without assumptions is a decision log, not a review artifact. IaC without the business context may tell the agent what will be built, while hiding the reason anyone should care.
Methodology fit: STRIDE, attack trees, and rigor
The prompt should not ask the model to "find risks."
That wording invites noise. It lets the agent wander through familiar security advice and return findings that sound plausible but do not attach to the design.
Start with the four questions from the threat modeling tradition:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
Then make the agent work against the system model.
For STRIDE, the unit of review should be a component, data flow, or trust-boundary crossing. The agent should ask whether spoofing, tampering, repudiation, information disclosure, denial of service, or elevation of privilege applies to that specific part of the design. Each candidate threat should name the attacker, preconditions, impacted asset, design evidence, mitigation, and verification path.
Attack trees help when the team has a clear attacker goal. "Access another tenant's records." "Exfiltrate documents through a model response." "Abuse an agent tool to send data outside the approved destination." The tree forces the review toward paths, not categories.
Privacy needs its own pass. LINDDUN is useful when the system processes personal data, identity data, behavioral telemetry, health data, financial data, or anything that creates sensitive inference. A system can pass a narrow STRIDE review and still create privacy harms through linking, identifying, detecting, unawareness, or non-compliance.
For AI and agentic systems, add AI-specific references. OWASP's AI Agent Security Cheat Sheet covers prompt injection, tool abuse, memory poisoning, excessive agency, privilege escalation, and data exfiltration. OWASP's LLM Top 10 adds risks such as prompt injection, sensitive information disclosure, excessive agency, and vector or embedding weaknesses.
The agent should return structured output, not a prose essay.
Threat = {
source_evidence,
affected_component,
trust_boundary,
threat_category,
attacker_goal,
preconditions,
impact,
mitigation_options,
verification_test,
open_questions,
confidence
}
That shape gives the architect something to argue with. A vague paragraph does not.
Human-in-the-loop: the agent drafts, the architect judges
The first win is a better starting point for the workshop.
Instead of asking a senior architect to build the model from scratch, the team can hand over a draft packet: system inventory, data flows, trust boundaries, candidate threats, missing evidence, proposed mitigations, and questions for the design owner.
The architect still owns the review.
They verify the system model. They challenge inferred facts. They remove findings that do not apply. They add abuse cases from business context. They decide whether a mitigation is strong enough, whether a risk needs leadership sign-off, and whether the design needs another pass before build.
The review meeting changes. It starts with sharper questions:
- Is this trust boundary real?
- Which identity is used at this hop?
- Who can read from this data store?
- What data leaves the tenant boundary?
- What happens if the agent follows a malicious instruction from a retrieved document?
- Which mitigation has a test?
- Who owns the residual risk?
Senior time goes to judgment; transcription can stay with the tooling.
The agent can also help after the meeting. It can turn accepted mitigations into backlog items, write negative test ideas, update the risk record, and flag the assumptions that should trigger re-review.
Approval stays outside the agent.
Guardrails: do not let the review agent become the leak
Architecture reviews contain sensitive material. Cloud topology. IAM design. Admin routes. Network paths. Customer names. Vendor integrations. Data classifications. Planned features. Known weaknesses.
Feeding that into an unapproved model creates a data disclosure path.
The guardrails should be boring and explicit:
- Use approved enterprise or API endpoints, not consumer chat sessions, for non-public designs.
- Maintain an approved model matrix that covers provider, region, retention, training use, abuse monitoring, stateful features, and data residency.
- Prefer stateless calls for sensitive reviews. Separately approve file uploads, vector stores, persistent threads, batch jobs, web browsing, and agent sessions.
- Redact secrets, account IDs, customer names, hostnames, and roadmap details when the exact value adds nothing to the review.
- Treat design documents as untrusted input. A malicious instruction can live in Markdown, a ticket, a diagram label, hidden text, or a PDF comment.
- Keep the review agent read-only. No production credentials. No write access to tickets, pull requests, cloud consoles, or document repositories without a separate approval path.
- Log the model, endpoint, files submitted, retrieved chunks, tool calls, reviewer, and final disposition.
This is the same control pattern from the AI agent security series. The model proposes. Deterministic controls and accountable humans decide.
If the architecture under review includes agents, the review has two layers. First, threat-model the system the agent supports. Then threat-model the agent itself: tools, memory, RAG, MCP servers, identity, approvals, egress, logs, sandboxing, and failure modes. CSP's AI Agent & Agentic System Security Assessment exists because those boundaries are easy to miss.
A rollout path from one architect to team capability
Start small.
Give one senior architect an isolated assistant and a defined input packet. Use it on reviews that were already scheduled. Measure whether it saves prep time, improves coverage, and produces questions the architect would have asked anyway.
Skip automatic gates at the start.
The first version should be advisory. The architect edits the draft, marks false positives, records missed issues, and tunes the prompt. The team learns which documents matter and which outputs are noise.
Then standardize the packet. One page for scope and assumptions. One diagram with trust boundaries. One list of sensitive data. One folder for ADRs, IaC, API specs, and prior findings. One output schema for threats and mitigations.
After that, plug the draft into the existing workflow. A design ticket can get an agent-generated review note before the architect sees it. A pull request that changes Terraform can include a threat-model delta. A product epic can carry open questions about data flow, retention, or identity. The human review stays visible.
Metrics matter:
- Reviews with a complete input packet.
- Time from design submission to draft review.
- Accepted threats versus rejected threats.
- High-risk findings with owners.
- Mitigations with verification tests.
- Residual risks with named approvers and expiration.
- Escaped design issues found later in code review, pentests, or incidents.
Scaling threat modeling takes more than running a model across every document. The mature version is a team capability: defined triggers, known inputs, structured outputs, human decisions, tracked mitigations, and re-review when the design changes.
Good triggers are concrete. New sensitive data type. New trust boundary. New external integration. New privileged identity. New agent tool. New model provider. New data store. New public endpoint. New exception to a standard.
Keep the architect in the loop
AI threat modeling is useful now. The tools are young, uneven, and improving fast. The operating model carries the weight.
The agent should do the tedious work first: read, extract, categorize, draft, compare, and ask. The architect should do the judgment work: verify, challenge, prioritize, and decide.
CSP's Threat Modeling & Application Design Review service already sits in that human judgment layer. The AI Security Practice extends it for LLM applications, RAG systems, agentic workflows, AI governance, and red teaming. Cloud design belongs in the same conversation; CSP's Cloud Security Assessments review the infrastructure and control-plane assumptions that architecture diagrams often simplify.
Agents can scale review preparation. They can make small teams faster. They can help architects spend less time building the first draft and more time finding the flaw that would have survived the checklist.
The model can draft the threat model. The architect owns the risk.
CSP threat-modeling and architecture reviews: human-led, agent-accelerated.
About the Author
Peter Karman is a Senior Principal AI Engineer at DryRun Security. He builds agentic, LLM-powered code-review systems that review PRs, ground findings in evidence, and alert of potential security issues. With 17+ years across infrastructure, networking, and software engineering, he designs dependable review pipelines, grounds findings in evidence, and instruments the process so performance meets real-world cost and latency constraints. He previously led engineering and AppSec initiatives as a Principal Engineer at companies like Leafly and AnyRoad.
Cloud Security Partners partnered with DryRun Security for this blog. DryRun Security is the industry’s first AI-native, agentic code security intelligence solution. Powered by their proprietary Contextual Security Analysis engine, they secure software built for the future by helping security and developer teams quiet noise, gain insights, and surface risks that pattern-based scanning tools inherently miss.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
