Refusal Recovery with Explicit Permission Prompt

This prompt is designed for enterprise AI systems that must enforce safety and policy boundaries but cannot afford to permanently block legitimate work. The core job-to-be-done is recovering from a refusal by offering the user a structured, auditable path to grant explicit permission to proceed. The ideal user is a product manager or safety engineer integrating this into a customer-facing application where certain actions—such as accessing sensitive data, executing high-cost operations, or generating content in a regulated category—require a documented opt-in. The required context includes the original refused request, the specific policy that triggered the refusal, and a clear, bounded scope of what the user is permitting.

Do not use this prompt when the refusal is based on a hard safety boundary that should never be crossed, such as generating illegal content or enabling harm. It is also inappropriate for ambiguous policy violations where the system itself is uncertain about the rule; in those cases, use an escalation or policy-boundary clarification prompt instead. This prompt assumes the system has correctly identified a violative request but has determined that an explicit user permission path is appropriate and safe. It is not a replacement for human-in-the-loop review in high-stakes domains like healthcare or finance, where an additional approval step should be wired into the harness before the permission is considered valid.

Before implementing this prompt, ensure your application has a durable consent storage mechanism and a revocation path. The permission generated here is a record, not just a text response. The prompt's value is in producing a clear, scoped, and auditable permission request that a user can explicitly accept or reject. If your system cannot enforce scope limitations or track consent over time, the prompt alone will create a compliance gap. Wire this into a state machine where the user's explicit 'yes' is captured, logged, and respected for the defined scope and duration only.

This template is designed for enterprise systems where a model has refused a user request due to a safety or policy boundary, but the system allows the user to grant explicit, auditable permission to proceed. The prompt instructs the model to generate a clear permission request that discloses the scope of the action, the associated risks, and the terms of consent, rather than simply re-refusing or silently proceeding. Use this when the initial refusal is triggered by a policy that permits user-directed overrides, such as accessing sensitive internal data or performing a high-impact action.

codeCopy
You are an AI assistant in an enterprise system with a defined safety policy. You previously refused a user request because it triggered a policy boundary. However, the system permits the user to grant explicit, auditable permission to proceed for certain actions.

Your task is to generate a permission request for the user. Do not re-refuse the request. Do not proceed without permission. Your output must be a structured request that the user can explicitly approve or deny.

# ORIGINAL USER REQUEST
[USER_REQUEST]

# REFUSAL REASON
[REFUSAL_REASON]

# APPLICABLE POLICY
[POLICY_REFERENCE]

# PERMISSION SCOPE
Define exactly what action will be taken if permission is granted. Be specific about data access, operations, and side effects.

# RISK DISCLOSURE
Explain the potential risks of proceeding, including data exposure, system impact, or policy implications. Be factual and avoid alarmist language.

# CONSENT TERMS
State that permission is for this single request only, is logged for audit, and can be revoked. Include a clear statement that the user must confirm they have the authority to grant this permission.

# OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "permission_request": {
    "summary": "One-sentence summary of what permission is being requested",
    "scope": "Detailed description of the action to be taken",
    "risks": ["Risk 1", "Risk 2"],
    "consent_terms": {
      "single_use": true,
      "audit_logged": true,
      "revocable": true,
      "authority_confirmation_required": true
    },
    "approval_prompt": "Clear question for the user to approve or deny, e.g., 'Do you grant permission to proceed with [action]?'",
    "denial_action": "What will happen if the user denies permission"
  }
}

# CONSTRAINTS
- Do not fabricate risks that don't apply.
- Do not pressure the user to approve.
- If the original request cannot be safely scoped for permission, set "scope" to null and explain why in "denial_action".
- Maintain the same safety boundaries for any future requests; this permission does not weaken policy.

To adapt this template, replace the placeholders with your system's specific context. [USER_REQUEST] should contain the full original user input. [REFUSAL_REASON] should be the exact reason the model gave for the initial refusal. [POLICY_REFERENCE] should cite the specific policy clause or rule that triggered the refusal. For high-risk domains such as healthcare or finance, add a [RISK_LEVEL] field and require human review of the generated permission request before presenting it to the user. Test this prompt against edge cases where the user request is genuinely unsafe and cannot be scoped—the model should return a null scope and a clear explanation rather than fabricating a dangerous permission path.

The explicit permission prompt is not a standalone component—it is a stateful gate in a larger workflow. When a model refuses a request that falls into a recoverable policy boundary, the application must pause execution, present the permission request to the user, capture explicit consent, and only then re-invoke the model with the granted scope. This harness must treat the permission prompt as a transaction boundary: no work proceeds until consent is recorded, and the consent record must be immutable and auditable. The prompt template itself produces the text of the permission request, but the harness owns the consent capture, verification, and revocation logic.

Wiring the prompt into an application requires several components. First, a refusal detector must identify when the model's initial response contains a refusal rather than a direct answer—this can be a classifier prompt, a keyword scan for refusal patterns, or a structured output field like "status": "refused". When a refusal is detected, the harness checks whether the refusal reason matches a recoverable policy boundary (e.g., "requires_explicit_permission"). If recoverable, the harness calls the explicit permission prompt with [ORIGINAL_REQUEST], [REFUSAL_REASON], [POLICY_CONTEXT], and [SCOPE_BOUNDARIES] to generate the permission request text. The generated text is presented to the user through the application UI, never through the model's own response channel, to prevent the model from simulating consent. The UI must capture an explicit affirmative action—a checkbox, a button click, or a signed confirmation—not passive acknowledgment. The captured consent must include a scope fingerprint (a hash of the permitted actions, data access, and time window) stored alongside the user ID, session ID, and timestamp in an append-only audit log.

Validation and retry logic is critical. Before re-invoking the model with the granted permission, the harness must validate that the consent scope matches the original request and hasn't been tampered with. If the model's permission request text includes scope descriptions, the harness should parse and compare them against the stored consent record. On re-invocation, the harness passes [GRANTED_SCOPE], [CONSENT_ID], and [AUDIT_TRAIL_REFERENCE] to the model so the response can reference the permission grant. If the model refuses again despite valid consent, the harness should not retry more than once—instead, escalate to a human reviewer with the full audit trail. Implement a revocation endpoint that allows users to revoke consent at any time, which immediately invalidates the scope fingerprint and prevents further processing under that grant. For high-risk domains, require a cooling-off period between consent presentation and acceptance, and log every state transition: refused → permission_requested → consent_captured → scope_validated → reprocessing → completed | re-refused → escalated. Use structured logging with trace IDs that link the original request, refusal, permission prompt, consent record, and final response for downstream audit and compliance review.

Model choice and tool use affect the harness design. Use a deterministic model or low-temperature setting for the permission request generation to ensure consistent scope language—variability here creates audit risk. If the application uses tool calls, the harness must ensure that no tools are invoked between the refusal and consent capture; the permission gate must block all side effects. For RAG-augmented systems, the permission prompt should include the relevant policy documents as [POLICY_CONTEXT] so the generated permission request accurately reflects the policy boundary. Do not store the user's consent decision in the model's context window as the sole record—the application database is the system of record. The prompt is responsible for clear communication; the harness is responsible for enforcement, audit, and revocation. Before deploying, test the full harness with: (1) a legitimate request that should receive permission, (2) a request that should remain refused even with consent, (3) a consent revocation mid-workflow, and (4) a tampered consent record to verify validation rejects it.