Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →modu-ai/moai-ref-llm-security
AI/LLM defensive security reference: prompt-injection defense, OWASP LLM Top 10 defensive mapping, MCP and agentic tool-call hardening, training-data poisoning detection, model-output validation and guardrails, MITRE ATLAS defensive correlation, and NIST AI RMF governance. Agent-extending skill that amplifies backend, security, and AI-application engineering with production-grade defensive patterns for LLM-backed systems. NOT for: offensive techniques (jailbreak authoring, attack-payload craftin
Passed 19 of 22 test cases with the skill, and 11 of 22 without it.
and 10 more in the full report
8 fixed11 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are fine-tuning a custom model on public domain technical articles and user-submitted feedback. Developers plan to clean data solely by removing standard duplicate lines. How do we detect and prevent dataset poisoning?
| Checked | Without skill | With skill |
|---|---|---|
| Maps data poisoning risks to OWASP LLM04. | Missed | Passed |
| Requires tracking data lineage and verifying provenance for dataset sources. | Missed | Passed |
| Implements canary artifacts in training data to detect unexpected model influence. | Missed | Passed |
The instructions your model reads when the skill loads.
Defensive practitioner reference for hardening LLM-backed applications and agents.
Every section is framed as defense, hardening, detection, or verification — it
describes the misconfiguration, how to detect it, and how to prevent it, never how
to exploit it. Cross-domain web-app vulnerabilities live in
moai-ref-owasp-checklist; API design lives in moai-ref-api-patterns.
Apply when reviewing or building an LLM-backed system — a chat product, a retrieval-augmented application, an autonomous agent, or an MCP server. The material assumes an untrusted-input threat model: any text the model reads (user turns, retrieved documents, tool results, file contents) may carry adversarial instructions, and any text the model emits may be acted on downstream.
The core defensive insight: an LLM does not distinguish "data" from "instructions" the way a parser does. Treat every text channel that reaches the model as a boundary where adversarial instructions can enter.
| Channel | Entry risk | Primary defense |
|---|---|---|
| End-user prompt | Direct prompt injection | Instruction-hierarchy enforcement, input screening |
| Retrieved documents (RAG) | Indirect prompt injection | Provenance tagging, content isolation, retrieval allowlist |
| Tool / function results | Injected instructions in tool output | Treat tool output as untrusted data, re-validate before re-prompting |
| System / developer prompt | Leakage, override | Minimize secrets in prompt, assume prompt is recoverable |
| Model output | Improper downstream handling | Schema validation, encoding, never auto-execute raw output |
| Training / fine-tuning data | Poisoning | Data lineage, provenance verification, canary detection |
The OWASP Top 10 for LLM Applications (2025 edition) is the canonical risk index for LLM systems. Each row below states the risk, the defensive check, and the hardening control. Citations are for defensive correlation only.
| ID | Risk | Defensive check | Hardening control |
|---|---|---|---|
| LLM01 | Prompt Injection | Can external text override system instructions? | Instruction-hierarchy enforcement, input/output screening, content isolation |
test cases passed, vs 11 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.