Infrastructure Configuration Change Approval Prompt

This prompt is designed for DevOps, SRE, and platform engineering teams who are automating infrastructure management with AI agents but require a strict human-in-the-loop gate before any configuration change is applied. The core job-to-be-done is to transform a raw intent to modify infrastructure (e.g., 'scale the web tier to 10 nodes') into a structured, evidence-backed change request that a human operator can quickly review, approve, or reject. It forces the AI to act as a meticulous change manager, not an autonomous executor, by generating a diff, a blast radius assessment, a service impact prediction, and a rollback plan.

Use this prompt when the AI agent has access to infrastructure-as-code repositories, live state querying tools (like kubectl or terraform state), and the ability to propose a plan. It is appropriate for high-risk, irreversible, or regulated environments where a bad configuration push can cause an outage. Do not use this prompt for read-only queries, for changes that have already been approved in a ticketing system, or in non-production sandbox environments where autonomous execution is safe and desired. The prompt assumes the model has access to the current state and the proposed state; if you cannot provide this context programmatically, the output will be speculative and unsafe.

The ideal user is an engineer building an internal platform or operator that wraps Terraform, Kubernetes, or network automation. The prompt is a component in a larger workflow: the AI gathers context, this prompt structures the approval request, and a separate system routes that request to a human via Slack, PagerDuty, or a custom review queue. The human's decision (approve/reject) should be logged and fed back into the system. Before implementing, ensure you have a way to block execution until an explicit approval signal is received; this prompt defines the language of the gate, not the gate mechanism itself.

This prompt template is designed to be integrated into a CI/CD pipeline, chatbot, or internal platform where an AI agent proposes infrastructure changes that require human approval before execution. The template forces the model to produce a structured change request that includes a configuration diff, blast radius assessment, service impact prediction, and a rollback plan. Use this template when the cost of an autonomous misconfiguration is high—such as in production Kubernetes, Terraform, or network changes.

textCopy
You are an infrastructure change reviewer. Your task is to generate a structured change approval request for a proposed infrastructure configuration change. Do not execute any changes. Only produce the approval request payload.

## Inputs
- [CURRENT_CONFIG]: The current infrastructure configuration.
- [PROPOSED_CONFIG]: The proposed infrastructure configuration.
- [CHANGE_CONTEXT]: Why the change is needed, who requested it, and any related tickets or incidents.
- [AFFECTED_SERVICES]: A list of services, environments, or resources that may be impacted.
- [RISK_LEVEL]: The preliminary risk classification (LOW, MEDIUM, HIGH, CRITICAL).
- [OUTPUT_SCHEMA]: The required JSON schema for the approval request.
- [CONSTRAINTS]: Any deployment constraints, such as maintenance windows, freeze periods, or required approvers.

## Instructions
1. Compute a human-readable diff between [CURRENT_CONFIG] and [PROPOSED_CONFIG].
2. Assess the blast radius: which services, teams, or customers could be affected if the change fails or behaves unexpectedly.
3. Predict the service impact during and after the change, including any expected downtime, latency, or error budget consumption.
4. Draft a step-by-step rollback plan that can be executed if the change causes an incident.
5. Re-evaluate the risk level based on your blast radius and impact analysis. If it differs from [RISK_LEVEL], explain why.
6. Populate the [OUTPUT_SCHEMA] with your findings.
7. If any critical information is missing—such as an empty diff, unknown service dependencies, or an untested rollback—flag the request as BLOCKED and list the missing information.
8. Adhere to all [CONSTRAINTS]. If the change violates a constraint, flag it and do not recommend approval.

## Output Rules
- Return ONLY valid JSON matching [OUTPUT_SCHEMA].
- Do not include commentary outside the JSON.
- If the request is BLOCKED, set `approval_recommendation` to `BLOCKED` and populate `blocking_reasons`.
- Use `risk_classification` values: `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`.

To adapt this template for your environment, replace the placeholders with actual configuration data, service catalogs, and your organization's specific output schema. For Terraform changes, [CURRENT_CONFIG] and [PROPOSED_CONFIG] can be populated from terraform plan output. For Kubernetes, use kubectl diff or a GitOps diff. The [OUTPUT_SCHEMA] should match the payload your approval system expects—such as a Jira ticket, a Slack Block Kit message, or a custom API contract. If your organization uses a specific risk matrix, encode those definitions in [CONSTRAINTS] so the model's re-evaluation aligns with your internal standards. Always test this prompt against known safe and dangerous changes to verify that the risk re-evaluation and blocking logic behave as expected before deploying to production pipelines.

This prompt is designed as a pre-execution gate, not a post-hoc audit log. It should be invoked by an automation agent (e.g., a Terraform runner, Kubernetes operator, or chat-ops bot) before terraform apply, kubectl apply, or an equivalent mutating command is executed. The application harness must supply the [CURRENT_CONFIG], [PROPOSED_CONFIG], and [AFFECTED_SERVICES] placeholders by diffing the planned state against the live state. The prompt's output is a structured approval request, not an execution command. The harness must parse this output and block the pipeline until a human reviewer explicitly approves the change via a UI, Slack message, or API call. Do not wire the model's output directly to an execution engine.

The implementation should follow a strict validate → review → execute loop. First, validate the model's JSON output against a strict schema that requires risk_classification, blast_radius_assessment, and rollback_plan fields. If validation fails, retry the prompt once with the validation error injected into the [CONSTRAINTS] field. If it fails again, escalate to an on-call engineer. On successful validation, the harness must render the human_approval_summary in a review interface and set a time-to-live (TTL) for the approval. The pipeline must remain blocked until an authorized reviewer provides a signed decision. Log the full prompt, the model's output, the validator result, and the human's decision to an append-only audit store for every change attempt.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, and set temperature=0 to minimize variance in risk classification. For the tool-use pattern, define a single submit_change_approval_request function with parameters matching the output schema. This forces the model to generate a valid function call, which is easier to parse than free-text JSON. Avoid using this prompt for read-only queries or low-risk plan-only operations; it is specifically designed for mutating infrastructure changes. The next step after implementing this harness is to build a regression test suite using historical change requests to ensure the prompt's risk classification accuracy doesn't drift over time.