| name | eop-forge |
| description | The design-time Elevation of Privilege (EoP) skill — threat-model a system before the code exists, and extend the deck with an AI/agent suit. Use this skill to "threat model this design", walk STRIDE against a proposed design, RFC, or architecture sketch and write the threats into the design doc before implementation (shift-left), or to "add the AI suit" — a co-authored seventh suit covering prompt injection, tool/agent abuse, training-data and context poisoning, and over-broad agent permissions (a literal elevation of privilege). Trigger on "threat model this design", "shift-left threat modeling", "model this RFC for security", "walk STRIDE against our design", "add the AI/agent suit", or "threat model our agent/LLM system". Builds on eop-deck; emits an eop-session/1 that eop-referee can turn into backlog.
|
| license | CC-BY-3.0-US (deck content © 2009 Microsoft Corporation; AI suit CC BY 4.0, Stacey Vetzal 2026) |
| metadata | {"version":"0.1.0","author":"Stacey Vetzal"} |
eop-forge — model the design before the code exists
The cheapest threat to fix is the one you catch before you write a line of code. eop-forge
is the EoP suite's shift-left surface: it walks the deck against a proposed design — a
design doc, an RFC, an architecture diagram, even a verbal sketch — and writes the threats
into the design before implementation begins. It also carries the deck forward: a
co-authored AI & Agent suit for the systems we're building now, where the trump card —
elevation of privilege — has become literal.
Builds on eop-deck for grounding, the deck, and the bug-test. Its output is an
eop-session/1, so the same accepted threats can flow into eop-referee's
render_backlog.py as tickets — eop-forge does not re-implement backlog rendering.
Two things this skill does
- Shift-left threat modeling — ground a proposed design (no code yet) and walk STRIDE
(plus, for AI systems, the AI suit) against it, recording threats as design changes folded
back into the design doc. Procedure:
references/shift-left.md.
- The AI & Agent suit — a seventh, optional suit extending the deck for model/agent
systems. Data lives in
eop-deck (assets/ai-suit.json);
rationale and play guidance: references/ai-suit.md.
Shift-left — the design ritual
When asked to "threat model this design" / "model this RFC" / "do security on this before we
build it":
1. Ground the design (via eop-deck, kind: "design")
Use eop-deck's grounding procedure, but against the proposed design instead of a repo. Draw
the intended data-flow / trust-boundary diagram from the design and ground each card onto
planned components. Produce an eop-grounded-deck/1 with target.kind: "design" (the schema
explicitly supports this). Cards that can't be tied to the planned design are wild.
2. Decide whether to shuffle in the AI suit
If the design involves a model, retrieval/RAG, tools, or an autonomous agent, include the
AI & Agent suit (eop-deck/assets/ai-suit.json). If it's a conventional system, the
six STRIDE suits are enough. See references/ai-suit.md.
3. Walk the deck against the design
Suit by suit, for each grounded card ask the bug-test in design tense: "would we change
the design for that?" Work the Aces and the AI suit hardest — pre-code is exactly
where novel and AI-era threats are cheapest to design out. Record each accepted threat as an
eop-session/1 per-threat object whose artifact speaks design, not code:
candidate_fix → the design change (a boundary moved, a privilege scoped, a control
added) — not a code patch.candidate_test → the acceptance check the eventual implementation must pass.
The full method, design-tense bug-test, and a worked example:
references/shift-left.md.
4. Write the threats back into the design doc
The deliverable is a Threat model section inside the design doc — so the threats live with
the design, reviewed before code. Render it:
python3 .claude/skills/eop-forge/assets/render_design_threats.py <session.json> [--out <path.md>]
Save the eop-session/1 under the repo's .threat-model/ folder (the suite's shared
artifact location — see eop-deck's "Where artifacts go"). With no --out, the renderer
writes the fragment into .threat-model/ (created if missing); run it from the repo root.
It writes a markdown ## Threat model fragment (paste/append into the design doc): a headline
Novel & AI-era block first (Aces + AI suit — the shift-left payoff), then accepted threats
by suit as design risk → design change → acceptance check, and a compact Considered &
deferred list for rejected ones. Stdlib only; auto-locates both deck.json and
ai-suit.json; warns-not-fails. The same <session.json> also feeds eop-referee's
render_backlog.py if you want tickets too.
The deliverable (plan's "done when")
A forward-looking deck (STRIDE + the AI suit) and a design ritual: pointing this at a proposed
design yields a threat-model section written into the design doc before any code exists, plus an
eop-session/1 ready to become backlog.
The guardrail (from the whitepaper)
AI grounds candidate threats against the proposed design and removes the blank-page friction —
but it does not replace the humans arguing over whether a threat is real and worth a design
change. The argument is the learning. eop-forge surfaces concrete, named, design-tense
candidates; people and the bug-test decide. Keep it in that supporting role.
Provenance
The base deck is © 2009 Microsoft Corporation, CC BY 3.0 US, via eop-deck. The AI & Agent
suit is an original co-authored extension (CC BY 4.0, Stacey Vetzal, 2026), informed by the
OWASP Top 10 for LLM Applications and emerging agentic-system risks. Never paraphrase a card —
quote it from eop-deck's assets.
