Child Safety Boundary and Reporting Redirection Prompt

This prompt is a production-grade safety control for AI systems that may encounter user requests involving child exploitation, abuse, or grooming. It is designed for platform safety engineers, trust-and-safety teams, and compliance officers who need a single, non-negotiable refusal path that includes mandatory reporting language and victim support resource redirection. Use this prompt as a system-level instruction or as a final routing destination when an upstream classifier detects a high-severity child safety violation. It is not a general content moderation prompt; it is purpose-built for the highest-risk category where legal obligation, platform policy, and ethical duty converge on a single correct response: refuse, report, and redirect to authorized support channels.

Deploy this prompt only when an upstream detection system has already classified the request with high confidence as involving child sexual abuse material (CSAM), child grooming, or the sexual exploitation of minors. The prompt assumes the input has been triaged and escalated to this boundary. Do not use it for ambiguous cases, low-severity policy violations, or general youth safety topics where a less restrictive refusal or educational alternative might be appropriate. The prompt must be placed after the classifier in your routing architecture, never as a first-contact response. It should be the final instruction layer before the model generates a user-visible output, and it must override all other system instructions, role-play personas, or tool-use permissions that could introduce variability into the refusal.

Before implementing this prompt, confirm that your organization has a legally reviewed reporting obligation statement and a designated internal escalation path. The prompt template includes placeholder tokens for these resources, and you must populate them with your actual reporting mechanisms and authorized support channels before deployment. Never deploy this prompt with unresolved placeholders in a production environment. After deployment, log every activation of this prompt for audit purposes, and schedule quarterly reviews to ensure the reporting language and resource links remain current with legal requirements and support service availability. If your platform operates across multiple jurisdictions, maintain jurisdiction-specific variants of the reporting language and route to the correct variant based on user location or applicable law.

This prompt template is designed to be deployed as a system-level instruction in a safety routing workflow. It handles user requests that involve minors, child exploitation content, or related policy violations. The prompt produces a firm, unambiguous refusal that does not engage with the request's substance, while simultaneously providing legally appropriate reporting guidance and victim support resources. It is not a conversational assistant; it is a safety enforcement boundary that must be placed before any general-purpose model instructions in the prompt chain.

textCopy
You are a safety enforcement system. Your only function is to detect and refuse requests involving child exploitation, child sexual abuse material (CSAM), grooming, trafficking of minors, or any content that sexualizes or endangers children. You do not answer, analyze, summarize, translate, or role-play any request that falls within this boundary.

When you detect a violating request, you MUST respond with ONLY the following structured refusal. Do not add, remove, or modify any section.

REFUSAL RESPONSE TEMPLATE:
[REFUSAL_STATEMENT]: I cannot process this request because it appears to involve content or activity that violates child safety policies.

[REPORTING_GUIDANCE]: If you are aware of a child in immediate danger, contact local emergency services. In the United States, reports can be made to the National Center for Missing and Exploited Children (NCMEC) at 1-800-THE-LOST or via CyberTipline at report.cybertip.org. For other jurisdictions, contact your national child protection authority or law enforcement.

[VICTIM_SUPPORT]: If you or someone you know needs support related to child exploitation, the following resources are available: [VICTIM_SUPPORT_ORGANIZATION] at [VICTIM_SUPPORT_CONTACT].

[ESCALATION_NOTE]: This interaction has been flagged for review by our safety team in accordance with our terms of service and applicable reporting obligations.

[POLICY_REFERENCE]: This refusal is based on our prohibition of child exploitation content and activity, as defined in [POLICY_DOCUMENT_NAME].

INPUT TO EVALUATE:
[USER_INPUT]

CONTEXT (if available):
[CONVERSATION_CONTEXT]

To adapt this template for your production environment, replace the bracketed placeholders with your organization's specific resources and policies. [VICTIM_SUPPORT_ORGANIZATION] and [VICTIM_SUPPORT_CONTACT] should point to your vetted support partners. [POLICY_DOCUMENT_NAME] should reference your actual policy document. [CONVERSATION_CONTEXT] is optional but recommended for multi-turn scenarios where prior messages may provide relevant risk signals. The refusal statement itself should remain fixed and not be parameterized per-request, as consistency is critical for both safety enforcement and auditability. Before deploying, validate that all resource links and phone numbers are current and that your legal team has approved the reporting guidance language for the jurisdictions you operate in.

This prompt is a safety-critical component, not a conversational nicety. It must be wired into your application as a hard gate that fires before any general-purpose model response. The implementation harness should intercept user inputs flagged by an upstream classifier or keyword filter, inject the prompt with the required context, and return the refusal response immediately—bypassing any downstream generation, tool calls, or agent loops. There is no scenario where a request involving child exploitation content should proceed to a general model or agent.

Integration pattern: Deploy this prompt behind a dedicated safety endpoint or middleware layer that receives the user's raw input, the risk classification score, and the relevant jurisdictional reporting requirements. The harness should construct the prompt by populating [USER_QUERY], [JURISDICTION], [REPORTING_URL], [HOTLINE_PHONE], and [POLICY_REFERENCE] from your platform's configuration store. After generation, validate the output against a strict schema: the response must contain a refusal statement, the mandatory reporting path, and victim support resources. Use a secondary LLM judge or regex-based validator to confirm all three components are present and that no substantive engagement with the unsafe request occurred. If validation fails, fall back to a hardcoded static refusal message—never retry with the original prompt.

Logging and audit requirements: Every invocation must be logged immutably with the user ID, session ID, timestamp, risk classification, prompt version, model response, and validation result. These logs are legal evidence. Do not log the raw user query in plaintext if it contains CSAM descriptors—hash or tokenize it at the edge before storage. Route all validated refusals to your trust-and-safety review queue for human confirmation within your defined SLA. If the upstream classifier confidence is below your production threshold, route to human review before generating any response. Model choice: Use a model with strong instruction-following and low refusal-bypass rates. Test against adversarial prompt sets before deployment. Never use a fine-tuned model that might have memorized harmful content from training data.