Most teams know what a threat model is supposed to do. Fewer have updated one since the system last changed, and almost none keep one current as it evolves. That's not laziness. It's math. A real threat model traditionally needs a room: an architect, an AppSec engineer, someone who knows the actual attacker landscape, and enough calendar time to get all three in the same meeting before the design is already frozen. Most orgs don't have that room on tap, so threat modeling becomes a one-time workshop at design time, stale the first time the architecture shifts, or it just doesn't happen.
Agentic AI changes that math. Here's what that looks like, why it matters, and how to put it in place.
WHAT
Threat-Informed Development, defined
MITRE's Center for Threat-Informed Defense has spent years building out threat-informed defense: using a deep understanding of adversary behavior to drive how you detect and respond. That work, anchored on MITRE ATT&CK and measured by maturity models like INFORM (2026), lives mostly after deployment. Threat-Informed Development (TIDev™) is its sibling on the other side of the release: the same adversary knowledge, applied to design and code before anything ships.
TID / TIDef
Adversary knowledge drives detection and response. Post-deployment.
TIDev™
An agent, grounded in threat intelligence for your industry, sector, and geography, threat-models your system in the IDE, at pull requests, and in the CI/CD pipeline, at the cadence you choose. Pre-deployment, and retrofittable to what's already running.
Design-time threat modeling is still the highest-leverage moment, and it stays central. TIDev™ keeps going after it, on the same logic as test-driven development: threats get surfaced and handled in dev, continuously, not in a workshop that's out of date the first time the design changes.
Where it runs: the same three loops your SAST already covers
If you run SAST or SCA today, you already know the shape of this. Mature AppSec platforms cover three loops: the inner loop (the developer's IDE), the middle loop (pull requests and CI), and the outer loop (the pipeline, runtime, and posture management). Checkmarx One is a good example: it integrates with IDEs, source control, and CI/CD pipelines, and its IDE agent runs on top of GitHub Copilot or Claude Code.
TIDev™ puts a threat-informed agent in those same three loops, with a different job than a scanner. A scanner asks whether this code has a known flaw. The TIDev™ agent asks whether this change gives an adversary targeting your sector a new way in.
| Loop | Where | What the agent does | Enforcement |
|---|---|---|---|
| Inner loop | IDE, while designing and coding | Flags the threat implications of the change in progress against the current threat model and your sector's intelligence; drafts mitigations and abuse cases before commit | Advisory only. Never blocks; it's the cheapest place to fix |
| Middle loop | Pull request / merge | Evaluates the diff against design docs, the current model, and the source stack; posts "no material change" with its reasoning, or a scoped delta, as a PR comment | Your choice: an advisory comment or a required check. If you gate, start warn-only and block only once you trust the signal |
| Outer loop | CI/CD pipeline, then continuously | Reconciles the model against what was actually built and deployed (IaC, containers, SBOM); re-evaluates when threat intelligence changes, even with no new code | Scheduled and intel-triggered. Feeds posture management and your TID/TIDef detection program |
What the agent evaluates on each run
Not a gut call. Nobody can reliably look at a diff and know whether it changed what an attacker could do to you. That isn't a skill gap; it's the problem. A reviewer sees forty changed files. The questions that matter (does this open a new path to sensitive data, does it touch something a group targeting your sector is actively exploiting) need the whole architecture, the current threat model, and current intelligence in view at once. That's exactly the job an agent with RAG over a defined, deliberately limited set of sources is built for.
How often the agent runs is your call: every pull request, nightly, per release, or whatever fits your team. What decides whether the model needs updating on any given run is change, not the calendar. Most runs come back "no material change," logged with the agent's reasoning so the call is auditable. The rest come back as a scoped threat-model delta (finding, evidence, mapped control) for a human to review. TITO's PR threat diffing works this way at the pull-request level. Here's what the agent is looking for. These are categories it evaluates, not a checklist a human has to run:
| Category | What it looks like in practice |
|---|---|
| Trust boundary | New service, new tenant, new network exposure, or an internal component becoming internet-facing |
| Data flow | PII, credentials, payment or health data moving through a path that didn't carry it before; a data classification change |
| AuthN / AuthZ | New login path, SSO or OAuth change, new role, privilege model change, token handling change |
| Entry point | New API endpoint, file upload, webhook, deserialization path, or admin interface |
| Third party | New external API, SaaS integration, SDK, or supply-chain component with its own trust assumptions |
| Infrastructure | IAM policy or IaC change that alters exposure, new region, change in secrets handling |
| Agent capability | An AI agent gains tool access, memory, autonomy, or a new MCP server (MAESTRO layers 3–4 territory) |
| Business context | Entering a new market, region, or sector; a new product line; starting to hold a new class of data. Different business, different adversaries |
| Threat side | A new technique used by adversaries targeting your sector or region, a CISA KEV entry affecting a component you run, or an incident at your organization or a sector peer. The system didn't change; the threat did |
The first seven live in the diff. The last two don't: one lives in business context, the other in threat intelligence. They're the ones most programs miss, and they're the reason the agent needs a live, sector-relevant intelligence feed, not just a reference library.
SO WHAT
Why keeping the model current matters
The field settled this years ago. The Threat Modeling Manifesto, drafted in 2020 by 15 security practitioners, lists "Continuous refinement over a single delivery" among its five values.[8] Derek Fisher, author of the Application Security Program Handbook (Manning, 2023), made the practical case in a 2023 interview.[10] Fisher, who came to application security from software development, leads product security at a global fintech.[25] Doing it right takes product, engineering, operations, cloud, and security people together, which is why it doesn't scale. He points to the common phrase "your threat model is never truly done":[10] teams ship to production several times a day, and nobody is going to open a diagramming tool for every code change. His answer was to automate what you can and teach developers to think about threats reflexively.[10]
The standards say the same thing. CSSLP Domain 3 (Secure Software Architecture and Design) opens with the task Perform Threat Modeling, and spells out what it takes: knowledge of common threat actors, the ability to map your attack surface, and the ability to ingest and analyze threat intelligence. Domain 4 (Secure Software Implementation) carries that into the build, including the task Apply Security During the Build Process. NIST SP 800-218 (SSDF) practice PW.1, Design Software to Meet Security Requirements and Mitigate Security Risks, names threat modeling, attack modeling, and attack surface mapping directly in task PW.1.1, and PW.1.2 requires the resulting requirements, risks, and design decisions to be tracked and maintained over time.
None of that means a team threat-modeling on a slower cadence is doing it wrong. It means a model that never gets revisited drifts away from the system it describes, and that drift is worth tracking as a Secure SDLC gap. How tightly you track it is a risk decision, and it's yours to make.
Generic threat intelligence isn't enough
If you're building rockets in Brazil, you don't care about attacks against pet food factories in China. Generic threat intelligence doesn't just waste time. It buries the handful of adversaries and techniques that actually matter to you under thousands that don't. That's the line between threat-informed and threat-flavored.
The intelligence feeding the agent has to be scoped to who you actually are: your industry and sector, your geography (where you build, operate, sell, and store data), the tech stack you run, the data you hold, and your regulatory exposure. That scope decides which adversaries are likely to come for you, and which of their techniques belong in your model.
This is established practice. MITRE's INFORM maturity model scores "Relevance of CTI" as its own measured component. ATT&CK's group profiles record which sectors and geographies each adversary has been observed targeting. A 2020 HHS threat-profiling briefing for the healthcare and public health sector walks through it end to end: search ATT&CK groups by sector, narrow to the ones targeting U.S. healthcare, then threat-model against their techniques. Fisher makes the same point from practice: an operating-room application cares most about uptime and data integrity, a financial institution about confidentiality. Same methodology, different threat model.
NOW WHAT
1. Write down your threat profile and your scope
Everything downstream filters through these two documents, so write them first. The threat profile covers sector, geography, stack, data, and regulatory exposure. The scope covers what's in your system and what you actually control. Fisher calls scope the hardest part of threat modeling, and the agent can't infer either one.
Now what
- Start from the short list of adversary groups actually observed targeting organizations like yours, and pull their techniques. That's your baseline threat set, not the entire ATT&CK matrix.
- When the business changes (a new market, region, product line, or data type), update the profile the agent reads, even if no code changed.
2. Ground the agent in a named source stack
An LLM guessing at "likely" threats without a defined corpus isn't threat-informed anything, and it can't satisfy CSSLP's "ingest and analyze threat intelligence" requirement if there's nothing named to ingest. Keep the stack deliberately limited, in two layers: a relevance layer that makes it yours, and a baseline corpus everyone shares.
| Layer | Source | What it grounds |
|---|---|---|
| Relevance | Your threat intel team / TIP | The live layer: your threat intelligence platform or a cumulative feed, already deduplicated and scored for relevance |
| Relevance | Your threat profile | Sector, geography, stack, data, regulatory exposure; the filter everything else passes through |
| Relevance | ATT&CK Groups, filtered | Adversaries observed targeting your sector and region, and the techniques they actually use |
| Relevance | Sector ISAC / ISAO | Peer-reported intelligence for your industry (e.g., FS-ISAC, Health-ISAC, Space ISAC) |
| Relevance | National CERT / government advisories | Geography-specific intelligence (e.g., CISA in the U.S., CERT.br in Brazil) |
| Relevance | Your own incidents and telemetry | What has actually targeted you |
| Baseline | OWASP Top 10 + Top 10 for Agentic Applications | Baseline app-sec and agentic-specific risks |
| Baseline | CSA (incl. MAESTRO) | Cloud and agentic-AI threat framework |
| Baseline | MITRE ATT&CK | TTPs: what attackers actually do |
| Baseline | MITRE CAPEC | Attack patterns, tied to CWE |
| Baseline | MITRE CWE | Root-cause weakness taxonomy |
| Baseline | NVD / CVE | Known vulnerabilities and real-world severity |
| Baseline | NIST SP 800-218 (SSDF) | Secure development practices; the closest NIST anchor to CSSLP |
| Baseline | NIST SP 800-53 | Control catalog for mapping mitigations to requirements |
| Baseline | CWE Top 25 | Prioritization signal, updated annually |
| Baseline | OWASP ASVS | Verifiable security requirements |
| Baseline | OWASP SAMM | Maturity model: where in the SDLC controls should land |
| Baseline | MITRE CTID corpus | Defense-side data that closes the loop between TIDev™ and TID |
Now what
- Name both layers in writing before you call a model "threat-informed." A stack with no relevance layer is threat-flavored, not threat-informed.
- Refresh each source on the schedule it actually publishes on: NVD/CVE and CISA KEV continuously, the CWE Top 25 annually. A stack running on stale sources is a stale workshop, just automated.
3. Plug in live threat intelligence
Talk to your threat intel team. If you have one, they already maintain the most relevant intelligence you'll ever get. Point the agent at their platform directly, not at a copy that goes stale.
If you don't have one, you're not stuck. Free sources exist: CISA's Known Exploited Vulnerabilities catalog; CISA's Automated Indicator Sharing program (free, though its underlying statute, CISA 2015, lapsed in 2025 and has been kept alive by short-term extensions since, so check its current status before relying on its sharing protections); abuse.ch's URLhaus, MalwareBazaar, and ThreatFox; and your sector ISAC. Open-source platforms like MISP and OpenCTI can aggregate them. And a small aggregator that pulls those feeds, filters them against your threat profile, and serves the result to the agent is now a realistic build with an AI coding assistant like Claude.
Now what
- Point the agent at adversary behavior, campaigns, and exploited vulnerabilities, not the raw indicator firehose. IOC feeds (hashes, IPs, URLs) are detection fuel for TID/TIDef. Design decisions come from how adversaries operate and what they're exploiting.
- Treat every feed as untrusted input. Community feeds accept submissions from anyone, and whatever the agent retrieves lands in its context. That's MAESTRO Layer 2 (RAG poisoning) aimed at your own threat model. Validate, attribute, and isolate what goes into the index.
4. Choose your cadence and roll it out
Pick the cadence that fits each system. There's no single right answer; it's a trade between coverage and overhead, and it can differ by service.
| Cadence | Trade-off | Often fits |
|---|---|---|
| Every pull request | Most runs; smallest, easiest-to-review deltas; issues caught before merge | High-change or high-risk services |
| Nightly or daily batch | Fewer runs; the day's changes reviewed together | Steady, moderate-change codebases |
| Per release or sprint | Lowest overhead; larger deltas; longer window between change and review | Slower-moving or lower-risk systems |
| Intel-triggered | Runs when the threat changes, independent of code | Worth pairing with any of the above |
Now what
- Buy or build, the pattern is the same: IDE extension, PR check, pipeline stage. If your AppSec platform already has agentic hooks in all three loops, evaluate them before building your own.
- Tune before you block. A gate that fires on noise teaches developers to route around it. Every SAST rollout has already taught that lesson.
- Make the cadence explicit and write it down. What's worth tracking is a scheduled run that didn't happen, a "no material change" call with no logged reasoning, or a delta no human reviewed. Not a cadence someone else would have chosen.
5. Keep people where they matter
The agent does the reading. People still make the calls, and three cautions from Fisher's practice still apply.
Now what
- Learn it by hand first. Before you automate a process, do it manually so you know its inputs, outputs, and what good looks like. A team that can't build a threat model can't review the agent's delta.
- Keep the human on the delta, not the diff. The agent surfaces; a person decides.
- Don't mistake the artifact for security. A threat model someone reviewed and filed is a checkbox. The agent's "no material change" log is evidence the question was asked, not proof the answer was right.
- Map every finding to a control (ASVS requirement, SSDF practice, CWE entry) so it reads as a requirement, not a suggestion.
Standing on existing work
None of the pieces here are new, and the people who built them deserve the credit:
- The 2020 Threat Modeling Manifesto, and the DevSecOps practice of continuous threat modeling.
- Izar Tarandach's continuous threat modeling work ("threat model every story") and his book with Matthew Coles, Threat Modeling: A Practical Guide for Development Teams (O'Reilly, 2020), written for development teams and covering DevOps automation.
- Threat-modeling-as-code tools (pytm, threatspec, Threagile), and OWASP's DevSecOps Guideline, which treats threat modeling as a pipeline activity alongside pre-commit checks, SAST, SCA, and DAST.
- Derek Fisher's AppSec program work, including his 2023 speculation that AI would eventually turn an architecture into threats and mitigations.
- AWS Security Agent, which added AI-generated STRIDE threat modeling in public preview on June 17, 2026, working from design docs and source code inside Kiro, Claude Code, and MCP-compatible IDEs.
- TITO, an open-source CLI that runs STRIDE-LM, ATT&CK mapping, and CSA MAESTRO for agentic-AI threats in CI/CD, with PR-level threat diffing.
- CSA MAESTRO and the OWASP Top 10 for Agentic Applications, for agentic-AI threats.
- MITRE's Center for Threat-Informed Defense, whose threat-informed defense work TIDev™ takes its name and posture from.
The only new thing here is the name, and a way of putting these pieces together.
Bottom line
A threat model done once, at design time, starts drifting the first time the system changes. Put an agent in the IDE, at pull requests, and in the pipeline, at whatever cadence fits your team. Ground it in a named source stack and in threat intelligence for your sector and geography. Keep people on the decisions that need them. That's TIDev™.
Sources
- AWS, "AWS Security Agent announces support for Threat Modeling," June 17, 2026.
- GitHub, leathal1/TITO — "Threat In, Threat Out."
- Cloud Security Alliance, "Applying MAESTRO to Real-World Agentic AI Threat Models: From Framework to CI/CD Pipeline," Feb. 11, 2026.
- Cloud Security Alliance / GitHub, CloudSecurityAlliance/MAESTRO (official MAESTRO Threat Analyzer repo).
- MITRE Center for Threat-Informed Defense (ctid.mitre.org) — mission statement, M3TID (2024) and INFORM (2026) maturity models, including INFORM's "Relevance of CTI" component.
- ISC2, CSSLP domain and task list — Domain 3: Secure Software Architecture and Design (task: Perform Threat Modeling); Domain 4: Secure Software Implementation (task: Apply Security During the Build Process).
- NIST SP 800-218, Secure Software Development Framework (SSDF) v1.1, practices PW.1, PW.1.1, PW.1.2.
- Threat Modeling Manifesto, values, https://threatmodelingmanifesto.org/ (accessed 2026-10-08)
- Derek Fisher, Application Security Program Handbook, Manning Publications, 2023.
- Escape, "Threat modeling: the future of cybersecurity or another buzzword," The Elephant in AppSec podcast with Derek Fisher, Dec. 22, 2023 (transcript).
- OWASP GenAI Security Project / Agentic Security Initiative, "OWASP Top 10 for Agentic Applications," 2025 release.
- MITRE ATT&CK, Groups (attack.mitre.org/groups) — adversary profiles including observed target sectors and geographies.
- U.S. Department of Health and Human Services, "HPH Threat Profiling with MITRE ATT&CK," TLP:WHITE briefing, July 2020.
- Space Information Sharing and Analysis Center (Space ISAC), founded 2019.
- CISA, Known Exploited Vulnerabilities (KEV) catalog.
- CISA, Automated Indicator Sharing (AIS) program page, including status of CISA 2015 extensions (checked September 2026).
- abuse.ch — URLhaus, MalwareBazaar, ThreatFox (free community threat intelligence).
- MISP Project and OpenCTI (Filigran) — open-source threat intelligence platforms.
- Checkmarx, Checkmarx One platform page and VS Code extension documentation (Developer Assist).
- OWASP DevSecOps Guideline (OWASP Developer Guide, section 9.1).
- Threat-modeling-as-code projects: pytm, threatspec, Threagile.
- DevOps.com, "Implementing Threat Modeling in a DevOps Workflow" (continuous threat modeling).
- Izar Tarandach and Matthew J. Coles, Threat Modeling: A Practical Guide for Development Teams, O'Reilly, 2020.
- tl;dr sec, summary of Izar Tarandach, "Threat Model Every Story: Practical Continuous Threat Modeling Work for Your Team."
- Phoenix Security, speaker bio for Derek Fisher, "Head of product security at a global fintech," https://phoenix.security/?p=34914 (undated; accessed 2026-10-08)