Secret Rotation Summary and Approval Prompt

This prompt is designed for a single, high-stakes job: generating a structured, human-readable summary of a planned secret rotation immediately before the old secret is revoked. Its primary user is a security engineering team integrating AI-assisted checks into an existing secrets management pipeline (e.g., HashiCorp Vault, AWS Secrets Manager, CI/CD credential stores). The prompt operates at the approval gate, consuming structured context about the new secret, its dependencies, and the rotation plan to produce a final risk assessment and a go/no-go recommendation for a human operator. It is not a general-purpose security chatbot and must not be used for generating secret values, making autonomous rotation decisions, or diagnosing system vulnerabilities.

The ideal invocation point is after a new secret version has been generated, validated for format compliance, and confirmed to be stored in the target secrets manager, but before any automation revokes the previous version. The required input context must include: a unique secret identifier, the rotation strategy (e.g., dual-publish with a synchronization window, immediate cutover), a list of dependent services that will consume the new secret, and the planned synchronization window. Without this structured context, the prompt cannot produce a reliable risk assessment. A typical implementation will feed this context from a rotation orchestrator into the prompt, receive a structured JSON summary, and then surface that summary in an internal approval tool (like Jira, ServiceNow, or a Slack bot) for an on-call engineer to explicitly approve or reject.

Do not use this prompt for low-risk, non-credential configuration changes or for secrets where an immediate, automated rollback is fully tested and safe. Its value is in creating a mandatory human checkpoint for high-impact rotations—such as database master credentials, payment API keys, or TLS private keys—where a failure could cause a widespread outage. The next step after reading this section is to review the prompt template and its required placeholders, then design the upstream harness that will assemble the [ROTATION_CONTEXT] and [DEPENDENCY_MAP] variables from your live infrastructure before invoking the model.

The prompt below is designed to be dropped into an AI harness that gates a secret rotation workflow. It forces the model to act as a strict summarizer, not an executor. The template uses square-bracket placeholders for all dynamic inputs, ensuring the prompt can be reused across different secret types, services, and rotation methods without modification. The output is a structured summary that includes the secret identifier, dependent services, rotation method, synchronization window, and a clear approval question.

textCopy
You are a security workflow assistant. Your only job is to generate a structured summary of a planned secret rotation for human approval. Do not execute any action. Do not generate, reveal, or suggest any secret values. Use only the information provided in the input context.

Generate a summary with the following sections:

1. SECRET IDENTIFIER: The name, path, or key ID of the secret to be rotated.
2. SECRET TYPE: The kind of secret (e.g., database credential, API key, TLS certificate, encryption key).
3. DEPENDENT SERVICES: A list of services, applications, or systems that use this secret and will need the new value.
4. ROTATION METHOD: How the new secret will be generated and distributed (e.g., automated vault rotation, manual generation, blue-green secret rollout).
5. SYNCHRONIZATION WINDOW: The time period during which both old and new secrets will be valid, and how the switchover will be coordinated.
6. REVOCATION PLAN: When and how the old secret will be revoked after the new secret is confirmed working.
7. ROLLBACK PROCEDURE: What to do if the rotation fails or dependent services cannot use the new secret.
8. RISK LEVEL: Low, Medium, High, or Critical, with a one-sentence justification.
9. APPROVAL QUESTION: A clear yes/no question for the approving security engineer.

INPUT CONTEXT:
- Secret Identifier: [SECRET_IDENTIFIER]
- Secret Type: [SECRET_TYPE]
- Dependent Services: [DEPENDENT_SERVICES]
- Rotation Method: [ROTATION_METHOD]
- Synchronization Window: [SYNCHRONIZATION_WINDOW]
- Revocation Plan: [REVOCATION_PLAN]
- Rollback Procedure: [ROLLBACK_PROCEDURE]
- Additional Notes: [ADDITIONAL_NOTES]

CONSTRAINTS:
- Do not invent information not present in the input context.
- If any required field is missing from the input context, mark it as [MISSING] and flag it for human attention.
- Do not generate, suggest, or include any secret values, tokens, or credentials.
- Keep the summary concise and factual. No speculation.
- If the risk level is not provided, infer it from the dependent services and rotation method, but note that it is inferred.

OUTPUT FORMAT:
Return the summary as plain text with the section headers exactly as listed above, followed by the content for each section.

To adapt this template for your environment, replace each [PLACEHOLDER] with data from your secret management system—such as HashiCorp Vault, AWS Secrets Manager, or your internal credential store. The [DEPENDENT_SERVICES] placeholder should include service names and their deployment regions or clusters. If your rotation workflow already has a risk scoring model, pass the computed score into [RISK_LEVEL] rather than asking the model to infer it. For high-risk rotations, add a [REQUIRED_APPROVERS] field and route the summary to multiple stakeholders before execution proceeds.

Before deploying this prompt into a production harness, validate that the output always contains all nine sections and that missing input fields are explicitly flagged rather than hallucinated. Test with edge cases: a secret with zero known dependent services, a rotation window of zero seconds, and a rollback procedure that references a runbook URL. If the model omits the [MISSING] flag or invents a plausible-sounding rollback, the prompt needs stronger constraints or a post-generation validator. Wire the output into an approval queue that blocks rotation until a human explicitly approves, and log the full summary alongside the approval decision for audit purposes.

This prompt is not a standalone chat interaction; it is a checkpoint inside a broader secret rotation pipeline. The harness must supply the prompt with a fully resolved [ROTATION_PLAN] that includes the new secret's existence proof, the dependent service inventory, and the proposed synchronization window. The model's job is to produce a human-readable summary and a structured approval decision, not to generate the rotation plan itself. Treat the prompt as a gate: the pipeline should halt before any revocation step until the approval output is received and validated.

Wire the prompt into an application by first assembling the [ROTATION_PLAN] from upstream systems—a secrets manager (e.g., Vault, AWS Secrets Manager), a service registry, and a deployment orchestrator. The plan must include: the secret identifier, a boolean flag confirming the new secret value exists and is validated, a list of dependent services with their expected update methods (e.g., environment variable reload, config map update), and the proposed synchronization window in minutes. Before calling the model, validate that the new secret exists by performing a read check against the secrets manager. If the check fails, abort the pipeline and alert the on-call rotation. After the model returns the summary and approval decision, parse the structured output and enforce a hard rule: if approval_decision is not approved, or if the risk_level is high without a documented override, block the rotation and route to a human review queue. Log the full prompt, response, and validation results to an audit system with a unique rotation ID for traceability.

For high-security environments, do not rely solely on the model's approval decision. Implement a multi-stage verification harness: (1) pre-prompt validation that the new secret exists and is distinct from the old secret, (2) post-prompt structured output parsing with schema validation, (3) a mandatory human-in-the-loop step for any rotation where risk_level is high or affected_service_count exceeds a configurable threshold, and (4) a post-rotation verification that the old secret has been revoked and dependent services are using the new secret without errors. Use a model with strong structured output support (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature to 0 to maximize consistency. The prompt's [OUTPUT_SCHEMA] should be enforced via the model's JSON mode or tool-calling API, and the harness must retry once with a repair prompt if the initial output fails schema validation. Avoid using this prompt for fully automated rotation without human approval unless the rotation is pre-classified as low-risk and the affected services have proven rollback mechanisms.