Sample threat model — STRIDE, LLM-backed returns API

The Acme Returns API fronts an LLM-backed support agent that answers return questions, looks up orders, and — within limits — issues refunds. A STRIDE walk over its data-flow diagram produced 9 threats across four trust boundaries. Two stand out: prompt injection through the customer channel (TM-03) and the agent calling the refund tool beyond its intended scope (TM-08) — together they turn a support conversation into an unaudited financial action. First moves: deny-by-default per-tool RBAC with human approval on refunds, guardrail isolation of privileged instructions, and per-request context isolation so one tenant's PII never reaches another's session.

6 of 9 register rows carry citations; the linked ones were fetched live from the gateway's corpora during the run. Two rows (TM-05, TM-07) matched no source row and ship as marked analyst drafts; one row (TM-06) lists candidate provisions but its regulatory basis is unresolved. None of the three is papered over.

Acme Returns AB (fictional) runs a customer-support returns flow: a public chat channel where an LLM agent handles return requests end-to-end. Components: the returns API edge (authentication, session handling), the LLM support agent (system instructions plus per-request retrieved context), two tools the agent can call (order lookup and refund), and a multi-tenant customer & order store holding PII.

Show the text form

[Customer / attacker]
      |  chat + REST over HTTPS                 <- B1: internet -> edge
[Returns API edge]   (OAuth 2.0 access token, session)
      |  prompt assembly                        <- B2: untrusted input -> model context
[LLM support agent]  (system instructions + customer message + retrieved context)
      |  tool calls                             <- B3: model output -> privileged action
[Order lookup] ---- [Refund tool]  (financial action)
      |  queries                                <- B4: tenant isolation
[(Customer & order store -- multi-tenant, PII)]

• B1Internet → API edge. Anonymous internet traffic meets the authenticated API surface (OAuth 2.0 tokens, sessions).
• B2Untrusted input → model context. Customer text is assembled into the same context window as privileged system instructions.
• B3Model output → privileged action. Agent output selects and parameterises tool calls — including the refund tool, a financial action.
• B4Tenant isolation. Retrieval crosses into a multi-tenant store holding PII and order history.

One row per threat, walked per element and boundary. Severity and likelihood are analyst-assigned and would be confirmed or corrected in senior review.

Linked citations are rows the gateway returned during this run, with source URL, publisher, and license preserved. Unlinked identifiers (OWASP LLM01, CWE-77, ATT&CK T1548, CWE-269, CWE-200 and the regulation references) carry over from the previously published sample register for this system. Rows with no matching source say so instead of carrying an invented reference.

Register rows mapped to controls from the gateway's security-controls catalog. Fragments are quoted as fetched.

If the returns agent ships to customers as a product with digital elements — for example as an embeddable support widget — the Cyber Resilience Act's essential cybersecurity requirements attach to it. The gateway returned the operative annex:

Cyber Resilience Act, Annex I — Reg (EU) 2024/2847 — “ESSENTIAL CYBERSECURITY REQUIREMENTS — Part I Cybersecurity requirements relating to the properties of products with digital elements” (Publications Office of the European Union).

In a paid engagement each register row is mapped to the specific Annex I point it engages. This sample stops at the annex level: the fetched excerpt covers the Part I heading, not the itemised list, and we don't cite deeper than what was fetched. Applicability is a scoping input, not a conclusion — whether Acme's deployment is a product placed on the market, rather than a pure service, decides if the CRA attaches at all. A real engagement records that determination; here it is marked open.

• STRIDE over the DFD. All six categories walked per element and boundary of the §2 diagram; classic categories extended for the LLM surface — Tampering to prompt injection, Elevation of privilege to tool-permission escalation, Information disclosure to context-window leakage.
• Sources fetched through the Ansvar gateway. The STRIDE pattern library, CAPEC, OWASP (ASVS 4.0.3, WSTG 4.2), the security-controls catalog, and the Cyber Resilience Act text — every linked citation is a row the gateway returned during the run, with source URL, publisher, and license preserved. Nothing is cited from model recall.
• Refusal discipline. No fetched source → the row says so (TM-05, TM-07). Regulatory basis not confirmable at article level → the row is flagged regulatory_basis_unresolved (TM-06). Gaps are marked, never filled with plausible text.
• What a paid engagement adds. Your real architecture and a scoping call; enrichment across ATT&CK, CWE, and your sector's regulations; and a named senior reviewer who confirms or corrects every row before it ships.

Senior review:   [shown for format — fictional sample, nothing to certify]
Reviewer:        [named reviewer — OSCP / CISSP / AI red team]
Date:            [—]

A paid engagement ships only after the named reviewer has validated every row and signed here. This sample is published unsigned, on purpose, so you can read the document exactly as it leaves the engine.

Want this for a real system? Scope a threat model →