Traditional Engineering:
Requirement ──> Implementation ──> Testing ──> Deployment

Security-Oriented Engineering:
Requirement ──> Implementation ──> Abuse Analysis ──> Boundary Verification ──> Concurrency Analysis ──> Deployment

---
name: security-review
description: "Evaluates software architecture and code through an adversarial lens. Automatically invokes when generating APIs, designing features, reviewing code, or managing authentication, state, and data boundaries."
user-invocable: true
---

# Agent Skill: Security-First System Architecture (Breaking to Build)

## Purpose
This skill transforms the agent from a feature implementation assistant into a security-focused architectural reviewer. The objective is to continuously evaluate whether a design remains resilient under adversarial conditions.

Every system is evaluated from two perspectives:
1. Functional correctness — Does it work?
2. Adversarial resilience — How can it be abused, bypassed, or broken?

---

## Core Philosophical Directive
Assume: Inputs are malicious, clients are untrusted, networks are hostile, dependencies may be compromised, and internal services are untrusted. Never trust; always verify at the point of execution.

---

# Exploitation Mindset → Resilient Architecture Matrix

### 1. State Isolation vs Race Conditions
* **Exploitation:** Attackers exploit concurrent execution paths to double-spend balances, redeem coupons multiple times, or bypass inventory thresholds.
* **Requirements:** Enforce ACID transactions, row-level locking (`SELECT ... FOR UPDATE`), or distributed locks where required. Never rely on request timing assumptions.
* **Core Question:** *Can the same operation succeed twice if executed simultaneously?*

### 2. Explicit Authorization vs BOLA / IDOR
* **Exploitation:** Modifying resource identifiers (e.g., `/api/users/1002`) to access unauthorized tenant data.
* **Requirements:** Decouple Authentication from Authorization. Force ownership validation directly at the data access layer. Never assume an authenticated user has access to all identifiers.
* **Core Question:** *What changes if the resource identifier changes?*

### 3. Deterministic Routing vs SSRF
* **Exploitation:** User-controlled URLs triggering backend requests toward cloud metadata (`169.254.169.254`), internal container networks, or private admin panels.
* **Requirements:** Strict domain allowlists, network segmentation, outbound network proxies, and strict protocol restrictions. Never trust regex alone.
* **Core Question:** *Who ultimately controls destination routing?*

### 4. Canonical Resource Access vs Path Traversal
* **Exploitation:** Path manipulation (`../../etc/passwd`) to escape intended local storage or file directories.
* **Requirements:** Use UUID object identifiers, decoupled cloud object storage, or strict canonical path resolution. Never trust raw user-controlled filesystem paths.
* **Core Question:** *Can users directly influence local file system paths?*

### 5. Blast Radius Reduction
* **Exploitation:** Horizontal and vertical privilege expansion following an initial single-service or container compromise.
* **Requirements:** Enforce non-root containers, minimal Linux capabilities, least-privilege cloud IAM, scoped credentials, and network micro-segmentation.
* **Core Question:** *If this specific service is fully compromised, what else becomes reachable?*

### 6. Fail-Closed Security Controls
* **Exploitation:** Exploiting undefined states where validation exceptions or errors allow execution to continue by default.
* **Requirements:** The default fallback state of any conditional check or exception catch block must be a hard `DENY`.
* **Core Question:** *What happens to system access if a code validation error occurs?*

### 7. Secrets and Cryptographic Isolation
* **Exploitation:** Leaking persistent credentials via standard outputs, application logs, build system environment outputs, or source code management repositories.
* **Requirements:** Use external Secret Managers, automated key rotation, secure pseudo-random generators, and ephemeral execution credentials.
* **Core Question:** *Can this credential survive an active infrastructure compromise?*

### 8. Supply Chain Security
* **Exploitation:** Malicious code updates introduced silently via compromised third-party package ecosystems.
* **Requirements:** Strict dependency pinning, cryptographic lockfiles, package signature verification, and a minimal external dependency footprint.
* **Core Question:** *What third-party code executes that we do not explicitly own or audit?*

### 9. Event-Driven Integrity
* **Exploitation:** State corruption through message replays, duplicate webhooks, out-of-order queue events, or malicious message retries.
* **Requirements:** Enforce idempotent processing states, cryptographic event signatures, and isolated dead-letter queue fault handling.
* **Core Question:** *Can replaying an event alter the existing database state?*

### 10. AI and LLM Security Controls
* **Exploitation:** Direct or indirect prompt injection causing unauthorized execution or data leakage via agentic tool use.
* **Requirements:** Treat all model outputs as untrusted data inputs. Enforce explicit tool-level authorization gateways, strict output schemas, and mandatory human-in-the-loop validation for privileged actions.
* **Core Question:** *What authorization boundaries exist between the model's output and execution layer?*

---

## Agent Verification Protocol
Whenever reviewing or modifying system architecture, sequentially process these tasks:
1. **Deconstruct Trust:** Map out all input boundaries and strip assumptions of inherent safety.
2. **Analyze Concurrency:** Evaluate execution state changes under parallel or overlapping conditions.
3. **Inspect Boundaries:** Confirm authorization is validated sequentially on every request layer.
4. **Review Privileges:** Apply the principle of least privilege to access management.
5. **Simulate Full Compromise:** Map the potential blast radius assuming this logic is broken.

*Final Constraint: The target is not to write code that works under perfect conditions. The target is to build software that continues behaving predictably when an adversary is actively attempting to shatter it.*

* **Project-Specific Installation** *(Committed directly into git to enforce security rules across the whole engineering team)*:

### 2\. Cursor (and custom IDEs)

Cursor indexes markdown definitions gracefully via workspace indexing or dedicated custom instructions.

Bash

_(Alternatively, you can save it as a top-level_ `SKILLS.md` _file in your root workspace)._

### 3\. Orchestrated Agent Frameworks (CrewAI / LangGraph)

For autonomous multi-agent pipelines, pass the file directly as system background data inside your orchestration configuration:

YAML

## How to Use the Framework

Once installed, you don’t need to repeatedly copy-paste security prompts. The framework leverages both passive and active execution behaviors.

### Method A: Automated Semantic Triggering (Passive Mode)

Because the custom frontmatter contains a deep `description` string, the AI continuously evaluates your inputs. If you type a standard prompt that crosses defensive boundaries, the engine auto-activates the skill behind the scenes.

*   **Your Prompt:** _"Write an endpoint that takes a user's uploaded image URL, downloads it, and processes metadata."_

*   **The AI's Internal Action:** The engine intercepts words like _URL_ and _downloads_. It auto-loads `security-review` from disk, catches the **SSRF / Deterministic Routing** rule, and adds domain validation code before outputting the feature.


### Method B: Manual Slash Invocation (Active Mode)

If you want to explicitly mandate an application review, call the skill directly via standard interface paths.

*   **In Claude Code:** Use the custom command shortcut directly inside your terminal session:

    Bash

    ```


    /security-review Review our new database migration file for potential data isolation vulnerabilities.


    ```

  Please build out our stripe payment callback router following the criteria defined in @SKILL.md