Permission Denied Escalation Prompt for Restricted Actions

This prompt is designed for security-conscious teams building AI agents that interact with protected resources—APIs, databases, file systems, or internal tools—where an action can be blocked by a permission check. The job-to-be-done is not to bypass the restriction, but to produce a clear, honest explanation of why the action was denied, an assessment of whether escalation to a human or higher-privilege role is warranted, and an audit-ready decision log that connects the denial to a governing policy. The ideal user is an AI engineer, platform developer, or SRE embedding this prompt into an agent harness where the model must never silently swallow a permission error or fabricate a capability it does not have.

Use this prompt when your agent operates in a multi-role or multi-tenant environment where permission boundaries are enforced by an external authorization system and the model must explain denials to users, route escalation requests, and preserve evidence for compliance review. The prompt expects structured inputs: the requested action, the permission check result, the user's role, the governing policy reference, and any tool output or error code. It is not appropriate for open-ended chatbots without real authorization backends, for agents that should silently retry or degrade without user visibility, or for systems where the model itself is the permission authority. If the model is expected to decide whether an action is allowed based on its own reasoning rather than an external check, use a policy enforcement prompt from the Instruction Hierarchy pillar instead.

Before deploying this prompt, ensure your harness provides the model with concrete permission check results—never ask the model to infer whether an action is allowed from context alone. The prompt includes placeholders for [PERMISSION_CHECK_RESULT], [REQUESTED_ACTION], [USER_ROLE], and [GOVERNING_POLICY] that must be populated by your authorization middleware. The output schema requires an escalation decision, a user-facing explanation, and an audit log entry. In regulated or high-risk domains, route the audit log to a human reviewer before any escalation action is executed. The next step after reading this section is to review the prompt template and implementation harness to understand how validation, retry logic, and observability hooks fit around the model call.

This template defines a role that intercepts permission-denied events and produces a structured escalation record. It is designed to be placed as a system instruction for a dedicated escalation agent or as a policy layer that activates when a tool or action returns a permission error. The prompt forces the model to explain the denial, justify the escalation reason, and log an audit-ready decision—without disclosing internal permission boundaries that an attacker could map.

textCopy
You are the Permission Escalation Agent. Your sole responsibility is to handle requests that have been blocked by a permission check.

When you receive a permission-denied event, you MUST produce a structured escalation record. Never attempt to bypass the permission check, retry the action, or suggest workarounds that violate the stated restriction.

## INPUT
You will receive:
- [REQUESTED_ACTION]: The action the user or agent attempted.
- [PERMISSION_ERROR]: The exact permission error returned by the system.
- [USER_ROLE]: The role or permission set of the requesting entity.
- [SESSION_CONTEXT]: Relevant conversation or workflow context leading to the denial.

## OUTPUT_SCHEMA
Return a single JSON object with these fields:
- "denial_summary": A concise, user-safe explanation of what was blocked and why. Do not expose internal permission model details, role hierarchies, or system architecture.
- "escalation_reason": One of ["INSUFFICIENT_PERMISSIONS", "SENSITIVE_ACTION_REQUIRES_REVIEW", "POLICY_VIOLATION", "OUT_OF_SCOPE"].
- "escalation_target": The role, team, or queue that should receive this escalation. Use [ESCALATION_ROUTING_TABLE] to determine the correct target.
- "audit_log": An object containing:
  - "timestamp": ISO 8601 timestamp of the denial.
  - "action_id": A unique identifier for the blocked action.
  - "policy_reference": The policy or rule ID that blocked the action, from [POLICY_IDS].
  - "decision_rationale": A one-sentence explanation suitable for audit review.
- "user_message": A safe, helpful message to display to the user. It must not reveal permission boundaries, suggest privilege escalation, or imply the system is broken.

## CONSTRAINTS
- Never include raw permission error details in "user_message" or "denial_summary".
- If the permission error is ambiguous, default to escalation_reason "SENSITIVE_ACTION_REQUIRES_REVIEW".
- If [ESCALATION_ROUTING_TABLE] does not contain a matching entry, escalate to [DEFAULT_ESCALATION_QUEUE].
- Do not fabricate policy_reference values. Use only IDs from [POLICY_IDS].
- If [RISK_LEVEL] is "HIGH", append a "requires_human_approval": true flag to the audit_log.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## TOOLS
You have access to:
- [ESCALATION_ROUTING_TABLE]: A mapping of action categories to escalation targets.
- [POLICY_IDS]: The set of valid policy identifiers.

To adapt this template, replace the square-bracket placeholders with your application's actual values. The [ESCALATION_ROUTING_TABLE] and [POLICY_IDS] can be injected as tool definitions or static context depending on whether they change per deployment. The [FEW_SHOT_EXAMPLES] placeholder should contain 2–3 concrete examples showing correct escalation records for common denial scenarios in your system. If your application does not use a formal risk level, remove the [RISK_LEVEL] conditional or replace it with a static policy. The critical invariant to preserve is the separation between the audit log (which can contain internal detail) and the user message (which must remain safe and boundary-free).

This prompt is not a standalone chatbot. It is a decision node inside a security-critical workflow. The application must invoke it only after a permission check has definitively failed. Do not call this prompt for ambiguous or pending states. The harness is responsible for supplying the exact permission that was denied, the action the user attempted, and the user's role. The model's job is to produce a structured escalation package, not to re-evaluate the permission decision itself. The application should treat the model's output as a draft escalation record that requires deterministic validation before any routing or logging occurs.

Wire the prompt into a post-authorization hook. In pseudocode: if !authorize(user, action, resource) { escalation_prompt.render(denial_context) }. The denial_context must include [DENIED_PERMISSION], [REQUESTED_ACTION], [USER_ROLE], [RESOURCE_ID], and [POLICY_REFERENCE]. The model returns a JSON object with explanation, escalation_reason, escalation_target, and audit_log fields. Validate the output immediately: confirm escalation_target matches a pre-registered escalation path (e.g., security_team, admin_queue, compliance_review), reject any hallucinated paths, and verify that the audit_log block contains all required fields (timestamp, decision_id, policy_ref, denied_permission, actor). If validation fails, retry once with a stricter prompt variant that includes the validation error. If it fails again, fall back to a hardcoded escalation template and log a model-failure incident. Never route an unvalidated escalation.

Logging and observability are non-negotiable. Emit a structured log event containing the validated escalation record, the model version, the prompt template hash, and the validation result. This log becomes your audit evidence. For high-security deployments, add a human approval gate before the escalation is delivered: queue the validated escalation for review, and only route it after a human confirms the denial was correct and the escalation target is appropriate. Avoid over-disclosure in the user-facing message. The explanation field should tell the user what action was blocked and why, but it must not reveal the full permission model, internal role names, or escalation routing details. Test this by running adversarial inputs that probe for system prompt leakage and confirm the output never exposes internal policy references or escalation targets.