Product · Threat modeling
From any description to a threat model you can act on.
An end-to-end threat modeling agent: ingests notes, repositories, diagrams, documents, SBOMs and CBOMs; builds a reviewable system model; runs the frameworks you choose and compliance presets; and returns evidence-checked threats with fixes and verification steps.
- Frameworks you choose
- Evidence checked
- Local or hosted models
- CLI · MCP · PR checks
The problem
Threat modeling is scattered across documents, scanners and spreadsheets.
A model is written once, in a design review, by the most experienced person available. It is thorough for the system as drawn that week. Then the system changes, the document does not, and the model becomes a record of a decision rather than a picture of the attack surface.
The findings that do exist are split between a diagram, a scanner report and a spreadsheet. Nobody can say which risk is highest, which fix came first, or whether the same threat was already accepted last quarter.
Threat Model Agent is built to do the whole job: read the system, model it, run the analysis, verify the evidence, and keep the result current.
Workflow
One run, from raw input to a reviewable model.
Five stages, with a human review where it matters: before analysis and before accepted changes.
- Ingest 01
Notes, repositories, documents, diagrams, cloud specs, SBOMs and CBOMs — mixed in one run. Speech and audio are transcribed first.
- Model 02
One structured system model: components, data flows, trust boundaries, assets and assumptions. Review it, edit the JSON, correct it before analysis.
- Analyze 03
The frameworks you pick run as separate calls, with presets for system, security domain and compliance. Scanners and a post-quantum pass attach their evidence.
- Verify 04
Every quote is checked against the inputs; invented citations are dropped. Duplicates merge, and an optional judge labels generic threats.
- Act 05
Threat cards carry attack scenarios, mitigations with Where and Verify, owners and test cases. Save versions, track to closure, send tickets, fail pull requests.
Inputs
Give it what you already have.
Mixed inputs are built into one system model. Unrelated systems belong in separate projects.
Text and speech
Paste a design note or dictate one. Audio files are transcribed into editable text before the run.
Repositories
Up to 10 Git URLs. The agent reads the file tree, docs, containers, IaC, API specs, auth and routing code.
Local files and documents
Folders, PDF, Word, HTML, Markdown and text. Whole pages are read without running their scripts.
Diagrams and images
draw.io, Mermaid, PlantUML, whiteboard photos and screenshots — nodes, edges and vision where the model supports it.
Infrastructure and API specs
OpenAPI, docker-compose and Terraform, with a security summary first: open endpoints, privileged containers, public buckets.
SBOMs and CBOMs
CycloneDX or SPDX, including cryptographic assets. Dependency and crypto threats name real components.
Scanner reports
SARIF, Semgrep, Gitleaks, Trivy and Checkov findings become evidence on matching threats.
Archives and more
A .zip behaves like a repository. Add a scanner report, a compliance target or a focus to the same run.
Frameworks
Any frameworks. Any combination.
- STRIDE, PASTA, VAST, OCTAVE, Trike, attack trees
- LINDDUN
- OWASP Web, API, Mobile, CI/CD, Kubernetes and IoT
- MITRE ATT&CK, Cyber Kill Chain, D3FEND
- Zero Trust, Identity and SSO, software supply chain, FedRAMP
- Cryptography and PKI, network infrastructure, internet edge
- OWASP LLM, MITRE ATLAS, MAESTRO, agentic applications
Presets and settings
Start from the obligation.
- General: standard STRIDE, quick web check, deep review, attacker view
- By system: API, mobile, cloud, Kubernetes, CI/CD, IoT, OT, AI or agent system
- Security domain: Zero Trust, identity, supply chain, cryptography and PKI, network, edge
- Compliance: PCI DSS, HIPAA, GDPR, SOC 2, FedRAMP, EU AI Act, AI governance
Then adjust
- Depth: quick, standard or deep
- Risk scoring: L/M/H, DREAD, CVSS-style or OWASP
- Compliance mapping: NIST, ISO, SOC 2, PCI, HIPAA, GDPR, AI RMF, CRA and more
- Optional judge that flags or hides generic threats
- Quote evidence, checked against the inputs
- Learn from dismissed threats and answered questions
- Local scanners and a post-quantum readiness pass
Output
A report you can defend and act on.
Not a list of plausible sentences. Each finding carries its evidence, its fix, and the way to check the fix.
Executive view
Total threats by severity, the top risks, and a system summary a board or a client can read.
Diagram
A data-flow diagram with threats marked, components and flows coloured by their worst threat.
Threat cards
Attack scenario, likelihood and impact, evidence, references, and mitigations with Where and Verify.
Evidence and findings
Quotes tied to file and line, scanner findings linked to threats, and the ones no threat covers.
Compliance and crypto
Controls grouped by standard, and a crypto inventory showing which uses are quantum-vulnerable.
Open questions
What the inputs could not answer, with the component and threats each question names.
The evidence is checked, not generated
Continuity
The model stays useful after the meeting.
Versions, tracking, tickets and checks keep the model tied to the work, not to a document.
Projects and versions
Every run becomes a numbered version. Compare two, see new, resolved and changed threats, and re-run only when inputs or commits changed.
Tracker and risk register
Status, owner, due date, notes and links per threat. Late items surface; the register exports for audit.
Tickets and pull requests
Send threats to GitHub, Jira, Linear, Azure DevOps, GitLab or ServiceNow, or to a signed webhook. A PR check comments only the new threats.
Kestrel and the graph
Ask the report questions and accept or reject proposed changes. The graph links components, threats, evidence, findings and controls.
Lifecycle
Present from design to operations.
The model is an artifact at every phase, and the agent keeps it current.
- Design 01
Model before code is fixed.
Start from the architecture, an API spec or a design note. Review components, flows and trust boundaries before threats are generated.
- System model review
- Trust boundaries
- Abuse cases
- Develop 02
Turn threats into work.
Each fix says where to change it and how to verify it. Send it to a ticket, a coding agent, or a pull request check.
- Where and Verify
- Tickets
- PR checks
- Operate 03
Keep the model true.
Versions show what changed. Re-runs only when inputs or commits move. Dismissed risks stay dismissed, with the reason.
- Version diffs
- Re-run if changed
- Risk register
Deployment
Runs where the team runs.
Local, hosted or a team server. The same engine behind the web app, the CLI, the MCP server and the pull request check.
Any model
Local Ollama or LM Studio, any OpenAI-compatible server, OpenRouter or Claude. Use one model, or a different one per stage, with cost limits.
Local or team
Docker or a checkout, offline installs, SQLite or Postgres. A team server adds accounts, SSO, passkeys, OAuth, audit and signed backups.
Where you work
The web app, the tma command line, an MCP server for AI apps and coding agents, and a GitHub Action for pull request checks.
With Cipher Posture, optional
One inventory, one model.
Threat Model Agent stands on its own. If you also run Cipher Posture, it can read the CBOM and identity inventory, so cryptographic and delegation risks are grounded in the same facts as the migration plan — not guessed from a diagram.
Without Cipher Posture
Bring the inputs you have. The agent builds the model from them and flags what it cannot know.
With Cipher Posture
Add a CBOM and identity inventory. Crypto and delegation threats name real assets, not assumptions.
Both stay current
Re-model when the architecture changes; the model version and the evidence stay attached.
FAQ
Reasonable questions.
If yours is not here, ask it directly — we answer email.
Is this a scanner?
No. It starts from the system, builds a model, and runs the frameworks you choose. It can run scanners and attach their findings as evidence, but a scanner report is an input, not the analysis.
What can I give it?
Notes, a dictated description or audio, Git repositories, local folders, PDFs and documents, diagrams and screenshots, OpenAPI, Terraform and docker-compose, SBOMs and CBOMs, scanner reports and zip archives. They can be mixed in one run when they describe the same system.
Which frameworks does it run?
As many as you need, including STRIDE, PASTA, LINDDUN, the OWASP family, MITRE ATT&CK, Zero Trust, identity, supply chain, FedRAMP, cryptography and PKI, network, edge, and LLM and agentic frameworks. Presets pick a sensible starting set; you can change every part.
How do you stop invented citations?
The evidence step quotes the input for each threat, and code checks that every quote really exists before it is kept. Invented citations are dropped. A separate check flags text in the inputs that tries to steer the model, and treats all input as data.
Does it replace security architects?
No. It drafts and maintains the model, which is the part that decays. Your architects review the assumptions, approve risk decisions, and own the mitigations. Kestrel proposes changes; a person accepts or rejects them.
Does it need Cipher Posture?
No. It works on its own. If you also run Cipher Posture, the agent can read its CBOM and identity inventory, so cryptographic and delegation risks are grounded in the same inventory.
Can it run offline or with local models?
Yes. Local model servers are found automatically, and offline installs work with a local model. Inputs, reports and traces stay on the machine with a local model; a hosted model receives the inputs of the run.
What does a pilot look like?
One system, four to six weeks. We agree the sources, run the model with your team, and review the output with your security architects. You keep the system model, threat register, evidence and test cases.
Pilot
Run it against one system.
Four to six weeks, one service group, and a review with your security architects. You keep the system model, threat register, evidence and test cases.