Document Store Poisoning Simulation Prompt

This prompt is designed for red teams and security engineers conducting structured tabletop exercises to evaluate their organization's resilience against retrieval-augmented generation (RAG) poisoning attacks. The core job-to-be-done is to simulate a full attack lifecycle—from initial access and adversarial document planting through index propagation to final answer corruption—in a controlled, offline environment. Use this prompt when you need a detailed simulation report that maps the attacker's actions to specific detection gaps in your RAG pipeline and provides concrete, prioritized remediation recommendations. It is ideal for security architects validating trust boundaries, MLOps teams hardening retrieval infrastructure, and compliance officers documenting due diligence against this specific threat vector.

The prompt requires the operator to provide a detailed scenario definition, including the target RAG architecture, assumed attacker access level, and the specific retrieval surface being tested (e.g., vector DB, keyword index, hybrid search). The output is a structured simulation report, not an executable attack script. It should include an attack timeline, a mapping of actions to MITRE ATLAS techniques where applicable, identified detection gaps with severity ratings, and a set of defensive recommendations. Crucially, this prompt must never be used for live production attacks, automated penetration testing without direct human supervision, or to generate actual malicious documents for deployment. The simulation is a thought exercise and architectural review tool, not a weapon. All outputs should be treated as sensitive security documentation and handled according to your organization's data classification policies.

Before using this prompt, ensure you have a clear, documented authorization for the tabletop exercise and a defined scope that excludes any interaction with live production systems. The next step after generating the simulation report is to conduct a human-led review of the findings, validate the feasibility of the attack path against your specific controls, and translate the remediation recommendations into engineering tickets for your RAG and security teams. Avoid the common failure mode of treating the simulation output as a complete penetration test; it is a starting point for deeper, hands-on investigation by qualified security personnel.

This section provides the core prompt template for orchestrating a tabletop-style red-team exercise. It is designed to simulate the complete lifecycle of a retrieval poisoning attack—from initial access and document planting through index propagation and final answer corruption. The template uses square-bracket placeholders so you can adapt it to your specific RAG architecture, document stores, and detection capabilities without rewriting the simulation logic. Use this prompt when you need a structured, repeatable way to evaluate your organization's detection and response readiness against poisoned document stores.

Below is the copy-ready prompt template. Replace each square-bracket placeholder with your environment-specific values before execution. The template assumes you have defined your target system's architecture, access scenarios, and evaluation criteria in advance. For high-risk production systems, always run this simulation in a sandboxed or staging environment first, and ensure outputs are reviewed by security engineers before any findings are acted upon.

textCopy
You are a red-team simulation engine for testing RAG pipeline resilience against document store poisoning attacks. Your task is to simulate a complete attack lifecycle and produce a structured assessment report.

## SIMULATION PARAMETERS
- Target RAG System Description: [TARGET_SYSTEM_DESCRIPTION]
- Document Store Type: [DOCUMENT_STORE_TYPE] (e.g., vector DB, SharePoint, Confluence, custom index)
- Retrieval Pipeline Architecture: [RETRIEVAL_PIPELINE_ARCHITECTURE] (e.g., hybrid search, keyword-only, embedding-based)
- Attacker Access Scenario: [ACCESS_SCENARIO] (e.g., compromised employee account, API key leak, insider threat, public-facing upload)
- Attacker Goal: [ATTACKER_GOAL] (e.g., override financial data, suppress competitor mentions, insert false policy)
- Detection Systems in Place: [DETECTION_SYSTEMS] (e.g., audit logs, content moderation, anomaly detection, manual review)
- Simulation Time Window: [TIME_WINDOW] (e.g., 24 hours, 7 days, 30 days)
- Output Schema: [OUTPUT_SCHEMA]
- Risk Level: [RISK_LEVEL] (low, medium, high, critical)

## SIMULATION INSTRUCTIONS
1. **Initial Access Phase**: Describe how the attacker gains the specified access level. Include the method, likely indicators, and detection difficulty.
2. **Document Planting Phase**: Generate [NUMBER_OF_DOCUMENTS] adversarial documents designed to achieve the attacker's goal. For each document, specify:
   - Document title and format
   - Content strategy (authority mimicry, factual overlap, instruction injection)
   - Planting method and target location
   - Stealth characteristics and expected detection difficulty
3. **Index Propagation Phase**: Model how the planted documents enter the retrieval index. Include:
   - Ingestion pipeline steps affected
   - Time to index availability
   - Whether chunking or embedding processes alter the payload
4. **Answer Corruption Phase**: Simulate [NUMBER_OF_TEST_QUERIES] user queries and predict:
   - Expected clean answer (without poisoning)
   - Expected poisoned answer (with planted documents)
   - Whether the model cites the poisoned source
   - Confidence that the attack succeeds
5. **Detection Gap Analysis**: Identify where existing detection systems would and would not catch each phase. Rate each gap by severity.
6. **Remediation Recommendations**: Propose concrete fixes for each detection gap, prioritized by impact and implementation difficulty.

## CONSTRAINTS
- Do not generate actual executable attack code or exploits.
- Base all assessments on the provided architecture description, not assumptions.
- Flag any phase where insufficient information prevents accurate simulation.
- For [RISK_LEVEL] critical or high, include a human review checkpoint recommendation.
- Output must conform exactly to the specified [OUTPUT_SCHEMA].

## OUTPUT FORMAT
Return a JSON object matching the [OUTPUT_SCHEMA] with the following structure:
{
  "simulation_metadata": {
    "target_system": "string",
    "access_scenario": "string",
    "risk_level": "string",
    "timestamp": "ISO8601"
  },
  "attack_timeline": [
    {
      "phase": "initial_access | document_planting | index_propagation | answer_corruption",
      "timestamp_offset": "string",
      "actions": ["string"],
      "indicators": ["string"],
      "detection_difficulty": "low | medium | high | critical"
    }
  ],
  "planted_documents": [
    {
      "id": "string",
      "title": "string",
      "format": "string",
      "content_strategy": "string",
      "planting_method": "string",
      "target_location": "string",
      "stealth_rating": "low | medium | high",
      "expected_detection_time": "string"
    }
  ],
  "test_query_results": [
    {
      "query": "string",
      "clean_answer": "string",
      "poisoned_answer": "string",
      "cites_poisoned_source": true,
      "attack_success_confidence": 0.0
    }
  ],
  "detection_gaps": [
    {
      "phase": "string",
      "gap_description": "string",
      "severity": "low | medium | high | critical",
      "existing_coverage": "string"
    }
  ],
  "remediation_recommendations": [
    {
      "gap_reference": "string",
      "recommendation": "string",
      "priority": "low | medium | high | critical",
      "implementation_difficulty": "low | medium | high",
      "estimated_impact": "string"
    }
  ],
  "human_review_checkpoints": ["string"],
  "simulation_confidence_notes": "string"
}

To adapt this template for your environment, start by filling in the [TARGET_SYSTEM_DESCRIPTION] with enough detail that the simulation can reason about concrete attack paths—include your document store type, retrieval architecture, and any known access controls. The [ACCESS_SCENARIO] should reflect a realistic threat model for your organization; avoid testing only the most extreme scenarios and instead prioritize the paths an actual attacker would take. After running the simulation, validate the output against your [OUTPUT_SCHEMA] using a structured parser, and route any findings rated critical or high to your security team for immediate review. Do not use this prompt to generate actual attack code or to test production systems without explicit authorization and isolation.

This prompt is designed for a tabletop exercise, but its real value comes from wiring it into a repeatable, automated harness. The goal is not just to generate a report once, but to run this simulation against every major change to your RAG pipeline—new parsers, updated embedding models, or modified chunking strategies. The harness should treat the LLM as the simulation engine, feeding it a structured scenario and capturing the resulting attack timeline, detection gaps, and remediation recommendations in a machine-readable format for comparison over time.

To build the harness, wrap the prompt in a scripted workflow. First, define a JSON configuration for your scenario, including the [TARGET_SYSTEM] description, [ATTACKER_PROFILE], and [ACCESS_LEVEL]. Feed this configuration into the prompt template. Critically, constrain the output with a strict JSON schema so you can diff results across runs. Use a model with strong reasoning capabilities (like GPT-4o or Claude 3.5 Sonnet) and set a low temperature (0.1-0.2) for deterministic, repeatable attack paths. After the LLM generates the simulation, run a validation step: check that the output JSON parses correctly, that all required fields (timeline, gaps, recommendations) are present, and that the attack steps logically follow from the initial access level. Log the raw prompt, the configuration, and the validated output to an audit trail for future regression testing.

For integration into a CI/CD pipeline, treat this as a security gate. After a PR changes your ingestion or retrieval code, the harness should re-run the simulation with a standard set of attacker profiles. A second LLM call, acting as an evaluator judge, can compare the new simulation output against a baseline to flag regressions—for example, a new parser that inadvertently makes document planting easier. The evaluator should score the severity of any new detection gaps. If the score crosses a threshold, fail the CI check and alert the security team. This moves the prompt from a one-off document to an operational safety net that catches retrieval poisoning vulnerabilities before they reach production.