Domain Boundary Rejection System Prompt

This playbook is for product engineers embedding a system-level instruction that defines the boundaries of an AI assistant's capabilities. Use this prompt when you need the model to recognize and gracefully reject requests outside its supported domains instead of hallucinating an answer. This is a foundational guardrail for any production AI system where the model must honestly communicate its limitations. It belongs in the system prompt layer, before any user or tool messages, and should be one of the first instructions the model processes.

The ideal user is a product engineer or AI platform builder deploying a customer-facing assistant, internal copilot, or API-integrated agent. You need this prompt when your system has a defined scope—such as a support bot that only handles billing and account issues, or a coding agent limited to a specific language and framework. The prompt works by enumerating supported capabilities and instructing the model to decline anything outside that set. It is not a safety filter, a policy enforcer, or a risk classifier. Do not use this prompt to detect abuse, block prohibited content, or assess regulatory compliance. Those concerns require dedicated classification prompts with structured verdicts, confidence scores, and audit trails. Pair this prompt with a separate safety boundary classifier and a policy violation detector for a complete ingress guardrail.

Before implementing this prompt, define your system's capability taxonomy. Write down every supported domain, action type, and output format. Then write the inverse: what the system explicitly does not do. Vague boundaries produce inconsistent rejections. Test the prompt with adversarial inputs that probe the edges—requests that sound close to a supported domain but fall just outside it. Monitor production logs for refusal tone drift, where the model becomes overly apologetic, defensive, or falsely modest about real capabilities. The next step after deploying this prompt is to build eval checks that measure refusal accuracy, hallucination rate on out-of-scope queries, and tone consistency across rejection responses.

This system prompt establishes a strict domain boundary for your AI application. It defines exactly what the system can and cannot do, then instructs the model to reject out-of-scope requests with a structured refusal that explains the limitation, states what the system can help with, and avoids hallucinating capabilities. Use this when you need a single, enforceable contract that prevents the model from attempting tasks outside its designed scope—whether that's medical advice, code execution, financial recommendations, or any other unsupported domain.

textCopy
You are an AI assistant with a strictly defined scope of capabilities. Your supported domains are:

[SUPPORTED_DOMAINS]

You are explicitly NOT capable of:

[UNSUPPORTED_DOMAINS]

When a user request falls entirely within your supported domains, respond helpfully and accurately.

When a user request falls outside your supported domains—even partially—you MUST refuse gracefully. Do not attempt the task. Do not hallucinate capabilities. Do not provide partial workarounds that imply capability you lack.

Your refusal must follow this structure:

1. **Acknowledge the request** briefly so the user feels heard.
2. **State clearly that the request is outside your supported scope**, referencing the specific domain boundary.
3. **List what you CAN help with** from your supported domains, offering a constructive path forward.
4. **If applicable, suggest an alternative resource** (e.g., "You may want to consult a qualified professional" or "Our [OTHER_PRODUCT] handles that use case").

Tone requirements:
- Be polite and helpful, never dismissive or apologetic.
- Do not over-explain why you cannot help.
- Do not speculate about future capabilities.
- Do not say "I'm just an AI" or similar self-deprecating language.

Examples of correct refusals:

[REFUSAL_EXAMPLES]

Examples of incorrect responses that you must avoid:

[INCORRECT_EXAMPLES]

Adaptation guidance: Replace [SUPPORTED_DOMAINS] with a bulleted or numbered list of your system's actual capabilities—be specific (e.g., "Answering questions about product pricing and features using the knowledge base" rather than "Customer support"). Replace [UNSUPPORTED_DOMAINS] with explicit boundaries (e.g., "Providing medical diagnoses," "Executing code," "Giving financial advice"). Provide 2-3 [REFUSAL_EXAMPLES] that demonstrate the refusal structure for common out-of-scope requests in your domain. Include 1-2 [INCORRECT_EXAMPLES] showing common failure modes like partial compliance, capability hallucination, or overly apologetic refusals. Test this prompt against edge cases where a request partially overlaps supported domains—the model should refuse if any material part of the request is out of scope. For production, pair this with eval checks that verify refusal structure compliance, tone consistency, and zero hallucination on unsupported queries.

The Domain Boundary Rejection System Prompt is not a standalone prompt—it is a system-level instruction that runs before any user input reaches the main conversation or agent loop. In a production harness, this prompt should be injected as the first system message in every request, ahead of role instructions, tool definitions, and conversation history. The goal is to create a hard boundary that the model cannot override through user persuasion, few-shot examples, or tool-call side effects. Because system prompts are not security boundaries against determined prompt injection, this harness must also include application-layer validation that checks the model's output for refusal signals before passing it downstream.

Wire the prompt into your application by constructing the message array with this system prompt in position zero, followed by any domain-specific system instructions, then the user message. After the model responds, run a lightweight post-processing validator that checks for a structured refusal marker—such as a REJECTION block with domain and reason fields—or a natural-language refusal pattern. If the validator detects a rejection, route the response to your out-of-scope handler (which might return a user-facing message, log the attempt, or escalate for review). If no rejection is detected, pass the output to the next stage. For high-throughput systems, consider using a smaller, faster classifier model to pre-filter obvious out-of-scope requests before invoking the main model, reducing latency and cost on requests that will be rejected anyway. Model choice matters: instruction-tuned models (GPT-4, Claude 3.5, Gemini 1.5 Pro) follow system-level boundary instructions more reliably than base models. Always test boundary adherence on your specific model version—behavior can shift across releases.

Validation and retries: implement a structured output check that looks for the expected refusal format. If the model produces a refusal but in the wrong format, do not retry—log the malformed refusal and treat it as a rejection. If the model fails to reject an out-of-scope request (a false negative), this is a critical failure that must trigger an alert. Build an eval suite with at least 50 out-of-scope examples spanning edge cases: near-boundary requests, requests that use domain terminology without being in-scope, and adversarial attempts to reframe out-of-scope tasks as in-scope ones. Run these evals on every prompt or model change. Logging: capture the full prompt, the model's response, the rejection detection result, and the downstream routing decision. This audit trail is essential for debugging false rejections (where the model refuses a legitimate in-scope request) and for demonstrating boundary enforcement to compliance reviewers. For regulated domains, ensure logs include the user ID, timestamp, and the specific domain boundary that was triggered.

Human review integration: for high-risk domains (healthcare, legal, finance), out-of-scope rejections should not silently fail. Route rejected requests to a review queue where a human can confirm the rejection was correct and decide whether the system's domain boundaries need updating. This feedback loop prevents the boundary from becoming stale as user needs evolve. What to avoid: do not rely solely on the system prompt for boundary enforcement in adversarial contexts. Prompt injection attacks can override system instructions. Always pair this prompt with application-layer guards: input filtering, output validation, and rate limiting on rejection attempts. Do not use this prompt as a substitute for proper authentication and authorization—domain boundaries are about capability scope, not access control. Finally, avoid making the domain description so narrow that legitimate requests are rejected, or so broad that the boundary becomes meaningless. Test with real user data before deploying.