Few-shot poisoning is a prompt-injection technique that corrupts an AI model’s behaviour by placing malicious examples into the few-shot context it uses for in-context learning. The model then imitates those examples during inference, so the attack can steer outputs, tool use, or policy compliance without changing the model weights.
How Few-Shot Poisoning Works
Few-shot poisoning targets the examples, not the model weights. By seeding the few-shot context with malicious demonstrations, an attacker can make the model infer the wrong pattern and carry that pattern into the current request.
This matters because in-context learning is designed to generalise from examples quickly. If the examples are untrusted, the model may imitate harmful output styles, follow unsafe instructions, or mirror an attacker’s preferred policy interpretation without any change to the underlying model.
Why Few-Shot Poisoning Is Dangerous
The attack is effective precisely because few-shot prompts are often treated as helpful context rather than as a security boundary. In practice, poisoned examples can steer the model toward unsafe tool calls, data disclosure, or rule-breaking behaviour while still looking like normal prompt content.
Its impact is broader than simple output corruption. If a model uses examples to decide how to respond, a poisoned context can influence classification, decision support, workflow routing, or automated actions downstream of the model.
Where Few-Shot Poisoning Shows Up
Few-shot poisoning is most relevant wherever examples are assembled dynamically from user input, retrieved content, shared prompt libraries, or prior conversations. Any system that reuses example-based prompting across tenants, sessions, or workflows increases the chance that hostile content will be treated as training signal rather than as untrusted text.
The risk also rises when prompt builders blend retrieved snippets, analyst notes, or user-provided samples into the same context window without strong separation. The model cannot reliably distinguish a legitimate demonstration from a malicious one unless the application constrains what can be included and how it is interpreted.
How Teams Reduce Exposure
Defences start with strict control over who can influence few-shot content and how that content is selected. Trusted example curation, input filtering, prompt templating, and clear separation between instructions and demonstrations all reduce the chance that malicious examples shape model behaviour.
It also helps to monitor for unusual prompt patterns, repeated adversarial phrasing, and unexpected shifts in model behaviour after prompt or retrieval changes. OWASP Agentic AI Top 10 is useful here because it frames prompt-level abuse, tool misuse, and privilege-related failures as concrete application risks. MITRE ATLAS adversarial AI threat matrix is also relevant for mapping context poisoning and prompt injection to recognised adversarial techniques.
Risk and Threat Considerations
Few-shot poisoning creates a trust boundary problem: the model may treat attacker-supplied examples as legitimate behavioural cues. That can lead to policy drift, unsafe tool invocation, or hidden instruction following even when the base model itself is unchanged.
Failure mechanism: A malicious example in the prompt acts like a local demonstration, so the model generalises from poisoned context instead of from the intended policy or task pattern.
Impact: The result can be compromised outputs, unauthorized actions, leaked data, or downstream automation that behaves as if the attacker’s example were authoritative.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI06 — Memory & Context Poisoning | Few-shot poisoning is a context-poisoning attack on an AI system's prompt state. |
| Recommendation — Test prompt pipelines for context poisoning and block untrusted examples from steering model behaviour. | ||
| MITRE ATLAS | TBD — Context Poisoning | ATLAS catalogs adversarial AI techniques including prompt and context poisoning. |
| Recommendation — Map poisoned prompt patterns to adversarial techniques and add detections for abnormal context shifts. | ||
| NIST AI RMF | GOVERN — Govern | AI risk governance applies to prompt-sourced behaviour changes and untrusted context handling. |
| Recommendation — Define ownership for prompt sources, review prompt-risk decisions, and require validation before release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Prompt construction and trust-boundary design are software architecture concerns in AI applications. |
| Recommendation — Separate instructions from untrusted examples and validate prompt inputs before they reach the model. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | Prompt contents and retrieved examples must be protected as sensitive model input during transfer. |
| Recommendation — Protect prompt and retrieval pipelines so untrusted parties cannot tamper with model inputs. | ||
Practitioner Guidance
Why practitioners should care: Few-shot prompts are often built from reusable content, retrieval results, or user-contributed examples, which makes them easy to overlook as an attack surface. Treat every example as content that can change model behaviour, not just as harmless context.
What to watch for: Look for sudden changes in tone, policy compliance, tool selection, or refusal behaviour after prompt assembly changes. If behaviour shifts only when certain examples are present, the prompt construction path deserves review.
Practitioner takeaway: The safest pattern is to minimise untrusted examples, constrain what can enter the few-shot block, and test prompt behaviour with adversarial samples before production use.