Cloud IAM Policy Over-Permission Review Prompt

This prompt is designed for cloud security engineers and DevSecOps teams who need to audit existing IAM policies for excessive permissions. The core job-to-be-done is triage: you have a raw IAM policy document (JSON) and a clear definition of intended access patterns—ideally derived from actual CloudTrail logs or a well-scoped requirements document—and you need a structured, actionable finding that identifies which roles or statements grant more access than necessary. The ideal user is someone who understands IAM evaluation logic, can provide a precise [INTENDED_ACCESS] specification, and will treat the model's output as a starting point for remediation, not a final authority.

You should use this prompt when you have a specific policy to review and a concrete, machine-readable or clearly enumerated definition of what access is actually needed. For example, you might provide a policy attached to an EC2 instance role and a list of required S3 buckets and KMS keys, or a summary of CloudTrail events for the last 90 days. The prompt works best as an interpretation layer that sits between raw policy data and your vulnerability management workflow (e.g., Jira tickets, Security Hub findings). It is not a replacement for automated reasoning tools. Always run the policy through IAM Access Analyzer and the IAM Policy Simulator first; use this prompt to interpret the results, identify over-privileges that policy simulator warnings might not explicitly flag, and draft the specific permission removal recommendations in plain English.

Do not use this prompt for real-time authorization decisions, for generating new policies from scratch, or as a substitute for a full policy-as-code review pipeline. It is also inappropriate for policies where the intended access is unknown or purely speculative—the quality of the output depends entirely on the precision of the [INTENDED_ACCESS] input. If you cannot define what access is needed, the model will produce unreliable or overly aggressive recommendations. Finally, never apply the model's suggested policy changes directly to production without human review and testing in a staging environment. The prompt is a triage accelerator, not an auto-remediator.

This section provides the core prompt template you will paste into your AI harness. The template is designed to ingest a cloud IAM policy document alongside a set of usage logs or an intended access specification. It instructs the model to perform a structured, permission-by-permission analysis, identifying any granted permissions that are not justified by actual usage. The output is a strict JSON schema that maps directly to a downstream remediation or ticketing system, ensuring the review is actionable rather than conversational.

Below is the copy-ready template. Replace every square-bracket placeholder with real data before sending. The [POLICY_DOCUMENT] should contain the raw JSON of your IAM policy. The [USAGE_DATA] placeholder should be populated with a summary of actions from CloudTrail logs, IAM Access Analyzer findings, or a list of intended permissions from your architecture specification. The [CONSTRAINTS] field is where you define exceptions, such as permissions required for emergency break-glass roles or known service-linked role defaults that should not be flagged. The [RISK_LEVEL] placeholder allows you to set a threshold for the analysis, such as 'Medium' or 'High', to filter out low-severity findings.

textCopy
You are a cloud security auditor specializing in IAM policy least-privilege analysis. Your task is to compare the granted permissions in an IAM policy against actual usage data or an intended access pattern specification. You must identify any permissions that are over-privileged and recommend specific actions to remove them.

## INPUT

**IAM Policy Document:**
```json
[POLICY_DOCUMENT]

Usage Data or Intended Access Specification:

textCopy
[USAGE_DATA]

CONSTRAINTS

• Do not flag permissions that are part of the following exception list: [CONSTRAINTS]
• Only report findings with a severity level of [RISK_LEVEL] or higher.
• If a permission is granted via a wildcard ("*"), but only a subset of actions under that service are used, you must recommend replacing the wildcard with the specific used actions.
• For each finding, you must provide a direct quote from the policy document as evidence.
• If the usage data is empty or unavailable, you must state this clearly and mark all findings as "unverified" with a confidence score of "Low".

OUTPUT_SCHEMA

You must respond with a valid JSON object conforming to this schema:

jsonCopy
{
  "analysis_metadata": {
    "policy_name": "string",
    "analysis_timestamp": "string (ISO 8601)",
    "usage_data_source": "string",
    "total_permissions_granted": "integer",
    "total_permissions_used": "integer"
  },
  "findings": [
    {
      "finding_id": "string",
      "severity": "High | Medium | Low",
      "policy_statement_sid": "string",
      "overly_permissive_action": "string (e.g., 's3:DeleteBucket')",
      "evidence": "string (direct quote from policy)",
      "actual_usage": "string (e.g., 's3:GetObject, s3:PutObject')",
      "recommendation": "string (specific new policy JSON snippet or action list)",
      "confidence": "High | Medium | Low"
    }
  ],
  "summary": {
    "total_findings": "integer",
    "high_severity_count": "integer",
    "medium_severity_count": "integer",
    "low_severity_count": "integer",
    "overall_risk_assessment": "string"
  }
}

After pasting the template, the most critical adaptation step is populating the [USAGE_DATA] field with high-quality information. Do not rely on a human's memory of what a service should access. Instead, programmatically generate this data from AWS CloudTrail event histories, GCP Audit Logs, or Azure Activity Logs, filtering for successful actions taken by the specific role in the last 90 days. If you are reviewing a policy before deployment, use your infrastructure-as-code definitions or a formal access matrix as the intended specification. The quality of this input is the single biggest factor in the prompt's success. Before integrating this prompt into a CI/CD pipeline, run it against a set of policies with known over-permissions, validated by IAM Access Analyzer, to calibrate the severity and confidence thresholds.

This prompt is designed to operate as a batch analysis step within a cloud security posture management workflow, not as a real-time interactive chatbot. The primary integration point is a security review pipeline that periodically (or on-demand) exports IAM policy documents and corresponding access advisor or policy simulator results, feeds them to the model, and processes the structured findings. The prompt expects a complete policy document and a set of usage or intended-access records as input, so the harness must assemble this context before calling the model. Because IAM misconfigurations can directly lead to privilege escalation and data exposure, the harness must treat every model output as a recommendation requiring human or automated policy-simulator verification before any policy change is applied.

Input assembly and validation: The harness should collect the raw IAM policy JSON from the cloud provider's API (e.g., aws iam get-policy-version or gcloud iam roles describe) and pair it with access activity data from IAM Access Analyzer, CloudTrail, or equivalent usage logs. Before calling the model, validate that the policy document is well-formed JSON and that the usage records contain the expected fields (principal, action, resource, last accessed timestamp). Reject malformed inputs early and log the failure for operator review. The prompt's [POLICY_DOCUMENT] placeholder should receive the full policy JSON as a string, while [ACCESS_ACTIVITY] should receive a structured summary of which permissions were actually used, formatted as a table or JSON array. If usage data is unavailable, the harness should substitute intended access patterns from a configuration file or architecture document, and the prompt's [CONTEXT] field should explicitly note that the analysis is based on intended rather than observed usage.

Model selection and tool use: This is a reasoning-heavy task that benefits from models with strong analytical capabilities and large context windows to hold entire policy documents. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate choices. The prompt does not require function calling or external tool use during generation, but the harness should consider a two-pass architecture: first, call the model to extract the list of over-privileged permissions with their justifications; second, run each recommended removal through the cloud provider's IAM policy simulator (e.g., iam simulate-principal-policy) to confirm that the removal would not break legitimate access. The harness should flag any recommendation that fails simulation and append the simulation result to the finding before presenting it to a human reviewer.

Output validation and retries: The prompt instructs the model to return a JSON array of findings with a specific schema. The harness must validate that the response is parseable JSON and that each finding object contains the required fields (role_name, permission, resource, last_used_or_intended, risk_level, recommendation, justification). If validation fails, implement a single retry with the validation error message appended to the prompt as additional [CONSTRAINTS] context. If the retry also fails, log the raw response and escalate for manual review rather than silently dropping the analysis. For high-risk environments, consider requiring a second model call (from a different model or temperature setting) to independently verify the findings and flag disagreements.

Logging, audit trail, and human review: Every invocation should produce an audit record containing the input policy hash, the model version, the raw and parsed outputs, validation results, and any simulation outcomes. Store these records in an append-only log for compliance and retrospective analysis. The harness should route findings with risk_level: critical or risk_level: high to an immediate review queue (e.g., a Jira ticket or PagerDuty alert) and batch lower-severity findings for weekly review. Never automatically apply IAM policy changes based solely on model output. The harness should generate a proposed policy diff and require explicit human approval or a break-glass automation with compensating controls before any modification reaches the cloud environment. This is the single most important safety boundary in the implementation.