User Permission Change Confirmation Prompt

This prompt is designed for identity and access management (IAM) workflows where an AI agent or automated system is about to execute a user permission change. Its job is to generate a concise, structured summary of the planned change before execution, creating a human-readable checkpoint. Use this prompt when you need to capture the principal, the scope of access being granted or revoked, a separation-of-duties check, and a clear justification. This is a required step before any irreversible IAM action in a governed system. The audience includes platform engineers, security engineers, and compliance teams building AI-assisted access management tools.

The ideal user is an engineering team embedding this prompt into a ticketing system, a Slack bot, or an internal admin tool. The required context includes the requesting user's identity, the target resource or role, the type of change (grant, revoke, escalate, or modify), the business justification, and any relevant policy documents. The prompt is not a replacement for an identity provider's policy engine; it is a summarization and confirmation layer that sits before the actual API call to the IAM system. Do not use this prompt for real-time authentication decisions, session validation, or cryptographic operations.

Before wiring this prompt into production, define the sensitivity tiers for permission changes in your organization. A role assignment for a read-only dashboard viewer may require only a summary log, while a production database admin grant should force a multi-stakeholder approval with a break-glass justification. The prompt template below expects a [RISK_LEVEL] variable that your harness should compute from the target resource's classification, not from the model's own judgment. If the model hallucinates a risk downgrade, your harness must catch it before routing the confirmation to a human reviewer.

This prompt template is designed to be the core instruction set for generating a human-readable checkpoint before a user permission change is executed. It forces the model to summarize the change, assess its scope, and flag separation-of-duties concerns. The output is not the final approval itself but the structured evidence a human or an automated policy engine needs to make an informed decision. Use this template as a direct input to your model, replacing the bracketed placeholders with data from your identity and access management (IAM) system.

codeCopy
You are an access control auditor. Generate a structured confirmation summary for the following pending user permission change. Do not execute the change. Your output must be a strict JSON object.

[CHANGE_DETAILS]
Action: [ACTION_TYPE: GRANT, REVOKE, or MODIFY]
Principal: [USER_EMAIL_OR_ID]
Target Resource: [RESOURCE_NAME_OR_ARN]
Permissions: [LIST_OF_PERMISSIONS]
Requested By: [REQUESTER_EMAIL]
Justification: [USER_PROVIDED_JUSTIFICATION]

[CONTEXT]
Current User Groups: [LIST_OF_CURRENT_USER_GROUPS]
Current Direct Permissions: [LIST_OF_CURRENT_DIRECT_PERMISSIONS]
Sensitive Resource Classification: [CLASSIFICATION_LEVEL: e.g., PII, PCI, PHI, INTERNAL, PUBLIC]

[OUTPUT_SCHEMA]
{
  "summary": "A one-sentence, plain-language summary of the change.",
  "principal": "The user or service account affected.",
  "change_type": "grant, revoke, or modify.",
  "scope_of_access": "A clear description of what the principal will be able to do after the change.",
  "separation_of_duties_concern": {
    "flag": true or false,
    "reason": "If true, explain the conflicting permissions or roles. If false, state 'No conflict detected.'"
  },
  "risk_level": "low, medium, or high based on the sensitivity of the resource and scope of access.",
  "required_approval_routing": "Based on risk level, suggest 'auto-approve', 'manager_approval', or 'security_approval'."
}

[CONSTRAINTS]
- If the action is GRANT and the resource is classified as PII, PCI, or PHI, the risk_level must be at least 'medium' and required_approval_routing must not be 'auto-approve'.
- If a separation_of_duties_concern is flagged as true, the required_approval_routing must be 'security_approval'.
- Base your output strictly on the provided context. Do not infer permissions not listed.

To adapt this template, integrate it into your IAM workflow's pre-execution hook. The [CHANGE_DETAILS] and [CONTEXT] placeholders should be populated by your application layer by querying your user directory and permission database. The [OUTPUT_SCHEMA] is your contract; parse the resulting JSON to drive your approval logic. For high-risk changes, ensure the generated summary is logged immutably alongside the final approval decision to create a complete audit trail. The next step after generating this summary is to route it to the approval queue specified in the required_approval_routing field.

This prompt is designed to sit directly before an identity and access management (IAM) write operation in an agent or automated workflow. Its job is to produce a structured, human-readable checkpoint that captures the full scope of a permission change, the principal involved, and any separation-of-duties conflicts. The harness should never allow the downstream IAM API call to proceed until the confirmation output has been generated, logged, and, for sensitive changes, explicitly approved by a human. Treat the prompt output as a gating artifact, not as a logging afterthought.

The implementation harness must enforce a strict sequence: first, collect the required inputs—[REQUESTING_USER], [TARGET_PRINCIPAL], [PERMISSION_CHANGE_DETAILS], [JUSTIFICATION], and [SENSITIVITY_LEVEL]. The [SENSITIVITY_LEVEL] field (e.g., low, medium, high, critical) should be derived from a predefined policy, such as the tier of the resource being accessed or the role being granted. Before calling the LLM, validate that all inputs are non-empty and that the justification is not a trivial placeholder. After receiving the model's structured output, parse it against a strict schema that includes summary, scope_of_access, separation_of_duties_conflicts, and risk_notes. If parsing fails, retry once with a repair prompt; if it fails again, block the action and escalate to an on-call channel.

The approval routing logic lives in the harness, not the prompt. For low sensitivity changes, the harness may auto-approve after logging the confirmation to an audit trail. For medium and above, the harness must route the formatted summary to a review queue, such as a Slack channel, a Jira ticket, or a dedicated approval UI, and block until an authorized approver responds. The harness should enforce a time-to-live (TTL) on the approval request; if the TTL expires, the action is automatically rejected and the requestor is notified. For critical changes, require multi-stakeholder approval as defined by your organization's access control policy. Every step—input collection, prompt call, output validation, routing decision, and human response—must be logged immutably with timestamps and actor identities for audit and governance reviews.