{
  "schema_version": "1.0.0",
  "rubric_version": "1.0",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "K-0018",
    "slug": "threat-model",
    "title": "Threat model",
    "aliases": [
      "adversary model"
    ],
    "status": "draft",
    "last_reviewed": "2026-09-23",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": []
    },
    "risk_flags": [],
    "flags": [],
    "one_liner": "An explicit statement of who might attack a system, what they can do, and which threats the design covers or leaves out of scope.",
    "sources": [
      {
        "source": "S-0072",
        "supports": "threat model describes the capabilities an attacker is assumed to deploy, including information, computing capability and control of the system; purpose is to identify threats of concern and rule others out of scope; nearly every system is vulnerable to a sufficiently dedicated and resourceful attacker",
        "locator": "§3"
      },
      {
        "source": "S-1600",
        "supports": "NIST definition of threat modeling as a form of risk assessment modelling attack and defence sides",
        "locator": "term: threat_modeling (NIST SP 800-53 Rev. 5)"
      },
      {
        "source": "S-0029",
        "supports": "Prover as covert adversary; unlimited physical access undermines attestation and signed firmware; physical inspections detect hard-to-hide hardware attacks",
        "locator": "§2; §3.1"
      },
      {
        "source": "S-0004",
        "supports": "states seeking to demonstrate compliance while seeking ways to circumvent verification",
        "locator": "p. 22, fn. 40"
      },
      {
        "source": "S-0018",
        "supports": "nation-state adversaries; no single chain of trust; redundancy across devices trusted unilaterally by each party; malicious verifier",
        "locator": "threat model section"
      }
    ],
    "related": [
      "K-0001",
      "K-0002",
      "K-0005"
    ],
    "type": "concept",
    "url": "https://trustbutveri.fyi/concepts/threat-model/",
    "source_file": "content/concepts/threat-model.md",
    "flags_all": [
      "ai-drafted"
    ],
    "body_markdown": "A threat model describes the capabilities an attacker is assumed to be able to use against a system, such as the information, computing power and control of the system available to it [[S-0072]].\n\nIts purpose is to identify the threats a design must withstand and to rule others explicitly out of scope, since nearly every security system is vulnerable to a sufficiently dedicated and resourceful attacker [[S-0072]]. NIST treats threat modelling as a form of risk assessment that models both the attack and the defence side of a system [[S-1600]]. Threat models used in AI verification differ in how far each party is trusted:\n- **Covert adversary.** Shavit models the [[K-0001|prover]] as willing to break the rules only if it expects not to be detected [[S-0029]].\n- **Circumvention.** The Oxford Martin report analyses states that seek to demonstrate compliance to each other while also looking for ways to circumvent verification [[S-0004]].\n- **Mutual distrust.** One low-trust system overview assumes nation-state adversaries on both sides, including a [[K-0002|verifier]] that may try to exfiltrate the prover's secrets, and relies on redundant checks across devices that each party trusts unilaterally, instead of a single chain of trust [[S-0018]].\n\nPhysical access is a recurring issue: Shavit notes that a prover with unlimited physical access to a chip could undermine its attestation and signed-firmware protections, and relies on physical inspections to detect such attacks [[S-0029]].",
    "body_text": "A threat model describes the capabilities an attacker is assumed to be able to use against a system, such as the information, computing power and control of the system available to it [S-0072]. Its purpose is to identify the threats a design must withstand and to rule others explicitly out of scope, since nearly every security system is vulnerable to a sufficiently dedicated and resourceful attacker [S-0072]. NIST treats threat modelling as a form of risk assessment that models both the attack and the defence side of a system [S-1600]. Threat models used in AI verification differ in how far each party is trusted: - Covert adversary. Shavit models the prover as willing to break the rules only if it expects not to be detected [S-0029]. - Circumvention. The Oxford Martin report analyses states that seek to demonstrate compliance to each other while also looking for ways to circumvent verification [S-0004]. - Mutual distrust. One low-trust system overview assumes nation-state adversaries on both sides, including a verifier that may try to exfiltrate the prover's secrets, and relies on redundant checks across devices that each party trusts unilaterally, instead of a single chain of trust [S-0018]. Physical access is a recurring issue: Shavit notes that a prover with unlimited physical access to a chip could undermine its attestation and signed-firmware protections, and relies on physical inspections to detect such attacks [S-0029].",
    "referenced_by": [
      {
        "id": "M-0014",
        "title": "Bandwidth limits and compartmentalization",
        "url": "https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/"
      },
      {
        "id": "M-0018",
        "title": "Chip location verification",
        "url": "https://trustbutveri.fyi/mechanisms/chip-location-verification/"
      },
      {
        "id": "M-0025",
        "title": "Confidential multi-party verification",
        "url": "https://trustbutveri.fyi/mechanisms/confidential-multi-party-verification/"
      },
      {
        "id": "M-0009",
        "title": "Hardware-enabled guarantees (flexHEG) and guarantee processors",
        "url": "https://trustbutveri.fyi/mechanisms/flexheg-guarantee-processors/"
      },
      {
        "id": "M-0011",
        "title": "Hardware performance throttling and licensing",
        "url": "https://trustbutveri.fyi/mechanisms/hardware-performance-throttling/"
      },
      {
        "id": "M-0015",
        "title": "Memory wiping and proofs of secure erasure",
        "url": "https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/"
      },
      {
        "id": "M-0010",
        "title": "On-chip telemetry from timing, memory and performance counters",
        "url": "https://trustbutveri.fyi/mechanisms/on-chip-telemetry/"
      },
      {
        "id": "M-0023",
        "title": "Safeguard attestation",
        "url": "https://trustbutveri.fyi/mechanisms/safeguard-attestation/"
      },
      {
        "id": "M-0001",
        "title": "Sampled inference recomputation",
        "url": "https://trustbutveri.fyi/mechanisms/sampled-inference-recomputation/"
      },
      {
        "id": "M-0017",
        "title": "Tamper evidence for verifier devices",
        "url": "https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/"
      },
      {
        "id": "M-0008",
        "title": "TEE remote attestation for AI workloads",
        "url": "https://trustbutveri.fyi/mechanisms/tee-remote-attestation/"
      },
      {
        "id": "M-0016",
        "title": "Timed challenge-response and memory-occupation challenges",
        "url": "https://trustbutveri.fyi/mechanisms/timed-challenge-response/"
      },
      {
        "id": "M-0021",
        "title": "Workload classification from telemetry and side channels",
        "url": "https://trustbutveri.fyi/mechanisms/workload-classification-from-telemetry/"
      },
      {
        "id": "M-0004",
        "title": "Zero-knowledge proofs of inference",
        "url": "https://trustbutveri.fyi/mechanisms/zk-proofs-of-inference/"
      },
      {
        "id": "I-0012",
        "title": "Low-trust AI compute verification system overview",
        "url": "https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/"
      },
      {
        "id": "I-0009",
        "title": "Lucid sovereignty (location) certificates",
        "url": "https://trustbutveri.fyi/implementations/lucid-location-certificates/"
      },
      {
        "id": "I-0010",
        "title": "RAND secure inference data center (SIDC) design",
        "url": "https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/"
      },
      {
        "id": "K-0001",
        "title": "Prover",
        "url": "https://trustbutveri.fyi/concepts/prover/"
      },
      {
        "id": "K-0020",
        "title": "Sampling and assurance",
        "url": "https://trustbutveri.fyi/concepts/sampling-and-assurance/"
      },
      {
        "id": "K-0002",
        "title": "Verifier",
        "url": "https://trustbutveri.fyi/concepts/verifier/"
      }
    ]
  }
}