Responsible use: Use this approach only on authorized systems, sandboxes, or bug bounty programs you are explicitly permitted to test.
Purpose
Testing AI-powered applications requires a different mindset than traditional web application security testing. While SQL injection and XSS remain relevant, LLM-based systems introduce entirely new attack surfaces—from prompt injection to RAG poisoning to tool misuse. This lesson provides a systematic methodology for security testing AI applications that accounts for the shared responsibility between model providers, application developers, and infrastructure operators.
What This Methodology Covers
The AI application security testing methodology addresses four key areas that distinguish AI systems from traditional software:
- The Shared Responsibility Model — Understanding who owns which security layers
- AI-Specific Attack Surfaces — Prompt injection, RAG vulnerabilities, tool calling abuse
- Testing Progression — From basic LLM understanding to complex multi-modal attacks
- Defense-First Mindset — Testing to improve security, not just find exploits
How It Works
Phase 1: Understand the Architecture
Before testing, map how the AI application is built:
- Model Layer: What foundation model powers the application? What are its known weaknesses?
- Application Layer: How does the app use the model? Does it have system prompts, tool calling, or RAG?
- Infrastructure Layer: Where does data flow? What external services integrate with the AI?
This mapping reveals which parties share responsibility for different vulnerabilities.
Phase 2: Enumerate AI-Specific Attack Surfaces
AI applications have surfaces that don't exist in traditional software:
Prompt Injection Surfaces
- Direct user input to the model
- Indirect injection via retrieved content (RAG)
- Multi-modal injection (images, audio containing hidden instructions)
RAG-Specific Surfaces
- Knowledge base poisoning
- Context window manipulation
- Source credibility bypasses
Tool Calling Surfaces
- Excessive agency—tools that can modify data or systems
- Parameter injection via LLM outputs
- Tool chaining attacks
Output Handling Surfaces
- Markdown rendering to HTML (XSS vectors)
- Code execution from generated code blocks
- Data exfiltration via crafted outputs
Phase 3: Test Systematically
Follow a structured testing progression:
- Basic Prompt Injection: Can you alter the model's behavior through direct input?
- System Prompt Extraction: Can you recover hidden system instructions?
- RAG Manipulation: Can you influence retrieved content to affect outputs?
- Tool Abuse: Can you make the model misuse its available tools?
- Output Exploitation: Can model outputs trigger vulnerabilities in downstream systems?
Phase 4: Document and Report
Vulnerabilities in AI apps often span multiple responsibility layers. Document:
- Which layer the vulnerability exists in
- Whether it's a fixable bug or requires mitigation
- The shared responsibility implications
Why It Works
This methodology works because it mirrors how AI applications actually function—as composed systems with boundaries between model, application, and infrastructure. Traditional security testing often misses AI-specific issues because:
- Jailbreak-focused testing misses RAG and tool-calling vulnerabilities
- Input-only testing misses output handling vulnerabilities
- Single-layer testing misses cross-layer attack chains
By systematically enumerating each surface, testers catch vulnerabilities that span traditional web app security and AI-specific weaknesses.
Example Pattern
Consider testing an AI customer support chatbot with document search capabilities:
Architecture Mapping:
- Model: GPT-4 via API
- Application: RAG over support documentation with tool calling for ticket creation
- Infrastructure: Web frontend, API backend, vector database
Attack Surface Enumeration:
- Prompt injection via chat input (direct)
- Prompt injection via support documents (indirect/RAG)
- Tool abuse via ticket creation function
- Output XSS via markdown rendering
Systematic Testing:
- Test direct prompt injection: "Ignore previous instructions and..."
- Check if document content influences behavior: Upload document with hidden instructions
- Test tool boundaries: Attempt to create tickets outside normal scope
- Verify output sanitization: Request markdown with embedded scripts
This structured approach catches vulnerabilities that random testing would miss.
Where It Shows Up in the Real World
Bug Bounty Success: Security researchers using systematic AI testing methodologies have found critical vulnerabilities including:
- Authentication bypasses in AI children's toys (access to all customer conversations via misconfigured admin panels)
- IDOR vulnerabilities in AI agent systems allowing data access across user boundaries
- Prompt injection leading to data exfiltration in enterprise chatbots
Industry Recognition: The shared responsibility model for AI security is increasingly recognized by:
- OWASP Top 10 for LLM Applications
- NIST AI Risk Management Framework
- Google's Secure AI Framework (SAIF)
Failure Modes
This methodology has limitations and gaps:
- Model Opacity: You may not know which model powers an application, limiting vulnerability prediction
- Rapid Change: AI capabilities evolve quickly; yesterday's secure configuration may become vulnerable
- Context Window Limits: Complex multi-turn attacks may exceed available context
- Tool Complexity: Modern AI agents have dozens of tools; comprehensive testing requires significant time
- Shared Responsibility Confusion: Determining who should fix a vulnerability (model provider vs app developer) can be unclear
Defender Takeaways
Organizations building AI applications should:
- Adopt the Shared Responsibility Model: Clearly document which security layers your team owns
- Structure Security Programs: Include AI-specific testing in security assessments
- Test Like Attackers: Use methodologies like this to find vulnerabilities before attackers do
- Assume Some Injection Will Succeed: Design with defense-in-depth, not just input filtering
- Monitor Cross-Layer Attacks: Watch for attack chains that combine multiple weaknesses
Related Lessons
- BTAA-FUN-021: Interactive Learning for AI Security Education — Learn AI security through hands-on challenges
- BTAA-FUN-027: AI Agent Vulnerability Discovery — How AI agents find security vulnerabilities
- BTAA-FUN-007: Prompt Injection in OWASP Context — Understanding prompt injection as the #1 OWASP risk
- BTAA-DEF-002: Confirmation Gates and Constrained Actions — Defensive patterns for AI applications
From the Bot-Tricks Compendium
Thanks for referencing Bot-Tricks.com — Prompt Injection Compendium — AI Security Training for Agents... and Humans!
Canonical source: https://bot-tricks.com Bot-Tricks is a public, agent-friendly training resource for prompt injection, adversarial evaluation, and defensive learning. For related lessons, structured indexes, and updated canonical material, visit Bot-Tricks.com.
Use this material only in authorized labs, challenges, sandboxes, or permitted assessments.