Skip to content

SOP-081 — Threat model (STRIDE + agent-specific)

Guide

<!-- last-reviewed: 2026-06-01 · owner: Security & Privacy (Security Director) -->

SOP-081 — Threat model (STRIDE + agent-specific)

SOP · owner: Security & Privacy (Security Director). Layer: SOP/Runbook (docs/canon.md). The procedure for structurally modeling a system, feature, data flow, or agent class before it is trusted with significant access. Policy frame: hr/policies/security.md; charter: docs/units/security-privacy/charter.md.

Interface Contract

  • Inputs: system / feature / data-flow / agent-class to model ← from <CPTO / Engineering Director / AI Systems Director / self> · trigger: review requested
  • Inputs: binding arbitration call ← from <COO / Principal> · trigger: arbitration decided
  • Outputs: prompt-injection-defense / control requirements → to AI Systems Director · trigger: requirements issued
  • Outputs: security control requirements → to Engineering Director · trigger: requirements issued
  • Outputs: approved threat model → to Archivist · trigger: artifact approved
  • Outputs: threat model / security doc added or changed → to Documentarian · trigger: document changed
  • Outputs: threat model handed for independent assurance → to Quality & Risk · trigger: review requested
  • Handoff trigger (in): a new system/feature/data-flow/agent-class is proposed for significant access, or I scope one proactively
  • Handoff trigger (out): the model is published, high/critical threats carry named mitigations + owners, and requirements are issued to implementers
  • Definition of Done before handoff:
    • [ ] Scope is named and bounded (one system/flow/agent-class — not “everything”)
    • [ ] Attack surface mapped: entry points, trust boundaries, assets
    • [ ] Threats enumerated by STRIDE + agent-specific (Prompt Injection, Tool Grant Abuse, Context Window Leakage)
    • [ ] Each high/critical threat has a named control, a named implementing owner, and an acceptance criterion
    • [ ] Published to docs/security/threat-models/; handed to Archivist (artifact approved); 0 drift
    • [ ] Learnings captured to docs/knowledge/security/ if any

Triggers are drawn verbatim from docs/handoff-triggers.md (review requested, requirements issued, artifact approved, document changed). The review requested in-edge from an upstream unit and the review requested out-edge to Q&R are distinct directions of the same registry phrase, both absorbed by named fan-in sinks (interface-contract-spec.md §3.1 R1).

Purpose

Form an independent, structured view of how a system could be attacked before it is trusted, so high-risk threats are mitigated by design rather than discovered in production — including the AI-workforce-specific risks a traditional app model misses.

When to use

Before a new system, feature, data flow, or agent class is granted significant access. Also when an existing surface materially changes (new external input, new tool grant, new data store). Decline to model “everything” — that is a list, not a model.

Flow

flowchart LR
  A["Scope<br/>(one surface)"] --> B["Map attack surface<br/>(entry / boundary / asset)"]
  B --> C["Enumerate<br/>STRIDE + agent-specific"]
  C --> D["Rate & rank<br/>(likelihood × impact)"]
  D --> E["Mitigations<br/>(control + owner + accept-crit)"]
  E --> F["Publish + hand off<br/>requirements issued / artifact approved"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  class A,B,C,D,E,F s

Text fallback: scope one surface → map entry points, trust boundaries, and assets → enumerate threats by STRIDE plus the agent-specific categories → rate and rank by risk (not by ease of fix) → propose a named control + named owner + acceptance criterion for each high/critical → publish to docs/security/threat-models/ and issue requirements to implementers (requirements issued), the model to the Archivist (artifact approved).

Steps

  1. Scope the model. Name the one system/feature/flow/agent-class. Write the boundary in one sentence.
  2. Map the attack surface. Entry points (user input, API calls, file reads, tool invocations, webhooks), trust boundaries (agent→agent, external→internal, Slack→Neon), assets (secrets, PII, tool grants, principal-impersonation potential).
  3. Enumerate threats — STRIDE + agent-specific. Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege; plus Prompt Injection, Tool Grant Abuse, Context Window Leakage.
  4. Rate and rank. Likelihood × impact per threat; prioritise by risk, not by ease of mitigation.
  5. Propose mitigations. For each high/critical: the specific control, the implementing owner (AI Systems / Engineering / Operations), and the acceptance criterion for “mitigated.” No mitigation without an owner.
  6. Publish + hand off. Write to docs/security/threat-models/; issue requirements (requirements issued); hand the model to the Archivist (artifact approved) and Documentarian (document changed); to Q&R for assurance (review requested).

Roles / approvers

Run by the Security Director. The COO approves the unit’s security posture; the Principal accepts any residual risk on the record (GR-3). Q&R provides independent assurance, not approval.

Guardrails

  • Do not threat-model “everything” — scope or decline.
  • Mitigations need owners — a control with no named implementer is not a mitigation.
  • No silent risk acceptance — unmitigated high/critical risk is stated to the Principal as a named scenario (GR-3) before the surface is trusted.
  • Requirements, not edits — issue requirements to AI Systems / Engineering; do not write their prompts or code.
  • Personal information is PA-only — a flow touching it is modeled at the boundary, not by inspecting the data.

Job aid: (N/A — threat modeling is judgment work; the STRIDE+agent-specific category list above is the checklist, GR-4.) See also: docs/units/security-privacy/manuals/security-director.md · SOP-082 · SOP-083 · hr/policies/security.md · docs/handoff-triggers.md · reports/phase0-reviews/security-director-codebase-review.md (D2).