Security Policy and IAM Configuration Compliance Prompt

This prompt is for cloud security teams, DevSecOps engineers, and compliance auditors who need to verify that generated or existing IAM policies, security group rules, and firewall configurations follow least-privilege principles. It acts as an LLM judge, taking a policy document and a set of security standards as input, and producing a structured compliance report. Use this when manual review is too slow, when you need consistent grading across hundreds of policies, or when you want to embed automated policy checks into a CI/CD pipeline. This is an evaluation prompt, not a policy generation prompt. It assumes a policy already exists and needs to be audited.

The ideal user has access to the raw policy JSON or configuration file and a defined set of security benchmarks—such as CIS, AWS Foundational Security Best Practices, or internal least-privilege standards. You must supply both the policy document and the evaluation criteria as inputs. The prompt works best when the standards are explicit and testable: 'No wildcard actions,' 'No * resource ARNs without conditions,' or 'All S3 bucket policies must restrict Principal to specific accounts.' Vague standards like 'follow best practices' will produce unreliable results. Before using this prompt, confirm that your standards can be expressed as discrete, verifiable rules.

Do not use this prompt to generate new policies, to remediate findings automatically, or to replace a human sign-off for production IAM changes. It is an evaluation tool, not an authorization tool. The output flags violations and risks but does not fix them. For high-severity environments—such as PCI DSS, HIPAA, or FedRAMP—always route findings through a human reviewer before closing any compliance ticket. Also avoid using this prompt on policies that contain secrets, internal account IDs, or sensitive resource names in plaintext; redact those fields before sending them to an external model API.

When integrating this into a pipeline, treat the prompt output as a signal, not a verdict. Combine it with static analysis tools like checkov, tfsec, or AWS IAM Access Analyzer for defense-in-depth. The LLM judge excels at catching semantic over-permission that static tools miss—such as a policy that is technically valid but grants excessive access relative to a stated business purpose—but it can also hallucinate findings or miss edge cases. Always log the full prompt, response, and policy version for auditability. If you are evaluating more than 50 policies per run, batch them and include a unique policy identifier in each request so you can trace findings back to source files.

This template is designed to be dropped directly into an LLM evaluation harness. It expects a generated or proposed IAM policy document, security group configuration, or firewall rule set as input, along with a description of the intended workload. The model acts as a compliance judge, producing a structured report that flags over-permission, missing restrictions, and best-practice violations. Replace every square-bracket placeholder with real data before sending the prompt to the model. The template includes explicit instructions for handling ambiguous cases, requiring the judge to note uncertainty rather than guess.

textCopy
SYSTEM:
You are a cloud security compliance auditor. Your job is to evaluate IAM policies, security group rules, and firewall configurations against least-privilege principles. You produce structured compliance reports with specific, actionable findings. Never approve a configuration you are uncertain about. Flag ambiguity explicitly.

USER:
Evaluate the following security configuration for compliance with least-privilege principles.

CONFIGURATION TO EVALUATE:
[POLICY_DOCUMENT]

INTENDED WORKLOAD DESCRIPTION:
[WORKLOAD_DESCRIPTION]

SERVICE CONTEXT (optional):
[SERVICE_CONTEXT]

COMPLIANCE STANDARDS TO CHECK (select one or more):
[COMPLIANCE_STANDARDS]

EVALUATION INSTRUCTIONS:
1. Parse the configuration and identify every permission, rule, and access grant.
2. For each permission, determine whether it is necessary for the described workload.
3. Flag any permission that exceeds what the workload requires (over-permission).
4. Identify missing restrictions that should be present (e.g., missing condition keys, missing resource constraints, missing IP restrictions).
5. Check for best-practice violations (e.g., wildcard principals, overly broad resource ARNs, missing MFA requirements).
6. If the workload description is insufficient to make a determination, flag the ambiguity and explain what additional information is needed.

OUTPUT FORMAT:
Return a JSON object with the following schema:
{
  "overall_compliance": "COMPLIANT" | "PARTIALLY_COMPLIANT" | "NON_COMPLIANT" | "INSUFFICIENT_INFORMATION",
  "findings": [
    {
      "severity": "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "INFO",
      "category": "OVER_PERMISSION" | "MISSING_RESTRICTION" | "BEST_PRACTICE_VIOLATION" | "AMBIGUITY",
      "resource": "The specific permission, rule, or statement identifier",
      "description": "Clear explanation of the finding",
      "recommendation": "Specific, actionable fix",
      "evidence": "Exact excerpt from the configuration that triggered this finding"
    }
  ],
  "summary": "One-paragraph summary of the compliance posture",
  "uncertainty_flags": ["List of questions that need answers before a definitive assessment can be made"]
}

CONSTRAINTS:
- Do not fabricate permissions that are not in the configuration.
- If the workload description is vague, flag it; do not assume.
- Every CRITICAL or HIGH finding must include an exact excerpt from the configuration.
- If no issues are found, return an empty findings array and COMPLIANT status.

Before integrating this template into a production pipeline, you must adapt the [COMPLIANCE_STANDARDS] placeholder to match your organization's specific policies. Common values include CIS_AWS_FOUNDATIONS, PCI_DSS, HIPAA, SOC2, or a custom internal standard. If you use a custom standard, append a brief description of its key requirements to the prompt so the model has enough context to apply it. The [SERVICE_CONTEXT] placeholder is optional but strongly recommended for complex evaluations—include details like the AWS service being used, the data classification level, and the network architecture. After adapting the template, run it against a golden dataset of known-compliant and known-noncompliant configurations to calibrate severity thresholds before deploying to production.

This prompt is designed to operate as a policy review gate within a CI/CD pipeline, a security automation workflow, or a cloud posture management tool. The primary integration point is a function that receives an IAM policy document (JSON), a set of security group rules, or a firewall configuration as a string, injects it into the [POLICY_DOCUMENT] placeholder, and sends the request to the LLM. The output is a structured JSON compliance report, which must be parsed and validated before any downstream action is taken. Because the prompt produces a machine-readable report, the harness should enforce a strict JSON schema on the response, rejecting any output that does not match the expected compliance_report structure, including the over_permission_flags, missing_restrictions, and best_practice_violations arrays.

The implementation should include a validation and retry layer. After receiving the model's JSON response, validate it against a predefined schema (e.g., using pydantic or jsonschema). If validation fails, retry the prompt up to two times with a repair instruction that includes the specific validation error. For high-severity findings—such as a critical over-permission flag on a production role—the harness must not auto-remediate. Instead, it should log the full prompt, the raw response, and the parsed report, then route the finding to a human review queue (e.g., a Jira ticket or a Slack notification) with a clear summary of the violation and the affected resource ARN. For low-severity best-practice suggestions, the harness can automatically open a non-blocking task. Model choice matters here: use a model with strong JSON mode and reasoning capabilities (e.g., claude-3-5-sonnet or gpt-4o) to minimize structural errors and improve the accuracy of least-privilege analysis.

To prevent drift and ensure the prompt remains effective, build a regression test suite of 10-15 IAM policies with known violations (e.g., a policy with "Action": "*" and "Resource": "*", a security group with 0.0.0.0/0 ingress on port 22, and a fully compliant least-privilege policy). Run this prompt against the suite on every change to the prompt template or the system instructions. Measure the precision and recall of over_permission_flags against your labeled ground truth. If the false negative rate on critical over-permissions exceeds 5%, block the prompt change from shipping. Finally, instrument the harness with logging that captures the prompt_version, model_id, policy_arn, compliance_score, and review_decision for every evaluation, enabling audit trails and cost attribution.