User Permission Elevation Approval Prompt

This prompt is designed for IAM and security engineering teams who are embedding AI agents into access management workflows. The core job-to-be-done is to convert a dynamic, context-rich elevation request into a standardized, blocking approval payload that a human reviewer can act on immediately. Use it when an AI agent, chatbot, or automated workflow needs to request temporary or permanent privilege escalation for a user or service account. The prompt takes structured inputs—requester identity, current role, requested role, business justification, scope, duration, and affected resources—and outputs a strict approval request object. This object acts as a non-negotiable gate: no elevation is executed by the downstream system until a human provides explicit sign-off.

The ideal user is an IAM engineer or platform developer building an internal tool where the logic of who can approve what is too nuanced for static code. Instead of hardcoding every possible elevation path, you wire this prompt into a harness that calls your identity provider's API. The prompt enforces critical safety checks that static scripts often miss. It programmatically flags segregation of duty (SoD) violations by comparing the requested role against the user's existing permissions, and it rejects requests that lack a mandatory expiration date for temporary access. This prevents the two most common IAM automation failures: granting a user a conflicting set of permissions and leaving privileged access permanently enabled. The output is not just a text block; it is a structured JSON payload with fields like approval_status, sod_violations, and required_signoffs that your application can parse to decide whether to create a ticket, send a Slack notification, or block the request entirely.

Do not use this prompt for low-risk, read-only access grants or for fully automated role-based provisioning where the policy is already codified in a rules engine. If a user simply needs read access to a public dashboard, the overhead of human review is unnecessary and this prompt will add friction without reducing risk. Similarly, if your organization uses a birthright provisioning system where roles are assigned automatically based on department and title, this prompt is the wrong tool. It is specifically for elevations above baseline, where the potential for damage—data exfiltration, system misconfiguration, financial loss—is high enough to warrant a human in the loop. Before implementing, map out your existing access policies and identify the specific elevation scenarios that require a human judgment call; deploy this prompt only at those choke points.

The prompt below is designed to sit inside your IAM automation workflow. It receives live context from your identity provider, ticketing system, and user directory, then produces a structured approval payload that a human reviewer can act on. The prompt does not make the decision—it prepares the evidence, flags risks, and enforces completeness so the reviewer can decide quickly.

textCopy
You are an IAM access review assistant operating inside a permission elevation approval pipeline. Your job is to produce a structured elevation request that a human reviewer can approve, deny, or return for clarification. You do not grant access. You do not decide outcomes.

## INPUT
- Requesting User: [REQUESTING_USER_IDENTITY]
- Current Role(s): [CURRENT_ROLES]
- Requested Role(s): [REQUESTED_ROLES]
- Justification Provided: [USER_JUSTIFICATION]
- Requested Scope Duration: [SCOPE_DURATION]
- Affected Resources: [AFFECTED_RESOURCES]
- Ticket Reference: [TICKET_ID]
- Organizational Policy Reference: [POLICY_REFERENCE]

## OUTPUT_SCHEMA
Return a single JSON object with these fields:
- "request_id": string (ticket reference or generated identifier)
- "requesting_user": string
- "current_role_summary": string (plain-language summary of current access)
- "requested_role_summary": string (plain-language summary of requested access)
- "justification": string (user-provided justification, verbatim)
- "scope_duration": string (requested duration; flag if missing or permanent)
- "affected_resources": array of strings
- "segregation_of_duty_conflicts": array of objects with "conflict_description" and "severity" ("high", "medium", "low")
- "missing_fields": array of strings (required fields that are absent or underspecified)
- "risk_flags": array of strings (e.g., "permanent elevation requested", "no expiration set", "privileged role combination")
- "recommended_review_questions": array of strings (questions the reviewer should ask before approving)
- "approval_recommendation": one of "ready_for_review", "needs_clarification", "high_risk_requires_escalation"

## CONSTRAINTS
- If [SCOPE_DURATION] is missing, "permanent", or exceeds [MAX_ELEVATION_HOURS], add a risk flag and include "missing_expiration" in missing_fields.
- If [REQUESTED_ROLES] includes any role from [PRIVILEGED_ROLE_LIST], add a risk flag and check for segregation-of-duty conflicts against [CURRENT_ROLES].
- If [USER_JUSTIFICATION] is fewer than [MIN_JUSTIFICATION_CHARS] characters or contains only generic text, add "needs_clarification" to approval_recommendation.
- Never fabricate missing fields. If a required input is absent, list it in missing_fields.
- Do not include PII beyond what is provided in the input fields.

## EXAMPLES
Example input: Requesting user "alice.chen@company.com", current role "developer", requested role "db_admin", justification "need to run migration script for PROD-4421", scope duration "4 hours", affected resources "production-db-cluster".
Example output: {"request_id": "PROD-4421", "requesting_user": "alice.chen@company.com", "current_role_summary": "Standard developer access", "requested_role_summary": "Database administrator on production cluster", "justification": "need to run migration script for PROD-4421", "scope_duration": "4 hours", "affected_resources": ["production-db-cluster"], "segregation_of_duty_conflicts": [{"conflict_description": "Developer requesting DB admin on production", "severity": "medium"}], "missing_fields": [], "risk_flags": ["privileged role combination"], "recommended_review_questions": ["Has the migration been tested in staging?", "Is there a rollback plan?"], "approval_recommendation": "ready_for_review"}

## TOOLS
You have access to:
- lookup_user_roles(identity): returns current role assignments and role history
- check_sod_policy(role_a, role_b): returns any segregation-of-duty conflicts between two roles
- get_policy(policy_ref): returns the text of the organizational access policy

Call tools as needed before producing the output. If a tool call fails, note the failure in risk_flags and proceed with available data.

## RISK_LEVEL
This workflow controls access to production systems. Errors can cause data exposure, service disruption, or compliance violations. When in doubt, escalate to "high_risk_requires_escalation".

To adapt this template, replace every square-bracket placeholder with live data from your IAM system before sending the prompt to the model. The [PRIVILEGED_ROLE_LIST] should come from your role catalog. [MAX_ELEVATION_HOURS] and [MIN_JUSTIFICATION_CHARS] should match your access policy. Wire the tool implementations (lookup_user_roles, check_sod_policy, get_policy) to your actual identity provider and policy store APIs. If your model does not support native tool calling, remove the TOOLS section and pre-resolve those lookups in your application layer, injecting the results as additional context fields.

Before deploying, run this prompt against at least 20 test cases covering: missing justification, permanent elevation requests, segregation-of-duty violations, missing expiration, and normal low-risk elevations. Validate that the output JSON parses correctly and that approval_recommendation matches your expected escalation path for each case. If the model hallucinates fields or skips risk flags, tighten the CONSTRAINTS section with explicit negative examples. Always log the full prompt and response for audit, and never route an approval_recommendation of high_risk_requires_escalation to an automated approval path.

This prompt is designed to be the decision-support engine inside an automated access management system, not a standalone chatbot. The application layer is responsible for gathering the required context—current role, requested role, justification, scope, and affected resources—from the user or upstream system. The prompt then generates a structured elevation request payload that must be validated before it ever reaches a human approver. Because privilege escalation is a high-risk action, the implementation harness must enforce strict validation, idempotency, and an audit trail at every step.

Wiring the prompt into an application involves three stages: pre-prompt validation, model invocation, and post-prompt enforcement. Before calling the model, validate that all required inputs are present and well-formed. The [CURRENT_ROLE] and [REQUESTED_ROLE] fields must match your IAM role taxonomy. The [JUSTIFICATION] must be non-empty and exceed a minimum length to prevent trivial requests. The [SCOPE_DURATION] must be a parseable duration or an explicit permanent flag. If any input fails validation, return an error to the user immediately—do not invoke the model. When calling the model, use a low-temperature setting (0.0–0.2) to maximize structural consistency, and set a response_format constraint for JSON if your provider supports it. On the first invocation failure, retry once with the same parameters; if the second attempt fails, log the failure and escalate to an on-call engineer rather than silently falling back to a degraded approval request.

Post-prompt enforcement is where the harness earns its keep. Parse the model's JSON output and validate it against a strict schema that includes required fields: elevation_type (temporary or permanent), segregation_of_duty_conflicts (array of detected conflicts), expiration_timestamp (null for permanent), and risk_classification. If the output fails schema validation, do not retry the prompt—log the malformed output and block the request. If the output passes validation, check for hard blocking conditions: any detected segregation of duty violation must halt the workflow and route to a security architect for manual review. If no hard blocks exist, format the elevation request into a human-readable approval card and push it to your review queue (e.g., Jira, ServiceNow, Slack workflow). The approval card must include a unique request_id, the full prompt output, and a deep link back to the audit log. Only after explicit human approval should your application call the IAM provisioning API. Log the final decision, approver identity, and timestamp to your audit system. Never allow the model's output to directly trigger an IAM change—the human-in-the-loop gate is non-negotiable.