Production Safety Policy Amplification Prompt

This prompt is for reliability engineers and AI platform architects who need to harden an existing assistant's behavior when it moves from staging to production. The core job is to take a base system prompt that works in a lower-risk environment and amplify its safety policies—raising refusal thresholds, requiring explicit confirmation for high-risk actions, and enforcing stricter output validation—without rewriting the entire instruction set. The ideal user already has a functional staging prompt and needs a repeatable, testable method to generate a production-grade variant that reduces the blast radius of model errors, tool misuse, or policy bypass in a live user-facing or revenue-critical system.

Use this prompt when the cost of a policy violation in production is materially higher than in staging. Concrete triggers include: the assistant gains access to production databases, payment APIs, or customer PII; the assistant can perform destructive actions (delete, write, send); the assistant serves external users instead of internal testers; or a compliance review requires demonstrable policy amplification before launch. The prompt expects a base system instruction block, a list of high-risk actions, and the target production risk level as inputs. It produces a modified system prompt with amplified guardrails, plus a set of eval scenarios you can use to verify that the production variant is measurably stricter than the staging baseline.

Do not use this prompt as a substitute for application-layer authorization, tool-level access control, or human approval workflows. It amplifies policy in the prompt layer only—it cannot prevent a determined prompt injection attack from bypassing instructions if the model is sufficiently compromised. Do not use it on a base prompt that is already unstable or poorly defined; amplification magnifies existing ambiguity. After generating the production variant, you must run policy strength comparison evals against the staging prompt, test for over-refusal that breaks core product functionality, and implement runtime monitoring that detects when the amplified policies are violated in production logs. If the workflow involves regulated data or life-safety decisions, pair this prompt with a mandatory human-in-the-loop review step that no prompt-layer policy can override.

This template is designed to be injected as a prefix to your existing system instructions when deploying an assistant to production. It acts as a policy amplifier, overriding or tightening behavioral rules that may have been relaxed for development or staging environments. The core mechanism is a set of layered constraints that raise the bar for autonomous action, explicitly define high-risk categories, and mandate a confirmation step before execution. Use this when the cost of an error in production—whether reputational, financial, or related to data integrity—is significantly higher than in pre-production environments.

markdownCopy
# PRODUCTION SAFETY POLICY AMPLIFICATION

## OVERRIDE PRIORITY
These rules override any conflicting instructions in the base system prompt or user request. In case of ambiguity, the safest interpretation must be chosen.

## AMPLIFIED REFUSAL THRESHOLD
You are operating in a PRODUCTION environment. Your default refusal threshold is now HIGH. You must refuse any request that has a non-trivial risk of causing data loss, financial impact, service disruption, or policy violation, even if a base instruction suggests you can proceed. When refusing, state the specific production safety rule that prevents the action.

## HIGH-RISK ACTION CONFIRMATION
Before executing any action in the following categories, you MUST request explicit user confirmation and wait for an affirmative response:
- [HIGH_RISK_CATEGORIES]
- Destructive operations (delete, overwrite, purge)
- Configuration changes to production systems
- Any action involving personally identifiable information (PII)
- Sending communications to external users

Your confirmation request must summarize the action, its specific target, and the potential impact.

## STRICT OUTPUT VALIDATION
Before presenting any final output, you must internally validate it against these rules:
- [OUTPUT_VALIDATION_RULES]
- No internal hostnames, IP addresses, or secrets may be present.
- All factual claims must be traceable to provided [CONTEXT] or marked as [UNCERTAIN].
- If the output includes code or configuration, it must be read-only or require a manual apply step.

## TOOL USE CONSTRAINTS
- [TOOL_CONSTRAINTS]
- You are prohibited from calling any tool tagged as `staging-only` or `development-only`.
- The maximum rate for API calls is [PRODUCTION_RATE_LIMIT].
- All tool call arguments must be logged for audit purposes.

## ENVIRONMENT CONTEXT
- Current Deployment: PRODUCTION
- Risk Level: [RISK_LEVEL]
- Active Feature Flags: [FEATURE_FLAGS]

To adapt this template, replace the square-bracket placeholders with your specific policies. [HIGH_RISK_CATEGORIES] should be a bulleted list of domain-specific actions (e.g., 'Initiating a financial transaction over $1000'). [OUTPUT_VALIDATION_RULES] can include custom regex patterns or forbidden terms. The key to making this work is ensuring the OVERRIDE PRIORITY clause is placed at the very top of your final assembled system prompt, giving it precedence over all other instructions. After adapting, test this prompt against a golden dataset of safe and unsafe requests to verify that the refusal rate increases appropriately without causing false positives on benign tasks.

The Production Safety Policy Amplification Prompt is not a standalone artifact; it is a policy transformation layer that sits between your base staging system prompt and the final production system message. The implementation harness must take a staging-validated system prompt, apply the amplification template, and produce a hardened production variant. This should happen at deploy time, not at runtime, to avoid injecting variability into production behavior. The harness should be a deterministic function: production_prompt = amplify(staging_prompt, environment='production', risk_threshold='high'). Any failure in amplification must block the deployment, not silently fall back to the weaker staging prompt.

The harness must enforce several structural checks before the amplified prompt reaches production. First, validate that the output contains explicit refusal amplification—look for phrases that raise the bar for high-risk actions, such as requiring explicit user confirmation, listing prohibited action categories, or adding mandatory validation steps. Second, confirm that tool authorization gates are present and stricter than staging equivalents. Third, run a differential eval: compare the staging and production prompts against a shared test suite of adversarial inputs and confirm that the production variant refuses or escalates more often on high-risk cases without breaking legitimate low-risk workflows. A practical implementation might use a CI/CD step that calls the amplification prompt, stores the output as a versioned artifact, runs the eval suite, and gates the release on a minimum safety score delta.

Logging and observability are critical. Every deployment of an amplified prompt must record the base staging prompt version, the amplification template version, the generated production prompt, and the eval results. At runtime, log which prompt version served each request so that incident responders can trace unexpected refusals or policy gaps back to a specific amplification run. Avoid runtime prompt assembly for production safety policies—pre-compute the hardened prompt and serve it as a static system message. If your platform supports dynamic tenant-specific overrides, inject those after amplification but before the final validation gate, and re-run the safety eval suite with tenant context included. The most common failure mode is amplification drift: as the base staging prompt evolves, the amplification template may produce unintended behavior. Mitigate this by running the amplification and eval pipeline on every staging prompt change, not just on scheduled release cycles.