Access Control Change Approval Routing Prompt

This prompt is designed for IAM and security engineering teams that need to encode organizational approval policy into an AI workflow without hardcoding every resource-to-approver mapping. The core job-to-be-done is translating a structured permission change request into a sequenced, conflict-checked list of required approvers. The ideal user is a platform engineer or IAM architect building an internal tool where approval rules are too complex for static routing tables—rules that depend on resource sensitivity tiers, role criticality scores, and separation-of-duty (SoD) matrices that change independently of the application code.

To use this prompt effectively, you must provide a rich, structured context. This includes a machine-readable policy document defining risk tiers, an SoD matrix that maps conflicting role pairs, and a directory of roles with their assigned criticality. The input should be a well-formed permission change request specifying the target resource, the requested entitlements, and the requesting user's current roles. The model reasons over this context at runtime, which means the quality of the output is directly dependent on the completeness and structure of the policy data you supply. A vague policy document will produce vague, and potentially dangerous, routing decisions.

Do not use this prompt for real-time access enforcement, authentication decisions, or any workflow where the model directly grants or revokes permissions without human review. This prompt produces a routing decision—a list of people who must approve a change—not an execution command. It is a planning and orchestration step in a larger human-in-the-loop system. The output must be consumed by a downstream workflow engine that sequences the approvals and collects human attestations. Never connect this prompt's output directly to an IAM provisioning API. The critical safety boundary is that a human must always be the one to click 'approve' based on the route this prompt provides.

This template encodes your organization's access control policy directly into the model's instructions. It is designed to be pasted into your system prompt or a high-guidance user message. The prompt forces the model to reason about resource sensitivity, role criticality, and separation-of-duty (SoD) constraints before outputting a structured approval list. Do not use this prompt for general-purpose access questions; it is strictly for routing a single, well-formed permission change request through a defined approval workflow.

textCopy
You are an Access Control Approval Router for [ORGANIZATION_NAME]. Your task is to evaluate a permission change request and determine the exact approval path required before the change can be executed. You must apply the organization's access control policy, resource classification tiers, and separation-of-duty rules without exception.

## POLICY CONTEXT
- Resource Classification Tiers: [RESOURCE_TIERS_AND_DEFINITIONS]
- Role Criticality Levels: [ROLE_CRITICALITY_LEVELS]
- Separation-of-Duty (SoD) Conflict Rules: [SOD_RULES]
- Default Approval Policy: [DEFAULT_APPROVAL_POLICY]

## REQUEST DATA
- Request ID: [REQUEST_ID]
- Requester Identity: [REQUESTER_IDENTITY]
- Target User/Principal: [TARGET_PRINCIPAL]
- Requested Permission Set: [PERMISSION_SET]
- Target Resource(s): [TARGET_RESOURCES]
- Business Justification: [BUSINESS_JUSTIFICATION]
- Request Timestamp: [TIMESTAMP]

## OUTPUT SCHEMA
You must respond with a single valid JSON object conforming to this schema:
{
  "request_id": "string",
  "approval_required": boolean,
  "routing_decision": {
    "approval_type": "auto_approve | single_approver | multi_stakeholder | executive_signoff | denied",
    "approval_sequence": [
      {
        "step": number,
        "approver_role": "string",
        "approver_identity": "string | null",
        "condition": "string",
        "is_blocking": boolean
      }
    ],
    "veto_authorities": ["string"],
    "quorum_required": number | null
  },
  "risk_assessment": {
    "risk_level": "low | medium | high | critical",
    "risk_factors": ["string"],
    "sod_violations_detected": [
      {
        "violation": "string",
        "conflicting_permission": "string",
        "severity": "warning | blocking"
      }
    ]
  },
  "justification": "string",
  "policy_references": ["string"]
}

## CONSTRAINTS
1. If the requester is also a required approver for this change, flag a conflict of interest and escalate to their manager or [CONFLICT_ESCALATION_ROLE].
2. If any SoD violation is detected with "blocking" severity, the approval_type must be "denied" and the justification must cite the specific policy clause.
3. If the target resource is classified as [HIGHEST_TIER_LABEL], executive_signoff is mandatory regardless of other conditions.
4. For multi_stakeholder approvals, the sequence must respect the order defined in [APPROVAL_ORDER_POLICY].
5. If the business justification is empty or insufficient, do not proceed. Set approval_required to true and approval_type to "single_approver" for the requester's manager to validate the justification first.
6. Never output an empty approval_sequence when approval_required is true.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INSTRUCTIONS
Analyze the request against the policy context. Reason step-by-step internally, then output only the JSON object.

To adapt this template, replace every square-bracket placeholder with your organization's specific data. The [RESOURCE_TIERS_AND_DEFINITIONS] should be a structured list of your resource classification levels (e.g., 'Tier 0: Public-facing documentation', 'Tier 3: Production customer PII'). The [SOD_RULES] placeholder must contain explicit, machine-interpretable rules like 'A user with the deployer role cannot also hold the approver role for the same production environment.' For [FEW_SHOT_EXAMPLES], provide at least two worked examples: one standard multi-step approval and one that triggers a SoD denial. This prompt is designed for models with strong instruction-following and JSON mode capabilities (e.g., GPT-4o, Claude 3.5 Sonnet).

Before deploying this prompt into any production approval pipeline, you must pair it with a post-generation validation step. The JSON output must be validated against the schema, and any sod_violations_detected with blocking severity must be programmatically verified to ensure the output's approval_type is denied. For high-risk environments, route every output where risk_level is high or critical to a human review queue before the approval sequence is executed. Never allow this prompt's output to directly trigger an automated permission change without a confirmed human approval record.

This prompt is designed to sit behind an API endpoint that receives permission change requests and returns an approval routing decision. The application layer must treat the model's output as a routing recommendation, not an executable command. The model determines who should approve and in what sequence; the application enforces this by creating approval tasks in your Identity Governance and Administration (IGA) or ticketing system. Never use the model's output to directly modify access controls, group memberships, or role assignments. The separation between the routing decision and the enforcement action is the primary safety boundary in this workflow.

Implement a strict output contract validation before any approval tasks are created. The expected output is a JSON object containing an approval_chain array of objects, each with role, approver_identifier, sequence_order, and justification fields. After receiving the model response, validate that: (1) the JSON parses without error, (2) the approval_chain is a non-empty array, (3) each entry has all required fields with correct types, (4) sequence_order values are unique and sequential starting from 1, and (5) no approver appears more than once in the chain unless explicitly allowed by policy. If validation fails, retry the prompt invocation with exponential backoff (e.g., 1s, 2s, 4s delays). After two failed retries, escalate to a human operator with the original request payload and all failed outputs for manual routing. Log every prompt invocation—including the full request, raw response, validation result, and any retry attempts—to an append-only audit store. These logs are essential for compliance review and debugging routing errors.

For high-risk environments, insert a human-in-the-loop review gate after successful validation but before approval tasks are created. Present the validated routing decision alongside the original permission change request to a designated security administrator or IAM team lead. Only after explicit human confirmation should the application enqueue the approval tasks. This gate catches subtle routing errors that pass schema validation but violate organizational policy, such as routing a sensitive role change to an approver with a known conflict of interest that the model failed to detect. The confirmation step should be time-bounded: if no human response is received within a configurable window (e.g., 30 minutes for standard changes, 15 minutes for urgent ones), escalate to a broader on-call group rather than auto-approving. Model choice matters here—use a model with strong instruction-following and structured output capabilities, and consider pinning a specific model version to avoid behavioral drift in production routing decisions.