Attack Surface Mapping for Router Bypass Prompt

This prompt is built for AI security architects and red-team engineers who need to produce a structured, defensible attack-surface map of an AI system's routing logic. The job-to-be-done is documentation and analysis, not live exploitation. Use it when you have a known or suspected multi-router architecture—intent classifiers, risk routers, model selectors, tool-access gates, escalation paths—and you need to inventory every point where an adversarial input could influence a routing decision. The output is a formal inventory of routing surfaces, vulnerability mappings, risk severity rankings, and defense-gap analysis that guides subsequent red-team testing and defensive engineering.

Do not use this prompt for single-model, single-handler systems with no routing logic; it assumes a multi-component routing topology. The operator must supply accurate system architecture details, including router types, handler mappings, trust boundaries, and existing defenses. The prompt does not execute attacks or generate adversarial payloads—it produces the map that tells you where to aim those payloads. For teams building automated red-teaming harnesses, this prompt is the prerequisite scoping phase that prevents blind spots in test coverage.

Before running this prompt, gather your architecture diagrams, router configurations, handler inventories, and any existing threat models. The quality of the output depends entirely on the accuracy and completeness of the input context. After generating the attack-surface map, use it to prioritize which routers to test first, which bypass techniques to attempt, and where to add defensive instrumentation. Pair this prompt with the sibling playbooks in the Routing Misdirection and Classification Evasion group—each targets a specific router type with concrete test payloads and evaluation criteria.

This prompt template is designed to be pasted directly into your AI system for a structured security review. It instructs the model to act as an AI security architect and systematically enumerate every routing surface, rank bypass risk severity, and score defensive coverage. The output is a structured attack-surface document, not a conversational summary. Before using this prompt, you must gather details about your system's architecture: the list of routers, their decision logic, the downstream handlers they protect, and any existing input sanitization or guard models. The more precise your input, the more actionable the output.

codeCopy
You are an AI security architect specializing in adversarial robustness for compound AI systems. Your task is to produce a structured attack-surface mapping for a multi-router AI system based on the provided architecture details.

## SYSTEM ARCHITECTURE
[SYSTEM_ARCHITECTURE_DESCRIPTION]

## ROUTER INVENTORY
[ROUTER_INVENTORY]

## DOWNSTREAM HANDLER MAP
[DOWNSTREAM_HANDLER_MAP]

## EXISTING DEFENSES
[EXISTING_DEFENSES]

## RISK TOLERANCE
[RISK_TOLERANCE]

## INSTRUCTIONS
1.  **Router Inventory Analysis:** For each router in the inventory, identify its decision type (e.g., intent classification, content moderation, tool access, model selection).
2.  **Vulnerability Mapping:** For each router, map potential bypass techniques from the following categories, specifying concrete attack vectors based on the router's logic:
    - **Obfuscation:** Encoding tricks, Unicode homoglyphs, delimiter smuggling.
    - **Context Manipulation:** Attention flooding, multi-turn state poisoning, role-play injection.
    - **Logic Exploitation:** Confidence score manipulation, few-shot contamination, tool output poisoning.
    - **Direct Injection:** Prompt extraction, instruction override, jailbreak attempts.
3.  **Risk Severity Ranking:** Rank each identified vulnerability as `CRITICAL`, `HIGH`, `MEDIUM`, or `LOW` based on the potential impact of a successful bypass. A `CRITICAL` risk allows an attacker to reach a handler that executes high-risk actions (e.g., code execution, financial transactions, PII access) without human approval.
4.  **Defense Gap Analysis:** For each vulnerability, evaluate the effectiveness of the existing defenses. Score the coverage as `STRONG`, `PARTIAL`, or `WEAK`. Identify specific gaps where a determined attacker could succeed.
5.  **Output Schema:** Produce the final output as a single JSON object conforming to the following schema:
    ```json
    {
      "attack_surface_summary": {
        "total_routers_analyzed": "<integer>",
        "critical_risk_count": "<integer>",
        "high_risk_count": "<integer>",
        "overall_defensive_posture": "<STRONG | MODERATE | WEAK>"
      },
      "router_vulnerabilities": [
        {
          "router_id": "<string>",
          "router_type": "<string>",
          "vulnerabilities": [
            {
              "vulnerability_id": "<string>",
              "bypass_category": "<string>",
              "attack_vector_description": "<string>",
              "risk_severity": "<CRITICAL | HIGH | MEDIUM | LOW>",
              "defensive_coverage": "<STRONG | PARTIAL | WEAK>",
              "defense_gap_explanation": "<string>"
            }
          ]
        }
      ],
      "prioritized_remediation_list": [
        {
          "priority": "<integer>",
          "vulnerability_id": "<string>",
          "recommended_action": "<string>"
        }
      ]
    }
    ```
6.  **Constraints:**
    - Do not simulate attacks or generate malicious payloads. Describe the attack vector conceptually.
    - Base all analysis strictly on the provided system architecture. Do not invent components.
    - If a router's logic is not fully specified, note the ambiguity and state your assumptions.
    - The output must be valid JSON. Do not include any text outside the JSON object.

To adapt this template, replace the square-bracket placeholders with your specific details. [SYSTEM_ARCHITECTURE_DESCRIPTION] should be a narrative of how user input flows through the system. [ROUTER_INVENTORY] is a list of every classifier, guard, or routing function, including its purpose and decision logic. [DOWNSTREAM_HANDLER_MAP] must detail what each router protects—such as specific tools, data stores, or model endpoints—and the privilege level of each. [EXISTING_DEFENSES] should list all pre-processing sanitizers, guard models, and output filters. Finally, [RISK_TOLERANCE] calibrates the analysis (e.g., 'A critical risk is any path to an unapproved code execution tool'). After running the prompt, validate the JSON output against the schema. A failed validation should trigger a retry with the error message included in the new prompt. For high-stakes systems, a human security architect must review the generated attack-surface map before it is used to prioritize engineering work.

This prompt is designed to run as a batch analysis step within a broader security review workflow, not as a one-off chat interaction. The primary integration point is a CI/CD pipeline, a scheduled security audit job, or an on-demand red-team tool. The harness must supply the router inventory, policy documents, and threat model context as structured inputs, then validate the output against a known schema before storing results in a security asset database. Because the output documents potential vulnerabilities in production routing logic, treat the generated report as sensitive material and restrict access to security engineers and AI platform architects.

Implement a validation and retry loop around the model call. The expected output is a JSON object with routers, vulnerabilities, defense_gaps, and risk_scores arrays. Use a JSON Schema validator to confirm structural integrity immediately after generation. If validation fails, retry up to two times with an augmented prompt that includes the specific validation error message. For model choice, prefer a model with strong reasoning capabilities and a large context window (e.g., Claude 3.5 Sonnet or GPT-4o) because the prompt requires holding multiple router definitions, policy documents, and threat mappings in context simultaneously. Do not use a lightweight classification model for this task—the reasoning depth required exceeds simple routing or triage models.

Log every generation attempt, including the input hash, model version, raw output, validation status, and any retry attempts, to an audit trail. This is critical for post-incident review if a bypass vulnerability is later exploited. After a valid output is produced, route it to a human review queue before it is accepted as a final assessment. The review step should allow a security engineer to confirm, reject, or annotate each finding. Rejected findings should be fed back into the prompt as negative examples for future runs. Avoid wiring this prompt directly into an automated remediation system—false positives in attack surface mapping can lead to unnecessary router reconfiguration and operational risk.