$npx -y skills add briiirussell/cybersecurity-skills --skill prompt-injectionAudit applications for AI prompt injection, agent security, and LLM permission boundary vulnerabilities. Use when the user mentions 'prompt injection,' 'LLM security,' 'AI security,' 'jailbreak,' 'indirect prompt injection,' 'prompt leaking,' 'AI red team,' 'LLM vulnerabilities,'
| 1 | # Prompt Injection — AI/LLM Security Audit |
| 2 | |
| 3 | Audit applications that use AI features, LLM integrations, or AI agents for prompt injection, privilege escalation, and authorization bypass vulnerabilities. |
| 4 | |
| 5 | Cross-references: `threat-modeling` for design-time AI risk modeling on new AI features (before this skill applies); `owasp-audit` for the XSS / output-rendering patterns that overlap when LLM output reaches the browser (sanitize on render, JSON-LD breakout); `api-audit` for the API surface that LLM tools and MCP servers expose; `ai-risk-management` for the broader governance frame this skill sits within — prompt injection is the security slice of AI risk; AI RMF covers the rest (fairness, robustness, transparency, drift, lifecycle). |
| 6 | |
| 7 | ## Background |
| 8 | |
| 9 | Prompt injection is the #1 vulnerability in LLM-integrated applications (OWASP Top 10 for LLMs, LLM01). It occurs when untrusted input influences the instructions an LLM follows, causing it to ignore its system prompt, leak secrets, or take unauthorized actions. |
| 10 | |
| 11 | **Three attack classes:** |
| 12 | - **Direct injection:** Attacker provides malicious input directly to the LLM (e.g., chat input, form field processed by AI) |
| 13 | - **Indirect injection:** Attacker plants malicious instructions in data the LLM will later consume (e.g., web pages, emails, documents, database records, tool outputs, RAG chunks) |
| 14 | - **Cross-privilege injection:** Lower-privileged user plants injection in shared data that a higher-privileged user's AI session consumes, escalating privileges through the AI layer |
| 15 | |
| 16 | ## Methodology |
| 17 | |
| 18 | ### Step 1: Map the AI Attack Surface |
| 19 | |
| 20 | Identify every place the application uses AI. This includes direct LLM API calls AND higher-level AI features: |
| 21 | |
| 22 | ``` |
| 23 | Grep for LLM API calls: |
| 24 | - openai, anthropic, cohere, replicate, ollama |
| 25 | - ChatCompletion, messages.create, generate, complete |
| 26 | - langchain, llamaindex, autogen, crewai |
| 27 | |
| 28 | Also look for AI features that may not be obvious LLM calls: |
| 29 | - AI-powered search or recommendations |
| 30 | - AI content generation (summaries, descriptions, emails) |
| 31 | - AI chatbots or copilots embedded in the app |
| 32 | - AI-assisted form completion or auto-fill |
| 33 | - AI moderation or classification |
| 34 | - AI-driven workflow automation |
| 35 | - MCP (Model Context Protocol) servers and tool registrations |
| 36 | ``` |
| 37 | |
| 38 | For each AI integration, document: |
| 39 | 1. **What is the system prompt?** Read it fully. |
| 40 | 2. **What user input reaches the prompt?** Trace every variable interpolated into the prompt template. |
| 41 | 3. **What external data reaches the prompt?** (RAG results, tool outputs, web scrapes, database records, file contents, emails) |
| 42 | 4. **What actions can the LLM take?** (tool/function calls, code execution, database writes, API calls, email sending) |
| 43 | 5. **How is the LLM output used downstream?** (rendered as HTML, executed as code, used in SQL, passed to another LLM) |
| 44 | 6. **What user role/permissions context does the AI operate under?** (its own service account? the requesting user's session? an admin context?) |
| 45 | |
| 46 | ### Step 2: Audit Prompt Construction |
| 47 | |
| 48 | Check how prompts are assembled. Look for: |
| 49 | |
| 50 | **Unsanitized interpolation:** |
| 51 | ```python |
| 52 | # VULNERABLE — user input directly in prompt |
| 53 | prompt = f"Summarize this: {user_input}" |
| 54 | |
| 55 | # VULNERABLE — external data injected without marking |
| 56 | prompt = f"Answer based on this context: {rag_results}" |
| 57 | ``` |
| 58 | |
| 59 | **Missing input/output boundaries:** |
| 60 | ```python |
| 61 | # BETTER — clear delimiters separating instructions from data |
| 62 | prompt = f"""Summarize the text between the <document> tags. |
| 63 | <document> |
| 64 | {user_input} |
| 65 | </document>""" |
| 66 | ``` |
| 67 | |
| 68 | **Secrets in system prompts:** |
| 69 | ```python |
| 70 | # VULNERABLE — API keys, database credentials, or internal URLs in system prompt |
| 71 | system = f"You are a helper. Use API key {API_KEY} to call..." |
| 72 | ``` |
| 73 | |
| 74 | Check for these patterns: |
| 75 | - User input concatenated or f-string interpolated into prompts without delimiters |
| 76 | - RAG/retrieval results injected without sanitization or boundary markers |
| 77 | - Tool/function outputs fed back into prompts without validation |
| 78 | - System prompts containing secrets, internal URLs, or sensitive business logic |
| 79 | - Chain-of-thought or scratchpad content exposed to the user |
| 80 | |
| 81 | ### Step 3: Audit Output Handling |
| 82 | |
| 83 | Check what happens with LLM responses: |
| 84 | |
| 85 | **Rendered as HTML (XSS via LLM):** |
| 86 | ```jsx |
| 87 | // VULNERABLE — LLM output rendered as raw HTML |
| 88 | <div dangerouslySetInnerHTML={{ __html: llmResponse }} /> |
| 89 | ``` |
| 90 | |
| 91 | If the LLM can be tricked into outputting `<script>` tags or event handlers, and the output is r |