Continuous Monitoring Rule Generation for Injection Surfaces Prompt

This prompt is designed for security operations teams who have completed an injection surface enumeration and need to operationalize those findings. The primary job-to-be-done is translating a static architecture review—including defined trust boundaries, input channels, and known attack vectors—into concrete monitoring rules that can detect injection attempts, extraction events, and defense bypasses in production. The ideal user is a detection engineer or security architect who already has a structured surface inventory and needs to close the gap between design-time analysis and runtime defense.

Use this prompt when you have a defined list of injection surfaces with their associated trust boundaries and attack vectors. The prompt expects structured input describing each surface, the data or instructions that cross it, and the specific injection techniques that apply. It produces monitoring rules with detection logic, log sources, severity assignments, and false-positive considerations. Do not use this prompt if you have not yet mapped your injection surfaces; start with the AI System Injection Surface Enumeration Prompt Template instead. This prompt is also inappropriate for generating architectural diagrams, conducting initial risk assessments, or creating red-team test cases—those are separate workflows with their own dedicated prompts.

Before running this prompt, validate that your surface enumeration includes: (1) a unique identifier for each surface, (2) the trust boundary it crosses, (3) the direction of data flow, (4) the specific injection techniques relevant to that surface, and (5) the component or service that processes the input. Incomplete surface descriptions will produce rules with coverage gaps. After generating rules, you must test them against known attack samples and benign traffic to calibrate false-positive rates. For high-severity rules affecting production alerting pipelines, require human review before deployment. The output should feed directly into your SIEM rule engine, log analysis pipeline, or AI gateway policy configuration, not remain as a document.

This prompt template is designed for security operations teams who need to convert a static inventory of injection surfaces into active, testable monitoring rules. It takes a structured definition of the system's attack surface, relevant telemetry sources, and output format requirements, and produces a set of detection rules ready for SIEM or runtime monitoring integration. The template forces explicit consideration of false-positive tolerance and detection coverage, which are the two dimensions where hand-written rules most often fail in production.

codeCopy
You are an AI security detection engineer. Your task is to generate runtime monitoring rules that detect injection attempts, extraction events, and defense bypasses targeting the defined injection surfaces.

## INPUT SURFACES
[INJECTION_SURFACES]

## AVAILABLE TELEMETRY
[TELEMETRY_SOURCES]

## OUTPUT SCHEMA
Generate a JSON array of detection rules. Each rule object must include:
- rule_id: unique string identifier
- rule_name: short descriptive name
- surface: which injection surface this rule monitors (from INPUT SURFACES)
- severity: "critical" | "high" | "medium" | "low"
- description: what the rule detects and why it matters
- detection_logic: natural language description of the detection condition
- telemetry_required: array of telemetry sources this rule consumes
- false_positive_notes: expected false positive scenarios and estimated rate
- test_case: a concrete example of an attack this rule would catch
- bypass_blind_spot: a known technique this rule would miss

## CONSTRAINTS
- Maximum [MAX_RULES] rules total
- Each surface must have at least [MIN_RULES_PER_SURFACE] rules
- False positive rate target: below [FP_RATE_TARGET] per rule
- Prioritize detection coverage for [PRIORITY_SURFACES] surfaces
- Rules must only use telemetry sources listed in AVAILABLE TELEMETRY
- Include at least one rule for each of: injection attempt, extraction event, defense bypass

## EVALUATION CRITERIA
After generating rules, self-assess:
1. What percentage of INPUT SURFACES have at least one rule?
2. What is the estimated aggregate false positive rate across all rules?
3. Which attack technique from [KNOWN_ATTACK_PATTERNS] has no coverage?
4. Are any rules dependent on telemetry not listed in AVAILABLE TELEMETRY?

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Generate the detection rules now.

To adapt this template for your environment, replace each square-bracket placeholder with concrete data from your attack surface review. The [INJECTION_SURFACES] placeholder should contain the structured output from an enumeration exercise—each surface defined with its input channel, trust boundary, and example attack vectors. The [TELEMETRY_SOURCES] block must be exhaustive and honest; listing telemetry you wish you had rather than what you actually collect will produce rules that silently fail in production. The [FEW_SHOT_EXAMPLES] block is critical for output quality: include at least two examples showing the desired rule structure, one with a high-severity injection detection and one with a lower-severity extraction detection, to calibrate the model's severity judgment. Before deploying any generated rule, run it against a labeled dataset containing both known attacks and benign traffic to validate the false-positive estimate. For high-risk surfaces where a missed detection has regulatory or business-critical impact, route generated rules through a human reviewer before activation.

This prompt is designed to be a scheduled, automated component within a Security Operations Center (SOC) or Detection Engineering pipeline, not a one-off analyst tool. The primary integration point is a rule generation service that runs on a defined cadence (e.g., daily, weekly) or is triggered by a change event, such as a new attack surface being cataloged or a new threat intelligence report being ingested. The service's job is to fetch the current inventory of injection surfaces from a source of truth (like a SIEM asset model or a custom CMDB), format them as the [INJECTION_SURFACE_INVENTORY] input, and invoke the LLM to produce candidate detection rules. The output is not deployed directly; it is pushed to a staging repository for human review and automated testing.

The implementation harness must enforce a strict validate-before-review contract. The raw LLM output must be parsed and validated against the [OUTPUT_SCHEMA] (a JSON array of rule objects). A validation script should check for: (1) structural integrity (all required fields like rule_name, detection_logic, severity are present and of the correct type), (2) logical consistency (the detection_logic can be parsed into a valid SIEM query, such as a Splunk SPL or Elastic KQL query), and (3) completeness (every surface in the input inventory has at least one corresponding rule). Outputs that fail structural validation should trigger a retry loop with a more explicit error message fed back into the [CONSTRAINTS] field, up to a maximum of two retries. Outputs that fail logical parsing should be flagged for human review with a specific error annotation. This ensures that a syntactically broken rule never reaches a reviewer without a clear warning.

For high-fidelity production use, the harness should include a false-positive (FP) estimation step. Before a rule is presented for human approval, the harness should execute a dry-run of the detection_logic against a historical log dataset (e.g., the last 7 days of logs) in a data lake or SIEM. The number of events that would have triggered the rule is attached to the rule as an estimated_weekly_volume field. This transforms the human review step from a subjective judgment into a data-informed decision. A reviewer can immediately see if a rule for a critical surface would generate 10,000 alerts a week and request tuning. The final step is a human-in-the-loop approval gate: a pull request is created in a Git repository containing the new or updated detection rules, and a detection engineer must merge it for the rule to be deployed to the production SIEM. This workflow ensures that the AI accelerates rule creation without sacrificing the operational safety and accountability required in security monitoring.