Use this skill when the work involves authentication, authorization, trust boundaries, sensitive data, input validation, or vulnerability assessment. Activated when designing or modifying AuthN/AuthZ flows; handling or storing PII, financial, or health data; processing user input or file uploads; integrating with third-party APIs; designing system boundaries; reviewing pull requests (implicitly always active); or when the user mentions security concerns, vulnerabilities, or asks for a security a
SkillScore91Maintained
Automatic
◆Security & AppSec pack
Last verified 8/8/2026
What it changes
Passed 20 of 22 test cases with the skill, and 18 of 22 without it.
Without skill82%
With skill91%
Checks it passed that the model alone missed
rejects granting wildcard permissions
includes the section header ## Trust Boundaries
includes the severity subheading ### 🟡 Medium / Low
and 1 more in the full report
2 fixed18 passed either way2 still failing0 broke
Pass-rate lift
+9 pp
Tokens
+106%
Agent turns
0%
Response time
-10%
Model gemini-3.6-flashMeasured 8/8/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 2
Prompt
We are adding a feature to our administrative platform that allows team leads to issue API tokens and manage user permissions across microservices. Please conduct a security audit on this flow. Structure your report by outlining the security scope and where data transitions across trust boundaries. Provide a tabular STRIDE analysis, followed by prioritized vulnerability findings split by severity tier. Each vulnerability should outline the exploit path, potential impact radius, and code or architecture fixes required. End with general hardening guidance.
What was checked, without and with the skill
Checked
Without skill
With skill
includes the section header ## Trust Boundaries
Missed
Passed
includes the section header ## Threat Assessment (STRIDE)
Missed
Passed
includes the severity subheading ### 🟡 Medium / Low
Missed
Passed
case-06 · gemini-3.6-flash · 8/8/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md250 linessingle file
APPLICATION SECURITY & THREAT MODELING
WHEN TO USE THIS
Designing or modifying Authentication (AuthN) or Authorization (AuthZ) flows
Handling, storing, or transmitting sensitive data (PII, financial, health)
Processing user input or file uploads
Integrating with third-party APIs or external systems
Designing system boundaries and network architecture
User asks for a security audit or mentions specific vulnerabilities
NEVER DO
Trust client-side validation as a primary defense mechanism
Store secrets or API keys in code, plaintext files, or environment variables committed to version control
Use blocklists (denylist) to filter input — use allowlists
Build custom cryptography or hashing algorithms
Grant wildcard (*) IAM or database permissions to bypass blockers
Fail open — when in doubt, deny access
Trust data from internal microservices without validation
MINDSET — ASSUME BREACH
The staff-level security mental model operates on one core assumption: Assume Breach.
Do not trust the network, the user, the internal microservices, the database, or the third-party API. Perimeter defense (firewalls) is insufficient because threats often originate from inside the perimeter or bypass it via application logic flaws.
Security is never an afterthought, a final audit, or a compliance checklist. It is integrated directly into the architectural design phase ("Shift Left") to prevent flaws before implementation begins.
View the system through the eyes of a malicious actor: "How can I break this? How can I bypass this? How can I use this feature in a way the developer never intended?" Do not rely on obscurity. Rely on mathematically proven cryptographic standards and robust, centralized authorization mechanisms.