agent-threat-modellisted

# agent-threat-model Answers one question about an agent deployment: **can text the agent reads cause it to send private data somewhere an attacker can see?** An LLM cannot reliably separate instructions from data, so any agent holding all three legs of the lethal trifecta — private data, untrusted content, an exfiltration vector — is compromised by construction, not by bug. The output is architectural: which leg gets broken, on which path, by which design change. Complements `threat-model`, which runs STRIDE on the system the agent lives in. That model asks how the system is attacked; this one asks what the agent can be talked into doing. Run both on an agent that handles real data. ## How to respond 1. **Inventory the capability surface before scoring anything.** From the input — an agent description, MCP/tool config, system prompt, `agent-loop-design` output, or repo — extract four lists: - **Data reach** — everything the agent can read, *transitively*. A filesystem tool reaches every secret in `.env`; a database tool reaches every tenant the credential permits. Reach is what the credential allows, not what the feature intends. - **Content sources** — everything that puts tokens into the context window: user messages, web fetches, retrieved documents, file contents, tool results, PR comments, email, calendar invites, subagent output. - **Tools** — every callable, including the ones that feel inert (`read_file`, `search`, `fetch`). - **Egress paths** — every