mirror of
https://github.com/OWASP/www-project-ai-testing-guide.git
synced 2026-07-15 23:47:19 +02:00
Update 2.1.2_Identify_RAI_threats.md
This commit is contained in:
@@ -85,7 +85,15 @@ The following tables provide a structured overview, facilitating clear visibilit
|
||||
|
||||
## **Four Pillars of AI Testing**
|
||||
|
||||
Need an intro and this note
|
||||
Artificial‑intelligence systems blend traditional software, complex data pipelines, and probabilistic models. This hybrid nature means that many well‑established security testing practices (e.g., network scanning, penetration testing, secure‑code review) remain indispensable, yet they are no longer sufficient on their own. AI brings new threat vectors—prompt manipulation, data poisoning, model extraction, and unintended agency, to name only a few—that require purpose‑built test strategies.
|
||||
|
||||
To address these emerging risks systematically, we group AI‑specific validation activities into four complementary pillars:
|
||||
|
||||
1. AI Application Testing – validating everything a human or downstream machine touches: chat interfaces, APIs, agents/plugins, and multi‑modal UX flows.
|
||||
2. AI Model Testing – stress‑testing the core model itself throughout training, fine‑tuning, and inference to expose weakness in robustness, fairness, and alignment.
|
||||
3. AI Infrastructure Testing – hardening the serving stack, orchestration layer, and plug‑in/agent sandbox so that the model’s power cannot be abused.
|
||||
4. AI Data Testing – assuring the integrity, provenance, diversity, and legality of data that feed the model before, during, and after training.
|
||||
Together, these pillars create a defense‑in‑depth framework: weaknesses caught late in one pillar are often prevented early in another, and insights from any pillar can be fed back into secure‑by‑design requirements for subsequent releases.
|
||||
|
||||
The threat scenarios presented in this guide highlight AI-specific risks and corresponding security considerations. While we identify a range of potential threats, some associated security controls and test procedures fall outside the scope of this guide. Our intent is not to replace or duplicate existing, well-established security testing methodologies, but rather to extend them by focusing on threats unique to AI systems.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user