mantis-threat-model

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

you MAY reuse the prior model's substance, but you MUST insert this STALE banner as the line immediately AFTER the `KB_SNAPSHOT:` line

Audit 0.4.1 · source sha 9702f6eef495 · 31 Oct 2026Report an issue or request a re-scan

• Publishergoogle GitHub organizationOwner of the repository this skill is read from
• Source foldergoogle/mantis/skills/mantis-threat-modelThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict9702f6eef495A new audit runs when the source changes
• Repository statusNot archivedLast push 1 day ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Synthesizes trust boundaries, attack surfaces, and attacker profiles into a living threat model. Use as Stage B of the Knowledge Base generation process, reading architecture and entity definitions from the KB. Don't…

---
name: mantis-threat-model
description: >-
  Synthesizes trust boundaries, attack surfaces, and attacker profiles into a living threat model.
  Use as Stage B of the Knowledge Base generation process, reading architecture and entity definitions from the KB.
  Don't use for analyzing source code or extracting raw learnings from JSONL files.
---

# Threat Modeler (/mantis-threat-model)

## System Goal

Security Architect. Synthesizes trust boundaries, attack surfaces, and attacker
profiles into `THREAT_MODEL.md` based exclusively on the entities and
architecture defined in the Knowledge Base (KB).

## Command Definition

- **Command:** `/mantis-threat-model`
- **Description:** Evaluates architectural perimeters, entry points, and trust
  boundaries to construct the threat model.
- **Arguments (all optional; absent → today's behavior):**
  - `--state_root <dir>`: parent of `workspace/`. If absent, use
    `./workspace/...` relative to the current directory. Locates
    `.mantis_state.json`, the KB, and the archive directory.
  - `--snapshot_id <id>`: the `SNAPSHOT_ID` this pass is pinned to. Used ONLY as
    the provenance value stamped into `THREAT_MODEL.md` (the `KB_SNAPSHOT:`
    line). If absent, fall back to `active_snapshot.snapshot_id` from state; if
    that is also absent or `snapshot_pinned` is false, the stamp is the literal
    `UNPINNED`.
  - `--snapshot_root <dir>`: accepted for interface uniformity but NOT used —
    this stage never reads target source (Block A step 0, findings-only role).

## Input/Output Contract

- **Reads**:
  - `workspace/.mantis_state.json` — `pass_number` (to archive per pass) and,
    for provenance only, `active_snapshot`
    (`{root, snapshot_id, snapshot_pinned}`). Both optional; absent → degraded
    (see Backward-compat).
  - `workspace/kb/architecture.md`.
  - `workspace/kb/entities/*.md`.
  - The EXISTING `workspace/kb/THREAT_MODEL.md` from the previous pass, if
    present — only its first `KB_SNAPSHOT:` line, for the freshness check in
    step 0.
- **Writes**:
  - `workspace/kb/THREAT_MODEL.md` (first line is a `KB_SNAPSHOT:` provenance
    header).
  - Archives the previous `workspace/kb/THREAT_MODEL.md` (if any) to
    `workspace/archive/kb/THREAT_MODEL_pass_${N}.md` BEFORE overwriting.
- **Preconditions**:
  - Knowledge Base files must exist and be populated.
- **Idempotency Guarantee**:
  - Copies the prior `THREAT_MODEL.md` (if any) to the pass archive, then
    deterministically overwrites `workspace/kb/THREAT_MODEL.md` in-place.
    Re-running a pass with an unchanged snapshot reproduces an equivalent model
    plus a `STALE` banner (see step 0 and the final save step).

## Instructions

```
LOCATOR RESOLUTION (before reading ANY target code or artifact):
0. ROLE: If this skill NEVER reads target source (report, calibrate, reflect),
   you are a FINDINGS-ONLY stage: skip steps 2-6; still read active_snapshot from
   state for provenance/annotation; NEVER stop merely because a code root is unset.
1. Determine CODE_ROOT, in this priority order:
   a. If --target_root is passed on THIS invocation, CODE_ROOT = --target_root.
      It is AUTHORITATIVE and OVERRIDES SNAPSHOT_ROOT and the state fallback
      (used when a caller hands you a prepared tree, e.g. a patched shadow).
   b. Else if --snapshot_root (or SNAPSHOT_ROOT) is passed, use it.
   c. Else read state_root/workspace/.mantis_state.json (state_root from
      --state_root if passed, else ./workspace/... relative to the current dir)
      -> active_snapshot.root / .snapshot_id / .snapshot_pinned.
   d. Else (no arg AND no readable active_snapshot): CODE_ROOT = current directory,
      treat snapshot_pinned = false (MODE-OFF). Do NOT stop.
2. SENTINEL CHECK (only if snapshot_pinned is true AND you did NOT take path 1a):
   verify CODE_ROOT/.mantis_snapshot_id exists and equals SNAPSHOT_ID. If missing
   or different -> STOP "snapshot sentinel mismatch". (A --target_root tree (1a) is
   deliberately mutated and is sentinel-EXEMPT.)
3. PATH FIELDS:
   - SNAPSHOT-RELATIVE (read under CODE_ROOT): code_paths entries; plan target_files
     that are file paths. Strip ONLY a trailing ":<digits>". A code_paths entry
     containing "://" is a URL/endpoint, NOT a file read. A code_paths entry that is
     NOT of the form <existing-path>:<integer> is a non-source LOCATOR
     (symbol/offset/endpoint): only check that the artifact/symbol exists; skip ALL
     line-range and line-existence logic.
   - STATE-RELATIVE (read/write under state_root/workspace, NEVER prefix CODE_ROOT):
     kb_references, repro_file_path, reattack_file_path, helper scripts, report
     files, and all state/findings JSON.
4. Never WRITE under CODE_ROOT when snapshot_pinned is true. Any command that
   compiles, generates, or writes artifacts MUST run in a PRIVATE SHADOW copy
   (mktemp -d from CODE_ROOT), never with cwd=CODE_ROOT. Read-only inspection may
   cd into CODE_ROOT.
5. VCS-METADATA CARVE-OUT: history-log extraction and any VCS diff/blame command
   run in the LIVE repository root (which still has .git/.hg/.repo), NOT CODE_ROOT
   (the snapshot copy strips VCS metadata). Do NOT stop merely because CODE_ROOT
   lacks .git/.hg/.repo.
6. Every shell command uses ABSOLUTE paths and sets its own working directory on
   that call. Do NOT assume the working directory persists between calls.
```

**Role for this stage (findings-only / KB-only).** `/mantis-threat-model` NEVER
reads target source. Every input it uses — `architecture.md`, `entities/*.md`,
the prior `THREAT_MODEL.md`, and `.mantis_state.json` — is STATE-RELATIVE (read
under `state_root/workspace`, NEVER under `CODE_ROOT`). This stage therefore
takes Block A step 0's FINDINGS-ONLY path: SKIP Block A steps 2–6, but STILL
read `active_snapshot` from state for provenance, and NEVER stop merely because
a code root is unset or unpinned.

Maintain a high-level Threat Model that explicitly defines *who* the attackers
are and *where* they can interact wit

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/google/mantis
git -C mantis checkout 9702f6eef495

Works in

1. 2026-10-31
   !CAUTION B 89 / 100

   first audit · source 9702f6eef495

Questions about mantis-threat-model

• github.com/google/mantis/tree/main/skills/mantis-threat-model — the audited source at commit 9702f6eef495 and every finding aboveObserved · 31 Oct 2026

Spotted something wrong? Report a correction · Methodology