New Feature Injection Risk Assessment Prompt

This prompt is designed for product security teams and AI security architects who need to evaluate whether a new feature introduces prompt injection surfaces before it ships. Use it during feature design review, security gate checks, or pre-launch threat modeling. The prompt assumes you have a feature specification, an existing system architecture diagram, and a current inventory of deployed defenses. It produces a risk assessment that identifies new injection surfaces, maps them to existing controls, flags coverage gaps, and recommends new controls.

This is not a replacement for manual threat modeling or red-team testing. It is a structured first pass that helps security reviewers avoid blind spots and produce consistent, comparable assessments across features. The prompt works best when the feature specification is concrete—vague feature descriptions produce vague risk assessments. You should have already completed an AI System Injection Surface Enumeration for the base system before using this prompt, so the existing surface inventory and defense catalog are available as input context.

Do not use this prompt for runtime incident response, real-time injection detection, or operational monitoring. It is a design-time assessment tool, not a production guard. If you need to evaluate injection risk in a live system under active attack, use the Continuous Monitoring Rule Generation for Injection Surfaces prompt instead. If you need to assess risk across an entire system rather than a single new feature, start with the AI System Injection Surface Enumeration Prompt Template. This prompt is scoped to feature-level delta analysis—what changes, what new risks appear, and what defenses need to be added or modified.

The output is a structured risk assessment, not a pass/fail gate. Human review is required before any finding is treated as a release blocker. The prompt can miss novel attack vectors not represented in its training data, and it cannot reason about implementation details that aren't included in the feature specification. Always pair this assessment with manual review by a security engineer who understands the full system context.

This prompt template is designed to be copied directly into your AI harness, test runner, or manual review workflow. It forces a structured risk assessment by requiring the model to enumerate new injection surfaces introduced by a feature, evaluate the applicability of existing defenses, and recommend new controls where coverage is missing. The output is a machine-readable risk assessment that can be validated against a schema before being reviewed by a security engineer.

textCopy
You are an AI security architect conducting a pre-launch injection risk assessment for a new feature. Your task is to identify every new prompt injection surface this feature introduces, evaluate whether existing defenses apply, and recommend any required new controls.

[FEATURE_NAME]: The name of the feature being assessed.
[FEATURE_DESCRIPTION]: A detailed description of what the feature does, its user flows, and its technical components.
[FEATURE_ARCHITECTURE]: A summary of the feature's architecture, including data flow, model interactions, tool use, retrieval steps, and output rendering.
[EXISTING_DEFENSES]: A list of currently deployed injection defenses, including input sanitization, instruction hardening, tool authorization policies, output filtering, and monitoring rules.
[SYSTEM_PROMPT_EXCERPT]: The relevant portion of the system prompt that governs this feature's behavior.
[TOOL_DEFINITIONS]: If the feature uses tools, provide their schemas, argument definitions, and authorization rules.
[RETRIEVAL_CONFIG]: If the feature uses RAG, describe the retrieval pipeline, data sources, and how retrieved content is rendered.
[OUTPUT_SCHEMA]: Return a JSON object with the following structure:
{
  "feature_name": "string",
  "assessment_date": "string (ISO 8601)",
  "risk_summary": {
    "overall_severity": "CRITICAL | HIGH | MEDIUM | LOW | INFO",
    "new_surface_count": "integer",
    "existing_defense_coverage_pct": "integer (0-100)",
    "new_controls_required": "integer"
  },
  "new_injection_surfaces": [
    {
      "surface_id": "string (unique identifier)",
      "surface_name": "string",
      "surface_type": "DIRECT_INPUT | INDIRECT_INJECTION | TOOL_ARGUMENT | RETRIEVED_CONTENT | OUTPUT_RENDERING | MULTI_TURN_STATE | OTHER",
      "description": "string (how an attacker could inject malicious instructions through this surface)",
      "attack_vector_example": "string (a concrete example of an injection attempt)",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "exploitability": "HIGH | MEDIUM | LOW",
      "existing_defenses_applicable": ["string (list of existing defense names that apply)"],
      "defense_gap": "string (why existing defenses are insufficient, or null if fully covered)",
      "recommended_new_controls": ["string (specific new controls to implement)"]
    }
  ],
  "existing_defense_evaluation": [
    {
      "defense_name": "string",
      "applies_to_this_feature": "boolean",
      "coverage_assessment": "FULL | PARTIAL | NONE",
      "gap_description": "string (if coverage is not FULL, explain what's missing)"
    }
  ],
  "required_new_controls": [
    {
      "control_name": "string",
      "control_type": "INPUT_SANITIZATION | INSTRUCTION_HARDENING | TOOL_AUTHORIZATION | OUTPUT_FILTERING | MONITORING | HUMAN_APPROVAL | OTHER",
      "target_surface_ids": ["string (list of surface_ids this control addresses)"],
      "implementation_guidance": "string (how to implement this control)",
      "priority": "IMMEDIATE | BEFORE_LAUNCH | POST_LAUNCH | NICE_TO_HAVE"
    }
  ],
  "launch_recommendation": "CLEARED | CONDITIONAL (list conditions) | BLOCKED (list blocking issues)",
  "reviewer_notes": "string (any additional context, assumptions, or limitations of this assessment)"
}

[CONSTRAINTS]:
- Do not fabricate surfaces. Only identify surfaces that actually exist in the feature architecture.
- For each surface, provide a concrete, realistic attack vector example.
- If a surface is fully covered by existing defenses, set defense_gap to null and recommended_new_controls to an empty array.
- If overall_severity is CRITICAL or HIGH, launch_recommendation must not be CLEARED.
- Do not include generic security advice. Every recommendation must be specific to the feature described.
- If the feature architecture is unclear or incomplete, note this in reviewer_notes and do not guess.

Before running this prompt, replace every square-bracket placeholder with feature-specific detail. The quality of the assessment depends entirely on the completeness of [FEATURE_ARCHITECTURE], [EXISTING_DEFENSES], and [TOOL_DEFINITIONS]. If any of these are missing or vague, the model will either hallucinate surfaces or produce a low-confidence assessment. After receiving the output, validate it against the [OUTPUT_SCHEMA] using a JSON schema validator, then route it to a human security reviewer. Never auto-approve a launch based solely on this assessment—this prompt is a structured thinking tool, not a replacement for security engineering judgment.

This prompt is designed to operate as a gated step in a feature release pipeline, not as a standalone chatbot query. Before a new feature reaches production, the engineering lead or product security team triggers this assessment. The prompt expects a structured feature specification as input and produces a risk assessment that must pass automated validation before a human reviewer signs off. Treat the output as a security artifact that lives alongside threat models and design reviews in your documentation repository.

Integration pattern: Wrap the prompt in an API call or CI/CD job that supplies [FEATURE_SPEC] from your feature flag system, PRD, or architecture decision record. Set [EXISTING_DEFENSES] from your current defense-in-depth registry (input sanitizers, instruction hierarchy rules, tool authorization policies, output filters, and monitoring rules). The model choice matters here—use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because surface enumeration requires systematic coverage, not just fluency. Validation layer: After receiving the output, run a structured check that verifies: (1) every section in the output schema is populated, (2) each identified surface includes a severity rating and a defense applicability assessment, (3) the coverage_gaps array is non-empty when [EXISTING_DEFENSES] is incomplete, and (4) no surface category from a known checklist (user input, file upload, tool arguments, retrieved documents, rendered outputs, agent handoffs) is missing without explicit justification. If validation fails, retry once with the validation errors appended as [CORRECTION_FEEDBACK]. If the second attempt also fails, escalate to a human reviewer with the partial output and failure reasons attached.

Human review gate: Even when validation passes, the output must route to a security reviewer for approval before the feature gates open. Store the assessment in a versioned artifact store (Git, a security review database, or a GRC tool) with the feature version, model version, prompt version, and reviewer identity recorded. Logging and observability: Capture the full prompt, raw model response, validation results, retry count, and reviewer decision. This audit trail is essential for post-incident review and for demonstrating security review coverage to auditors. What to avoid: Do not treat this prompt as a one-time checklist that ages out. Rerun it when the feature's capabilities expand, when new tools are added, or when the model is upgraded—each of these changes can introduce new injection surfaces that the original assessment missed.