Infrastructure Provisioning Approval Prompt

This prompt is for DevOps and platform engineering teams building AI-assisted infrastructure workflows. Use it when an AI agent or copilot proposes to create, modify, or destroy cloud resources and you need a structured, human-readable summary before execution. The prompt forces the model to surface resource details, estimated cost impact, region, tagging compliance, and security group implications in a consistent format that a human operator can approve, reject, or escalate. It is designed for pre-provisioning gates in Terraform, Pulumi, CloudFormation, or custom infrastructure pipelines.

Do not use this prompt for read-only queries, status checks, or actions that have already executed. It belongs at the approval step before terraform apply or equivalent, not after. The ideal user is a platform engineer embedding this prompt into a CI/CD pipeline or internal developer portal where a human must explicitly sign off on infrastructure changes. Required context includes the full plan output, the target environment, cost thresholds, and the organization's tagging and security group policies. Without this context, the model cannot produce a reliable summary.

Before wiring this into a production system, define your cost threshold for automatic escalation, your required tag schema, and your security group naming conventions. The prompt is a pre-execution gate, not a post-mortem tool. If you need to verify what already happened, use a post-action verification prompt instead. If the plan is empty or a no-op, skip this prompt entirely to avoid approval fatigue.

This prompt template is designed to be pasted directly into your AI orchestration layer. It instructs the model to act as a pre-provisioning gate, generating a structured summary of a planned infrastructure change. The summary must be approved by a human before any actual provisioning API calls are made. The template uses square-bracket placeholders that your application must replace with live data from your Infrastructure as Code (IaC) plan, CI/CD pipeline, or ticketing system.

textCopy
You are an infrastructure compliance reviewer. Before any cloud resource is provisioned, you must generate a concise, human-readable summary of the planned action. Your summary will be the final checkpoint before execution. Do not proceed with the action itself.

Generate a pre-provisioning summary based on the following inputs:

[PLANNED_RESOURCES]: A detailed list of cloud resources to be created, modified, or destroyed, including their types, names, and configurations.
[ESTIMATED_MONTHLY_COST]: The projected monthly cost impact of this change.
[DEPLOYMENT_REGION]: The target cloud region (e.g., us-east-1).
[RESOURCE_TAGS]: A key-value map of all tags that will be applied to the resources.
[SECURITY_GROUP_CHANGES]: A description of any new or modified security group rules, including open ports and CIDR ranges.
[CHANGE_REASON]: The business justification or ticket ID for this provisioning request.

Structure your output precisely as follows:

**Provisioning Summary**
*   **Intent:** A one-sentence summary of the change.
*   **Resources:** A bulleted list of each resource, its type, and its purpose.
*   **Cost Impact:** The [ESTIMATED_MONTHLY_COST], with a flag if it exceeds the $[COST_THRESHOLD] monthly threshold.
*   **Compliance Check:**
    *   **Region:** Confirm the [DEPLOYMENT_REGION] is an approved region.
    *   **Tags:** Verify all mandatory tags from the list [MANDATORY_TAG_KEYS] are present. Flag any missing tags.
    *   **Security:** Highlight any security group rules that open port 22 (SSH) or 3389 (RDP) to 0.0.0.0/0 as a critical risk.
*   **Approval Required:** State clearly that explicit human approval is required to proceed.

If any compliance check fails, add a final section titled **BLOCKING ISSUES** and list each failure. The provisioning must not proceed until all blocking issues are resolved.

To adapt this template, replace the square-bracket placeholders with data from your infrastructure pipeline. For example, [PLANNED_RESOURCES] should be populated by parsing your Terraform plan or CloudFormation change set. The [COST_THRESHOLD] and [MANDATORY_TAG_KEYS] variables should be injected from a central policy configuration. After the summary is generated, your application harness must parse the output, check for the **BLOCKING ISSUES** section, and either halt the pipeline or route the summary to a human approval queue. Never allow the model to directly call a provisioning API.

The Infrastructure Provisioning Approval Prompt is not a standalone artifact; it is a gate within a larger orchestration pipeline. The harness should treat the LLM call as a structured summary generator whose output is then validated, logged, and presented to a human reviewer before any provisioning API is invoked. The core principle is that the model proposes, the system validates, and a human decides. The harness must therefore enforce a strict separation between the read-only generation of the summary and the write-enabled execution of the plan.

Begin by constructing the prompt with the required variables: [PLAN_DETAILS] (the raw Terraform plan, Pulumi preview, or equivalent diff), [COST_ESTIMATE] (a structured cost breakdown), [COMPLIANCE_TAGS] (a list of required tags like data-classification or environment), and [SECURITY_GROUP_RULES] (the proposed network changes). The harness should call the model with temperature=0 to maximize deterministic output and request a strict JSON schema for the response, including fields like resources_to_create, estimated_monthly_cost, missing_compliance_tags, and security_risk_summary. On receiving the response, the system must not trust it blindly. Implement a post-generation validation layer that programmatically checks: (1) the JSON schema is valid, (2) the estimated_monthly_cost does not exceed a pre-configured [COST_THRESHOLD], and (3) the missing_compliance_tags array is empty. If any of these checks fail, the workflow must branch to an automatic rejection or an escalated review queue, not to the provisioning step.

For high-risk environments, the harness should integrate with a change management system like ServiceNow or Jira. After validation passes, the generated summary is formatted into a ticket or approval request containing the full LLM output, a unique plan_id, and a deep link to the raw execution plan. The human reviewer's decision—approve or reject—must be captured as a structured event with a timestamp, user ID, and optional justification. Only upon receiving an explicit approval signal should the harness invoke the downstream provisioning tool (e.g., terraform apply or a cloud SDK call). Log every step: the raw prompt, the model's raw response, the validation results, the approval ticket ID, and the final human decision. This audit trail is essential for post-deployment reviews and security investigations.

When choosing a model, prefer one with strong JSON mode and instruction-following capabilities. If using a model that does not support strict JSON mode, implement a retry loop with a repair prompt that feeds validation errors back to the model for correction. Set a maximum of 2 retries before escalating to a human operator with the malformed output. Finally, never pass raw cloud credentials in the prompt context. The harness should inject resource identifiers and configuration summaries, not secrets. The LLM's role is to summarize risk and compliance posture, not to generate or execute the final Terraform configuration.