Security Research Intent Verification Prompt Template

This prompt is designed for platform security teams who need to programmatically distinguish between legitimate security research queries and malicious exploitation attempts. The core job-to-be-done is intent classification: given a user request that involves vulnerability discussion, exploit code, or penetration testing tools, the prompt must produce a structured verdict with evidence markers and a recommended action. The ideal user is a security engineer or trust-and-safety operator integrating this prompt into a triage pipeline, an automated moderation system, or a researcher-facing API gateway.

Use this prompt when the cost of blocking a genuine researcher is high—for example, on bug bounty platforms, security tooling APIs, or academic collaboration portals. The prompt is calibrated to reduce false positives on queries that superficially resemble attacks, such as CVE discussions, proof-of-concept explanations, CTF walkthroughs, and pentest report documentation. It is not suitable for real-time attack prevention systems where latency constraints demand deterministic rule-based blocking, nor for environments where any exploit-adjacent content must be refused without exception. The prompt requires the model to reason over code context, user history (if available), and query framing before classifying intent.

Before deploying this prompt, ensure you have defined your organization's policy on what constitutes acceptable security research. The prompt's [POLICY] placeholder must be populated with concrete, enforceable criteria—vague policies produce inconsistent classifications. Pair this prompt with a human review queue for high-confidence malicious classifications and an eval harness that measures false positive rates on your specific benign research traffic. Do not use this prompt as a standalone safety guarantee; it is one component in a defense-in-depth strategy that should include rate limiting, authentication, and out-of-band verification for high-severity exploit attempts.

This template is designed to be copied directly into your prompt library or orchestration layer. It forces the model to distinguish between legitimate security research (CVE discussion, pentest report queries, CTF walkthroughs) and malicious exploitation requests (exploit generation, unauthorized access instruction). The square-bracket placeholders let you inject your organization's specific policy, risk tolerance, and output format without rewriting the core logic.

textCopy
You are a security research intent classifier for [PLATFORM_NAME]. Your job is to evaluate whether a user request represents legitimate security research or malicious exploitation.

## Classification Rules
- Legitimate research includes: vulnerability discussion, CVE analysis, pentest methodology, CTF writeups, security tool documentation, academic paper queries, and defensive technique explanation.
- Malicious exploitation includes: generating exploit code for active attacks, instructions for unauthorized access, bypassing authentication without authorization, and operational attack guidance.
- When intent is ambiguous, apply the [RISK_TOLERANCE] standard: [RISK_TOLERANCE_DESCRIPTION].

## Input
User request: [USER_REQUEST]

Context (if available): [CONTEXT]

## Output Format
Return a JSON object with this exact schema:
{
  "classification": "legitimate_research" | "malicious_exploitation" | "ambiguous",
  "confidence": 0.0-1.0,
  "evidence_markers": ["string"],
  "recommended_action": "allow" | "block" | "escalate" | "request_clarification",
  "reasoning": "string"
}

## Evidence Markers
- Cite specific phrases, technical indicators, or contextual signals that support your classification.
- For legitimate research, note indicators like: CVE references, academic framing, defensive context, authorized testing language.
- For malicious exploitation, note indicators like: target specification, authorization absence, operational instruction requests.

## Escalation Triggers
Escalate to human review when:
- Confidence is below [CONFIDENCE_THRESHOLD]
- The request involves [ESCALATION_DOMAINS]
- The user has a history of [PRIOR_BEHAVIOR_PATTERNS]

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

Adapt this template by replacing each placeholder with your organization's specific values. [PLATFORM_NAME] should identify your product or team context. [RISK_TOLERANCE] and [RISK_TOLERANCE_DESCRIPTION] define your bias toward permissiveness or restriction—for example, a security training platform might set this to 'permissive' while a cloud provider might use 'restrictive.' [CONFIDENCE_THRESHOLD] gates when outputs require human review; start at 0.85 and adjust based on your false positive tolerance. [ESCALATION_DOMAINS] should list high-risk areas like zero-day exploitation, critical infrastructure, or nation-state actor techniques. [CONSTRAINTS] can include jurisdiction-specific requirements, data handling rules, or output formatting restrictions. [EXAMPLES] should contain 3-5 few-shot demonstrations covering both legitimate and malicious cases from your actual traffic patterns. After adapting, run the prompt through your eval suite using the test cases described in the Testing and Eval Criteria section before any production deployment.

This prompt is designed to sit behind a security review API or an internal triage queue, not as a standalone chatbot. The primary integration point is a classification endpoint that receives a user query, enriches it with session context and user role metadata, calls the LLM with this prompt template, and then acts on the structured output. Because the domain involves potential exploitation attempts, the harness must treat every classification as a security-relevant event with appropriate logging, evidence preservation, and human review triggers.

Input assembly should combine the raw user query with available context before populating the prompt placeholders. At minimum, include: [USER_QUERY] (the exact text), [USER_ROLE] (e.g., authenticated_researcher, anonymous, enterprise_security_team), [SESSION_HISTORY] (last N turns if multi-turn), and [PLATFORM_CONTEXT] (e.g., vulnerability_disclosure_portal, developer_forum, security_tool_documentation). If your system has a verified researcher badge or prior submission history, include that in [USER_CREDENTIALS]. The [POLICY_BOUNDARIES] placeholder should reference your organization's specific acceptable use policy sections on security research, exploit sharing, and proof-of-concept code. Model choice matters: use a model with strong instruction-following and low refusal volatility for classification tasks. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable; avoid models known for brittle safety refusals on security-adjacent topics unless you've calibrated them specifically.

Output validation is critical. The prompt requests a JSON structure with intent_classification, evidence_markers, confidence_score, and recommended_action. Your harness must validate that the response is parseable JSON, that intent_classification is one of the expected enum values (e.g., legitimate_research, malicious_exploitation, ambiguous, policy_violation), that confidence_score is a float between 0 and 1, and that evidence_markers contains at least one specific reference to the input text. If validation fails, retry once with a repair prompt that includes the validation error. If the retry also fails, escalate to a human reviewer with the raw query and partial output preserved. Log everything: the full prompt, the model response, the validation result, the action taken, and the reviewer decision if escalated. These logs are your audit trail for false positive/negative analysis and policy refinement.

Action routing based on recommended_action should be implemented as a decision matrix in application code, not left to the model alone. Map allow to normal processing, allow_with_caveats to a response that includes a safety preamble, flag_for_review to a human queue with a 24-hour SLA, block to a refusal response with an explanation and appeal path, and escalate_to_security_team to an immediate pager notification. For ambiguous classifications with confidence below 0.7, default to flag_for_review. Rate limiting is essential: if a single user or IP triggers multiple malicious_exploitation or policy_violation classifications within a short window, automatically escalate the session and consider temporary suspension pending review. Do not rely on the prompt alone to enforce rate limits; implement these in the application layer.

Testing and calibration should happen before production deployment. Run the provided test cases (CVE discussion, exploit PoC requests, pentesting tool documentation queries) through the full harness and measure false positive and false negative rates against human-labeled ground truth. Pay special attention to queries that mix legitimate research language with exploitation-adjacent requests—these are your highest-risk misclassification points. After deployment, implement a feedback loop: allow human reviewers to correct classifications, and use those corrections to tune your [POLICY_BOUNDARIES] text and confidence thresholds. Schedule a monthly review of escalated cases to identify patterns that require prompt updates or policy changes. Never silently update the prompt without running the regression test suite against the new version.