Use agent-threat-model

Threat-model an AI agent deployment against the lethal trifecta

Threat-model an AI agent deployment against the lethal trifecta — private data, untrusted content, and an exfiltration vector — producing a per-capability matrix, a named architectural fix for every unsafe path, and a pre-launch checklist. Use before shipping an agent, when reviewing MCP server or tool permissions, when the user asks about prompt injection or data exfiltration risk, or when deciding whether an agent's capability surface is safe to expose.

Install it

npx skilldrop-cli install agent-threat-model                 # Claude Code, your user folder
npx skilldrop-cli install agent-threat-model --project       # Claude Code, this repo
npx skilldrop-cli install agent-threat-model --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the AI engineering pack: --pack ai-engineering installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Can this agent be prompt-injected?"
• "Review the MCP servers we're about to grant this agent"
• "Is it safe to give our support bot database access and an email tool?"
• "Could someone exfiltrate our data through this agent?"
• "Security review of our agent's tool permissions before launch"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Threat-model this API design"
• "Review this pull request for security bugs"
• "Our agent loops forever — how do I cap it?"

If another skill answers instead, ask for this one by name: "use agent-threat-model".

Check what you get

A good result:

• Every capability path is scored on all three legs. A row with a blank leg wasn't analyzed, it was skipped.
• No prompt-level mitigation is presented as a control. "The system prompt instructs the model to ignore injected instructions" mitigates nothing — it is precisely what the attack defeats. It may appear as defense in depth, never as the broken leg.
• No classifier is a broken leg either. Injection detectors raise cost for the attacker; they do not remove a leg. Architecture beats instructions.
• Egress is enumerated past the network tool. A model that lists only http_request failed the sweep — rendered markdown, error text, logs, and file writes are all channels.
• Every 🟥 is broken or signed off by a named role with a revisit trigger. No silent acceptance.
• Every fix has a verification step a reviewer can actually run — a config assertion, a test, an observed denial.
• Every 🟥 and 🟧 carries its OWASP IDs, taken from the mapping table, not guessed from a risk's title.
• "Read-only" is never a safety claim. Reading is how data reaches the attacker; the question is only where it goes next.

See a worked example

• support triage agent

Use something else when

• STRIDE on the surrounding system's architecture — that's threat-model
• Reviewing written code for vulnerabilities — that's devils-advocate or sonar-review
• Runaway loops, token burn, or infinite retries — that's agent-budget (a cost incident, not a security one)
• Output quality, hallucination, or eval design — that's llm-eval-harness
• After a confirmed leak — that's postmortem-generator

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: agent-budget, agent-loop-design, devils-advocate, llm-eval-harness, postmortem-generator, sonar-review, subagent-design, threat-model

Edit this page on GitHub · View source