Cloud IAM Permission Denied Recovery Prompt

This prompt is designed for cloud engineers and SRE teams who encounter an 'Access Denied' error during automated pipeline execution or manual operations in AWS, GCP, or Azure. The core job-to-be-done is rapid, safe recovery: you provide the specific denied API call and the existing IAM policy document, and the model generates a minimal, least-privilege policy addition that resolves the immediate permission boundary. This is a surgical recovery tool, not a policy authoring workshop. It assumes you already have a functional policy that is simply missing one or more specific actions for a resource.

To use this prompt effectively, you must have two concrete pieces of context ready: the exact API action that was denied (e.g., s3:GetObject, storage.objects.get) and the complete, current JSON policy document attached to the failing identity. Without the current policy, the model cannot calculate the minimal diff and may suggest overly broad permissions. This prompt is ideal for fast recovery in CI/CD pipelines where a new feature requires a previously ungranted permission, or for operators debugging a sudden permission failure in a previously working service. The output is a corrected policy statement, not a full policy document, which you must then validate and apply through your standard IaC or manual change process.

Do not use this prompt for generating IAM policies from scratch, as it requires an existing policy to diff against. It is also unsuitable for cross-account role assumption failures where the root cause is a misconfigured trust policy on the target role, not a permissions policy on the calling identity. Finally, avoid this prompt for complex multi-service authorization failures where the denial is caused by an implicit deny from a Service Control Policy (SCP), permissions boundary, or session policy; the prompt's scope is limited to identity-based policy statements. In all cases, a human must review the generated policy addition for least-privilege compliance and resource scope correctness before applying it to any environment.

The prompt below is designed to be dropped into a recovery harness when a cloud API call returns an access-denied error. It expects the raw error message, the denied API action, and the current IAM policy document attached to the principal that was denied. The model's job is to produce a corrected policy statement that grants only the missing permission, not to rewrite the entire policy or suggest broad wildcard permissions. Replace every square-bracket placeholder with live data before sending the prompt to the model. If any placeholder is empty, the harness should abort the retry and escalate to a human operator rather than sending an underspecified prompt.

textCopy
You are an IAM policy repair assistant operating under a strict least-privilege constraint.

## INPUT
- Denied API Call: [DENIED_API_ACTION]
- Error Message: [ERROR_MESSAGE]
- Current IAM Policy Document (JSON): [CURRENT_POLICY_JSON]
- Cloud Provider: [CLOUD_PROVIDER]
- Resource ARN (if available): [RESOURCE_ARN]

## CONSTRAINTS
1. Propose the smallest possible permission addition that resolves the denial.
2. Never suggest wildcard actions (e.g., `*:*` or `*`) unless the current policy already grants an equivalent wildcard and you are matching its scope.
3. Never suggest wildcard resources unless the error and current policy clearly indicate a resource-level wildcard is already in use.
4. If the denial is caused by a condition key mismatch rather than a missing action, explain the condition conflict instead of adding new actions.
5. If the current policy already contains the required permission but a condition, boundary, or SCP is blocking it, state that explicitly and do not suggest policy changes.
6. Output only the minimal new policy statement in the provider's native JSON policy format, plus a one-sentence explanation of what was added and why.

## OUTPUT_SCHEMA
Return a JSON object with exactly these fields:
{
  "action": "add_statement" | "modify_condition" | "no_change" | "escalate",
  "explanation": "One-sentence explanation of the diagnosis and change.",
  "new_statement": { ... } | null,
  "condition_note": "string explaining condition conflict, if applicable" | null
}

## EXAMPLES
Example 1 - Missing action:
Input: Denied API Call: s3:GetObject, Error: AccessDenied, Current Policy: {"Statement":[{"Effect":"Allow","Action":["s3:ListBucket"],"Resource":"arn:aws:s3:::my-bucket"}]}
Output: {"action":"add_statement","explanation":"Added s3:GetObject permission on the bucket objects to resolve the GetObject denial while preserving the existing ListBucket permission.","new_statement":{"Effect":"Allow","Action":["s3:GetObject"],"Resource":"arn:aws:s3:::my-bucket/*"},"condition_note":null}

Example 2 - Condition mismatch:
Input: Denied API Call: ec2:StartInstances, Error: AccessDenied due to condition key, Current Policy includes a condition restricting ec2:StartInstances to tag Environment=prod but the instance has Environment=staging.
Output: {"action":"modify_condition","explanation":"The policy allows StartInstances only when the Environment tag equals prod, but the target instance is tagged staging. No new action is needed; the condition must be updated or the instance tag changed.","new_statement":null,"condition_note":"Condition key ec2:ResourceTag/Environment requires value 'prod'; target instance has 'staging'."}

## RISK_LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high" or "critical", append: "Flag this output for human review before applying. Do not auto-apply the suggested policy change."

After copying the template, wire it into a recovery harness that validates the model's output against the provider's IAM policy schema before any apply step. If the action field is escalate, the harness must route the case to a human operator with the full error context and model explanation. If the action is add_statement, diff the proposed statement against the current policy to confirm it adds only net-new permissions and does not widen existing ones. For AWS, validate the statement against the IAM policy grammar using a library like policyuniverse or iam-floyd before calling PutRolePolicy or equivalent. For GCP, validate against the allowable permissions list for the target resource type. For Azure, validate against the provider's resource provider operations list. If validation fails, increment the retry counter and re-prompt with the validation error included in [ERROR_MESSAGE]. After three failed validation attempts, escalate to a human and log the full retry trace.

Do not use this prompt for denials caused by organization-level SCPs, service control policies, or identity boundary policies that the principal's direct policy cannot override. In those cases, the model should return action: escalate with an explanation that the block is external to the submitted policy document. Also avoid using this prompt when the denial involves cross-account access or resource-based policies on the target resource, unless those policies are included in [CURRENT_POLICY_JSON] as additional context. The prompt is scoped to identity-based policy repair only.

This prompt is designed to sit inside a recovery harness that intercepts a permission-denied error from a cloud API, gathers the necessary context, and presents a corrected policy suggestion to a human operator before any changes are applied. The harness should never auto-apply IAM changes. The prompt's job is to produce a minimal, least-privilege policy addition that can be reviewed. The harness is responsible for collecting the denied API call details, the current policy document, and any resource context, then passing them into the prompt template as [DENIED_API_CALL], [CURRENT_POLICY_DOCUMENT], and [RESOURCE_CONTEXT].

Wire the prompt into an incident response or CLI tool pipeline. When a cloud SDK or API returns an AccessDenied or 403 error, the harness should extract the denied action (e.g., s3:GetObject), the resource ARN, and the current IAM policy attached to the principal that made the call. Pass these into the prompt. After the model returns a suggested policy statement, the harness must run a policy syntax validator (e.g., AWS IAM policy simulator dry-run, GCP IAM policy lint, or Azure policy validation API) before showing the output to the operator. If the syntax check fails, retry the prompt once with the validation error appended as [VALIDATION_ERROR] in the retry context. Do not retry more than twice; escalate to a human with the original error and both attempts logged.

Model choice matters here. Use a model with strong structured output and code generation capabilities (e.g., Claude 3.5 Sonnet, GPT-4o). Set temperature to 0 or very low (0.1) to minimize creative drift in policy syntax. The output should be a JSON object with suggestedStatement (the IAM policy JSON snippet), explanation (a plain-English justification of the minimal permission), and leastPrivilegeCheck (a boolean indicating whether the suggestion passes a basic least-privilege review). The harness should parse this JSON, display the explanation to the operator, and require explicit approval before the policy change is staged. Log every suggestion, validation result, and approval decision for audit purposes. Never allow the harness to bypass the human approval step for IAM modifications.