adversarial-design-review

Analyze system designs for adversarial abuse paths and trust boundary failures.

2|Updated Apr 30, 2026
One-click install
npx skills add https://github.com/NlightNFotis/skills --skill adversarial-design-review-nlightnfotis
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: adversarial-design-review
Source: https://github.com/NlightNFotis/skills/tree/main/adversarial-design-review
Command: npx skills add https://github.com/NlightNFotis/skills --skill adversarial-design-review-nlightnfotis

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you uncover how a design can be abused, bypassed, confused, or quietly gamed before it ships. It is especially useful when normal happy-path reviews miss trust boundaries, malicious actors, prompt injection risks, or incentive-driven misuse.

Core Features & Use Cases

  • Boundary-Centered Threat Modeling: Maps assets, trust boundaries, actors, and invariants so you can see where security and correctness actually change hands.
  • Abuse Case Generation: Uses STRIDE, LLM-specific attack patterns, and incentive failure modes to produce concrete attack scenarios instead of vague warnings.
  • Risk Ranking and Mitigation Design: Prioritizes issues by impact and feasibility, then recommends boundary-level controls, tests, and telemetry.
  • Use Cases: Review authentication flows, plugin systems, tool-calling agents, APIs, secret handling, untrusted file or network inputs, and metrics that could be gamed.

Quick Start

Ask the adversarial-design-review skill to assess your API, CLI, agent, or plugin design by identifying trust boundaries, abuse cases, top-ranked risks, and concrete mitigations.

Frequently Asked Questions about adversarial-design-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find prompt injection risks in my LLM agent design before launch?

Threat modeling your LLM agent design identifies prompt injection risks by mapping trust boundaries, enumerating actors, and applying LLM-specific abuse cases to uncover hidden attack paths before release.

What is the best way to perform a security review for a plugin architecture?

A security review for plugin architectures requires mapping trust boundaries between untrusted plugins and core systems, then generating STRIDE-based abuse cases to design boundary-level mitigations.

How do you assess trust boundary failures in an API authentication flow?

Assessing trust boundary failures in authentication flows involves enumerating actors and invariants, then using impact-feasibility ranking to prioritize security tests and telemetry for boundary-level controls.

Can I use STRIDE threat modeling to find abuse cases in tool-execution pipelines?

Yes, applying STRIDE threat modeling to tool-execution pipelines identifies incentive gaming and untrusted input handling risks by generating concrete attack scenarios and recommending boundary-level mitigations.

When do I need an adversarial design review for my CLI or API?

Adversarial design reviews are needed when happy-path reviews miss trust boundaries, malicious actors, or incentive-driven misuse in CLIs, APIs, and cross-boundary operations involving secrets, PII, or privileges.

What limitations exist when applying risk assessment to LLM safety designs?

Risk assessment for LLM safety requires structured threat modeling with actor enumeration and LLM-specific abuse cases, but cannot guarantee complete coverage of all emergent prompt injection or incentive gaming vectors.