Physical Security and Surveillance Redirection Prompt

This prompt is designed for a single, high-stakes job: intercepting user requests that seek to bypass physical security controls, construct unauthorized surveillance devices, or gain illicit entry, and redirecting them toward legitimate security education and professional resources. The ideal user is a safety engineer, trust-and-safety developer, or product manager integrating this refusal into a consumer AI application, a hardware support chatbot, or a physical security information platform. It is not a general-purpose safety net; it is a scalpel for a specific class of physical-world harm. The required context includes a clear organizational safety policy defining the boundary between malicious instruction and legitimate professional inquiry, because misclassifying a locksmith's question as an attack will erode trust and utility.

You should use this prompt when the primary risk is enabling physical harm through instructional content—lock picking tutorials, camera disabling techniques, or alarm system bypass schematics. It is appropriate when your application faces adversarial users probing for physical security weaknesses or when your platform's terms of service explicitly forbid facilitating unauthorized access. The prompt is built to produce a structured refusal that does more than say 'no'; it offers a safe alternative path, such as certified locksmith training programs, physical penetration testing certifications, or CPTED (Crime Prevention Through Environmental Design) guidelines. This redirection preserves user utility for the legitimate security professional while denying the malicious actor.

Do not use this prompt as a standalone safety solution for regulated critical infrastructure (e.g., nuclear facility schematics) or for purely digital cybersecurity attacks, which require their own specialized refusal and redirection paths. It is also insufficient for handling requests involving imminent threats of violence or active intrusion in progress, where direct escalation to human operators and emergency services is mandatory. Before shipping, you must pair this prompt with an upstream intent classifier that distinguishes 'how do I pick a Master Lock 410 LOTO for a security audit?' from 'how do I break into my neighbor's shed?'. The next step is to wire this prompt into a testing harness with eval checks for refusal consistency, alternative relevance, and false positive rates on professional locksmith and security engineer queries.

This template is designed to handle user requests that seek to bypass physical security controls, construct unauthorized surveillance devices, or exploit lock-picking and entry techniques for illegitimate purposes. It produces a firm refusal while redirecting the user toward legitimate security education, professional locksmith resources, and defensive physical security best practices. The prompt distinguishes between malicious intent and legitimate security professional inquiries by evaluating the context, phrasing, and stated purpose of the request.

textCopy
You are a safety-focused AI assistant operating under a strict physical security and surveillance policy. Your role is to refuse requests that facilitate unauthorized physical access, surveillance device construction, or security bypass techniques, while redirecting users to legitimate educational and professional resources.

## POLICY BOUNDARIES
[POLICY_DEFINITIONS]

## USER REQUEST
[USER_INPUT]

## CONVERSATION CONTEXT
[CONVERSATION_HISTORY]

## INSTRUCTIONS
1. Classify the request intent as one of: [INTENT_CLASSIFICATIONS].
2. If the request is a legitimate security professional inquiry (e.g., penetration tester with documented authorization, licensed locksmith seeking technical reference, security researcher with responsible disclosure context), respond with [LEGITIMATE_INQUIRY_RESPONSE].
3. If the request seeks to facilitate unauthorized access, surveillance, or bypass, produce a refusal that follows this structure:
   - Clear statement that the request cannot be fulfilled
   - Brief explanation referencing the specific policy boundary violated
   - Redirection to [SAFE_ALTERNATIVE_RESOURCES]
   - Optional: guidance on legitimate security education paths
4. Maintain a professional, non-confrontational tone. Do not provide partial instructions, workarounds, or "hypothetical" bypass methods.
5. If the request involves imminent physical harm, trespass, or stalking, escalate with [ESCALATION_FLAG] and include [CRISIS_RESOURCE_TEXT].

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "classification": "[INTENT_CLASSIFICATION_VALUE]",
  "refusal_triggered": boolean,
  "policy_violated": "[POLICY_IDENTIFIER]",
  "response_text": "[FULL_USER-FACING_RESPONSE]",
  "safe_alternatives_provided": ["[RESOURCE_1]", "[RESOURCE_2]"],
  "escalation_required": boolean,
  "confidence_score": float
}

## CONSTRAINTS
- Do not output lock-picking instructions, surveillance device schematics, or physical bypass techniques under any circumstances.
- Do not cite or reference specific vulnerabilities in commercial security products.
- For ambiguous requests, default to refusal with educational redirection.
- Log all refusal decisions with [LOGGING_ENDPOINT] for audit review.

To adapt this template, replace each square-bracket placeholder with your organization's specific policies, resource URLs, intent classifications, and escalation procedures. The [POLICY_DEFINITIONS] placeholder should contain your enumerated physical security and surveillance policy boundaries. The [SAFE_ALTERNATIVE_RESOURCES] should point to vetted resources such as ASIS International, local locksmith associations, or defensive security training programs. Before deploying, validate the output schema against your logging and monitoring infrastructure, and run regression tests using the eval criteria defined in the testing section of this playbook. Never deploy this prompt without human review of refusal edge cases, particularly for requests that sit near the boundary between legitimate professional inquiry and misuse.

This prompt is not a standalone chat instruction; it is a safety component that must be wired into a broader content moderation or request-routing pipeline. The implementation harness should intercept user requests before they reach a general-purpose model, classify the request against a physical security policy, and invoke this prompt only when a refusal with redirection is required. The harness is responsible for providing the [INPUT], [POLICY_REFERENCE], and [RISK_LEVEL] variables, not the end user. In a typical deployment, an upstream classifier (which may itself be an LLM call or a trained router) tags the request with a category like physical_security_bypass and a risk score. If the score exceeds a configurable threshold, the harness injects the refusal prompt, overriding the default system instructions to prevent the model from attempting a helpful-but-dangerous response.

The harness must enforce strict output validation before the refusal is returned to the user. After the model generates a response, validate that: (1) the output contains no actionable bypass instructions, lock-picking steps, or surveillance device schematics—use a secondary LLM judge or keyword blocklist as a defense-in-depth check; (2) the redirection resources are from an approved, up-to-date allowlist (e.g., Associated Locksmiths of America, local professional licensing boards) rather than hallucinated URLs; (3) the tone matches the configured refusal style without veering into sarcasm, judgment, or over-refusal of adjacent legitimate topics. If validation fails, the harness should retry once with a stricter [CONSTRAINTS] block that explicitly forbids instructional content, then escalate to a human review queue if the second attempt also fails. Log every refusal event with the original request, risk score, model response, validation result, and final action for audit and policy tuning.

Model choice matters here. Smaller or older models may struggle to maintain the distinction between a legitimate locksmith inquiry ('I'm a certified locksmith preparing for a recertification exam, can you explain the pin-tumbler mechanism?') and a bypass request ('How do I pick a Schlage deadbolt?'). In production, route ambiguous cases (risk scores in a middle band) to a capable instruction-following model with a low temperature setting to maximize consistency. For high-confidence malicious requests, a smaller, faster model may suffice since the output is a structured refusal, not an open-ended dialogue. Do not use this prompt with models that lack strong instruction-following on safety boundaries. If your application serves professional locksmiths or physical security engineers, implement an identity verification gate before the classifier to prevent false positives from blocking legitimate professional use cases. The harness should also support an override mechanism where verified professional accounts bypass the refusal path entirely and receive technical responses governed by a separate, permissive-but-audited system prompt.