$npx -y skills add SnailSploit/Claude-Red --skill offensive-ai-securityWhen this skill is active: 1. Load and apply the full methodology below as your operational checklist 2. Follow steps in order unless the user specifies otherwise 3. For each technique, consider applicability to the current target/context 4. Track which checklist items have been
| 1 | # SKILL: AI Pentest |
| 2 | |
| 3 | ## Metadata |
| 4 | - **Skill Name**: ai-security |
| 5 | - **Folder**: offensive-ai-security |
| 6 | - **Source**: https://github.com/SnailSploit/offensive-checklist/blob/main/ai.md |
| 7 | |
| 8 | ## Description |
| 9 | AI/LLM security offensive checklist: prompt injection, jailbreaking, model extraction, training data poisoning, adversarial inputs, LLM-assisted attack automation, and AI system reconnaissance. Use when assessing AI/ML systems, red-teaming LLMs, or researching AI attack vectors. |
| 10 | |
| 11 | ## Trigger Phrases |
| 12 | Use this skill when the conversation involves any of: |
| 13 | `AI security, LLM security, prompt injection, jailbreak, model extraction, training data poisoning, adversarial input, AI red team, ML security, RAG poisoning, AI attack` |
| 14 | |
| 15 | ## Instructions for Claude |
| 16 | |
| 17 | When this skill is active: |
| 18 | 1. Load and apply the full methodology below as your operational checklist |
| 19 | 2. Follow steps in order unless the user specifies otherwise |
| 20 | 3. For each technique, consider applicability to the current target/context |
| 21 | 4. Track which checklist items have been completed |
| 22 | 5. Suggest next steps based on findings |
| 23 | |
| 24 | --- |
| 25 | |
| 26 | ## Full Methodology |
| 27 | |
| 28 | # AI Pentest |
| 29 | |
| 30 | ## Shortcut |
| 31 | |
| 32 | - Understand the AI system, its components (LLM, APIs, data sources, plugins), and functionalities. Identify critical assets and potential business impacts. |
| 33 | - Collect details about the model, underlying technologies, APIs, and data flow. |
| 34 | - Vulnerability Assessment: |
| 35 | - Use tools like `garak`, `LLMFuzzer` to identify common vulnerabilities. |
| 36 | - Craft prompts to test for injections, jailbreaks, and biased outputs. |
| 37 | - Probe for data leakage and insecure output handling. |
| 38 | - Assess plugin security and excessive agency. |
| 39 | - Attempt to exploit identified vulnerabilities and chain them for greater impact (e.g., prompt injection leading to data exfiltration via excessive agency). |
| 40 | - If access is gained, explore possibilities like model theft, further data exfiltration, or lateral movement. |
| 41 | |
| 42 | ## Mechanisms |
| 43 | |
| 44 | AI/LLM vulnerabilities stem from several core mechanisms: |
| 45 | |
| 46 | - **Instruction Following & Ambiguity**: LLMs are designed to follow instructions (prompts). Ambiguous, malicious, or cleverly crafted prompts can trick them into unintended actions. The boundary between instruction and data is often blurry. |
| 47 | - **Data Dependency**: Models learn from vast datasets. |
| 48 | - **Training Data Issues**: Biased, poisoned, or sensitive data in training sets can lead to skewed, insecure, or privacy-violating outputs. |
| 49 | - **Input Data Issues**: Untrusted input data (user prompts, documents, web content) can be a vector for attacks like indirect prompt injection. |
| 50 | - **Complexity and Lack of Transparency ("Black Box" Nature)**: The internal workings of large models are complex and not always fully understood, making it hard to predict all possible outputs or identify all vulnerabilities. |
| 51 | - **Integration with External Systems (Agency & Plugins)**: LLMs are often given "agency" – the ability to interact with other systems, APIs, and tools (plugins). If these integrations are insecure or the LLM has excessive permissions, it can become a powerful attack vector. |
| 52 | - **Output Handling**: How the LLM's output is used by downstream applications is critical. If unvalidated output is fed into other systems, it can lead to code execution, XSS, SSRF, etc. |
| 53 | - **Resource Consumption**: LLMs can be resource-intensive. Specially crafted inputs can lead to denial of service by exhausting computational resources. |
| 54 | - **Supply Chain**: Vulnerabilities can exist in pre-trained models, third-party datasets, or the MLOps pipeline components. |
| 55 | - **Overreliance**: Humans placing undue trust in LLM outputs without verification can lead to the propagation of misinformation or the execution of flawed, AI-generated advice/code. |
| 56 | - **Policy‑Layer Conflicts** – layered provider, vendor and application rules can clash, creating latent bypass windows. |
| 57 | - **Sparse Fine‑Tuning Drift** – lightweight adapter training frequently overrides base‑model safety alignment. |
| 58 | - **Multi‑Modal Expansion** – V‑L and audio‑language models inherit text flaws while adding steganographic channels. |
| 59 | - **Model Extraction via Embeddings** – probing embedding space boundaries through carefully crafted prompts can leak training data membership or approximate model parameters. |
| 60 | - **Virtualization Attacks** – convincing the model it operates in a test/sandbox environment to bypass production safety rules. |
| 61 | - **Constitutional Jailbreaks** – exploiting conflicts between layered safety rules (provider policy vs. developer system prompt vs. user context). |
| 62 | - **Tool Chaining Escalation** – multi-agent frameworks allowing Agent A to delegate to Agent B to reach privileged Agent C, bypassing single-hop restrictions. |
| 63 | - **Memory Poisoning** – injecting persistent malicious instructions into agent memory systems (AutoGPT, CrewAI, LangChain Memory). |
| 64 | - **Tokenization Exploits** – zero-width characters, Unicode normalization mismatches between input sanitizers and model tokenizers. |
| 65 | |
| 66 | ## Hunt |
| 67 | |
| 68 | ### Preparation |
| 69 | |
| 70 | 1. |