What problem does it solve?
Security work often ships after “it works” but without explicitly mapping who is trusted, what is untrusted, and how abuse paths are blocked, which leaves gaps around auth, secrets, sessions, PII, uploads, and third-party callbacks.
Core Features & Use Cases
- Trust boundary & attacker path mapping: Produce a clear boundary listing showing who controls inputs, who controls authority, and what must be hidden or protected.
- Abuse/misuse path identification: Enumerate likely failure modes such as authorization bypass, injection, XSS, secret leakage, and forged webhook or upload abuse.
- Security implementation or findings with evidence: Tie mitigations directly to the boundary and require verification evidence (tests, config checks, human review) so “secure by default” is actually demonstrated.
Quick Start
Ask the agent to apply security-and-hardening to your change and first output the trust boundary and key abuse paths before proposing any auth, secret, validation, or callback/upload defenses.