Attack Surface Enumeration Prompt Template

This prompt is designed for AI security architects and red-team engineers who need to produce a structured, exhaustive map of an AI system's attack surface before launching any adversarial testing campaign. The primary job-to-be-done is to move from a vague understanding of 'the system has prompts' to a concrete, auditable inventory of every trust boundary, data flow, and injection surface. This includes direct user inputs, system prompts, retrieved documents, tool outputs, multi-turn conversation state, and any other data that influences model behavior. The ideal user is someone who can read an architecture diagram or system design document and translate it into the structured fields this prompt requires, such as [SYSTEM_ARCHITECTURE_DESCRIPTION] and [DATA_FLOW_DIAGRAM_NOTES].

You should use this prompt at the very start of a red-team engagement, during the design phase of a new AI feature, or as part of a periodic security audit of an existing production system. The output is not a list of attack payloads; it is a pre-attack reconnaissance map. It forces you to identify where instructions originate, which components trust which data sources, and where an attacker could inject malicious content. For example, a RAG system's attack surface isn't just the user prompt; it includes the vector database, the web scraper that populates it, and the summarization tool that processes retrieved chunks. This prompt ensures none of those are overlooked. Do not use this prompt to generate actual injection strings or to evaluate the severity of a specific vulnerability; pair it with the sibling fuzzer and evaluation prompts in this content group for those downstream tasks.

The required context is a detailed technical understanding of the target system. You cannot use this prompt effectively with only a product marketing description. You need to provide concrete details about prompt assembly order, tool definitions, retrieval pipelines, and multi-turn state management. If you lack this information, the first step is to gather it from the engineering team. The output will be a structured enumeration that serves as the index for your entire red-team campaign. After generating this map, your next action should be to use it to prioritize attack vectors and select the appropriate fuzzing harnesses, such as the 'Indirect Injection Test Case Generator' for retrieved content or the 'Tool Misuse Scenario Generator' for agent tool calls. A common failure mode is treating this as a one-time artifact; the attack surface changes with every prompt update, model upgrade, or new tool integration, so this enumeration must be versioned and reviewed alongside the system it describes.

This template is the core of your attack surface review. It instructs the model to act as a security architect and produce a structured enumeration of every point where untrusted data enters the prompt assembly process. The output is designed to be machine-readable so you can feed it directly into downstream risk scoring, fuzzing harness configuration, or a defense coverage matrix. Before using this prompt, you should have a clear architectural diagram or description of your AI system's data flows, including retrieval sources, tool outputs, user input channels, and any multi-agent handoff points.

codeCopy
You are an AI security architect conducting a systematic attack surface review. Your task is to enumerate every point where untrusted data can enter the prompt assembly process for the system described below.

## SYSTEM DESCRIPTION
[SYSTEM_DESCRIPTION]

## INSTRUCTIONS
1. Identify every injection surface where external data enters the prompt, including:
   - Direct user messages
   - Retrieved documents or chunks from [RETRIEVAL_SOURCES]
   - Tool outputs from [TOOL_LIST]
   - Agent-to-agent handoff messages
   - System prompt variables populated from external sources
   - Few-shot examples loaded from [EXAMPLE_SOURCES]
   - Memory or conversation history from [MEMORY_SOURCES]
   - Metadata, headers, or configuration injected at runtime
2. For each surface, describe:
   - The data source and its trust level (untrusted, semi-trusted, internal)
   - The injection vector type (direct, indirect, stored, reflected)
   - The prompt component it flows into (system, developer, user, tool, assistant)
   - Whether the data passes through any sanitization or validation before prompt assembly
3. Identify trust boundaries where data crosses from one trust zone to another.
4. Flag any blind spots where injection could occur but is not currently monitored.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "system_summary": "Brief description of the analyzed system",
  "injection_surfaces": [
    {
      "surface_id": "unique identifier",
      "data_source": "source description",
      "trust_level": "untrusted | semi-trusted | internal",
      "injection_vector": "direct | indirect | stored | reflected",
      "target_prompt_component": "system | developer | user | tool | assistant",
      "sanitization_applied": true or false,
      "sanitization_detail": "description of any sanitization",
      "risk_notes": "any additional risk context"
    }
  ],
  "trust_boundaries": [
    {
      "boundary_id": "unique identifier",
      "from_zone": "source trust zone",
      "to_zone": "destination trust zone",
      "crossing_surfaces": ["surface_id references"],
      "controls_in_place": ["list of controls"]
    }
  ],
  "blind_spots": [
    {
      "description": "unmonitored injection path",
      "severity": "high | medium | low",
      "recommendation": "suggested remediation"
    }
  ],
  "coverage_assessment": {
    "total_surfaces": number,
    "surfaces_with_sanitization": number,
    "high_risk_unprotected": number,
    "completeness_confidence": "high | medium | low"
  }
}

## CONSTRAINTS
- Do not speculate about system components not described in the system description.
- If the system description is incomplete for a full analysis, note this in blind_spots rather than guessing.
- Prioritize completeness over brevity. Missing a surface is worse than flagging a low-risk one.
- For each surface, assume an attacker with full knowledge of the system architecture.

To adapt this template, replace the square-bracket placeholders with your actual system details. The [SYSTEM_DESCRIPTION] should be a thorough architectural summary covering all data flows, not a one-line product description. For [RETRIEVAL_SOURCES], list every knowledge base, vector store, or document source that feeds into RAG pipelines. For [TOOL_LIST], enumerate every API, function, MCP server, or external service the agent can call. For [EXAMPLE_SOURCES] and [MEMORY_SOURCES], identify where few-shot demonstrations and conversation history are stored and loaded from. If any of these are empty, explicitly state that to avoid the model hallucinating surfaces. After running this prompt, validate the output by checking that every surface you know about appears in the list, and that the coverage_assessment.completeness_confidence matches your own assessment. For high-risk systems, have a second reviewer compare the output against your architecture diagram before feeding results into a fuzzing harness or risk register.

This prompt is designed to be used as a structured analysis step within a broader AI security review process, not as a one-off chat interaction. The output is a machine-readable enumeration of injection surfaces, trust boundaries, and data flows that should feed into downstream risk scoring, fuzzing campaign configuration, and defense evaluation rubrics. In an automated harness, you would invoke this prompt programmatically with a system architecture description, model configuration, and tool definitions as input, then validate the structured output before passing it to subsequent analysis stages.

To integrate this into an application, wrap the prompt in a function that accepts a [SYSTEM_DESCRIPTION] object containing the model's role, instruction hierarchy, available tools, data sources, and trust boundaries. The function should call the LLM with response_format set to the defined JSON schema and a low temperature (0.0–0.2) for deterministic enumeration. After receiving the response, run a validation layer that checks: (1) the JSON parses correctly against the expected schema, (2) every enumerated surface includes a trust_boundary and data_flow_direction field, (3) no surface is listed without an associated injection_vector example, and (4) the coverage_gaps array is non-empty, indicating the model recognized its own blind spots. If validation fails, retry once with an error message injected into the prompt context explaining which field was missing or malformed. Log every enumeration result with a unique review_id for audit trails and regression comparison when the system architecture changes.

For high-risk production systems, do not treat this prompt's output as the final authority. Route the validated enumeration to a human review queue where a security architect can confirm, reject, or augment each surface. Store the reviewed enumeration as the canonical attack surface baseline. When the system prompt, tool set, or data pipeline changes, re-run this prompt and diff the output against the baseline to detect new injection surfaces or trust boundary shifts. Wire the diff into your CI/CD pipeline as a pre-release gate: if new, unreviewed surfaces appear, block the deployment until a human signs off. Avoid using this prompt on systems where the architecture is not fully documented—garbage-in, garbage-out applies, and missing context will produce a false sense of coverage.