SkillVaultskills Browse all 500 skills

Security · Version 1.1.0 · Reviewed 2026-08-02

Threat Model Facilitator

Find and prioritize exploitable risk in trust boundary mapping and attack path enumeration with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Runs a structured threat model producing assets, actors, trust boundaries, concrete attack paths, and prioritized mitigations.

₹149 one-time

Get this skill archive

What this skill helps you do

  • Trust boundary mapping
  • Attack path enumeration
  • Mitigation prioritization

How Threat Model Facilitator works

You provide

Design, data flows, actors, and deployment context

It inspects

Trust boundaries and what an attacker gains at each step

It decides

Concrete attack paths with prioritized mitigations

You verify

Each mitigation mapped to a testable control

What it checks first

Threat Model Facilitator runs a structured threat model producing assets, actors, trust boundaries, concrete attack paths, and prioritized mitigations. Use it when the work involves Trust boundary mapping, Attack path enumeration, Mitigation prioritization.

  1. What an attacker gains at each step, which determines whether a path is worth mitigating.
  2. Trust boundaries where untrusted input crosses into a privileged context.
  3. Whether authorization is enforced where data is accessed or only where requests arrive.
  4. Which assets would cause the most damage if disclosed, altered, or destroyed.
  5. What the system serves from a domain that shares cookies or storage with the application.

Failure modes it recognizes

  • User-uploaded content served from the application origin, turning any upload into stored cross-site scripting.
  • Share links with guessable or sequential identifiers, allowing enumeration across tenants.
  • A server-side fetch of a user-supplied URL reaching internal services or cloud metadata.
  • Authorization checked when the link is created but not when it is redeemed.
  • File type validated by extension or client-supplied content type rather than by content.
  • An internal API assumed unreachable because it is not documented publicly.

Answers it will reject

  • Enumerating a threat taxonomy without connecting each item to a concrete path in this system.
  • Rating severity by category rather than by what the attacker actually obtains.
  • Deferring to a checklist and never asking what a valid-but-hostile user can do.
  • Producing a threat model with no owner or follow-up, which decays immediately.

Decision rules it applies

  • Start from assets and attacker goals, not from a list of vulnerability classes.
  • A threat is only actionable when the path from entry point to impact is named.
  • Serve untrusted content from a separate origin so a compromise cannot reach application cookies.
  • Prefer unguessable identifiers plus an authorization check, not one or the other.

Evidence it asks for

  • Draw the data flow and mark every boundary crossing, then walk one hostile input across each.
  • Attempt the enumeration or traversal manually before rating its likelihood.
  • Map each mitigation to a test that fails if the mitigation is removed.

The method inside

  1. Map the artifact, actors, boundaries, and invariants relevant to trust boundary mapping.
  2. Trace concrete failure or abuse paths for attack path enumeration; do not report checklist items without a mechanism.
  3. Prioritize mitigation prioritization findings by impact, likelihood, confidence, and cost of correction.
  4. Recommend the smallest defensible change, then define how an independent reviewer can verify it.

Deliverables

  • Trust boundary mapping assessment
  • Attack path enumeration decision and action plan
  • Mitigation prioritization verification checklist

Evidence requirements

  • Code, configuration, data flows, and trust boundaries
  • Identity, authorization, and deployment context
  • Threat model, controls, and known assumptions

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

We are launching a file-sharing feature. Walk us through threat modeling it.

Expected output

Start with what an attacker gains, not with a threat taxonomy. For file sharing the highest-value paths are usually authorization on the share link and content served from a domain that shares cookies with your app. Enumerate who can reach each store and what a valid-but-hostile user can do...

Boundaries and compatibility

Ideal for

  • Trust boundary mapping: produce a decision or artifact grounded in supplied evidence.
  • Attack path enumeration: produce a decision or artifact grounded in supplied evidence.
  • Mitigation prioritization: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Authorizing offensive actions against systems without permission
  • Reporting theoretical issues as exploitable without a path

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.