Configuration Secret Rotation Architecture Prompt

This prompt is for security engineers and platform architects who need a structured, rigorous review of a secret rotation design before it reaches production. The job-to-be-done is preventing downtime, data corruption, and security incidents caused by credential rotation failures. Use it when you have a concrete design artifact—an architecture diagram, a technical design document, or a detailed implementation proposal—that describes how API keys, database credentials, TLS certificates, or other secrets will be rotated without interrupting live traffic. The prompt forces the reviewer (or an AI acting as a review assistant) to systematically examine rotation triggers, dual-credential windows, client reload behavior, and failure recovery paths, producing a gap analysis rather than a generic security checklist.

The ideal user brings a specific design to the table. You should have already mapped out the rotation flow, identified the secret store (e.g., HashiCorp Vault, AWS Secrets Manager), and defined the clients that consume these secrets. The prompt is most effective when you can describe the mechanism: Is rotation time-based or event-driven? How long does the system accept both old and new credentials? How are clients signaled to reload? What happens if the secret store is unreachable mid-rotation? Without this level of detail, the prompt will produce vague questions instead of actionable findings. Do not use this prompt for a general security posture review, for auditing a live system's current state without a design document, or as a substitute for penetration testing, secret store configuration review, or runtime incident response procedures.

There are clear boundaries where this prompt should not be applied. It does not evaluate the cryptographic strength of secrets, the network security of the secret store, or the IAM policies governing access to secrets. It does not simulate rotation under load or validate the actual behavior of client libraries. The prompt is a design-time architecture review tool, not a runtime testing tool. If your goal is to test a live rotation, you need a chaos engineering experiment with synthetic traffic and observability dashboards. If your goal is to verify that secrets are stored securely at rest, you need a configuration audit of your secret store. Use this prompt as a gate in your security architecture review process before implementation begins, or as a structured way to pressure-test an existing rotation design during an audit. After completing the review, the next step is to address the identified gaps, then move to implementation and runtime validation with actual rotation dry-runs in a staging environment.

This prompt template is designed to be copied directly into your AI harness, IDE, or orchestration layer. It instructs the model to act as a security architecture reviewer, analyzing a provided secret rotation design against a strict set of criteria. The prompt uses square-bracket placeholders for all dynamic inputs, ensuring you can adapt it to your specific system design documents, internal policies, and output format requirements without modifying the core instruction set.

textCopy
You are a principal security architect reviewing a configuration secret rotation architecture for a production system. Your goal is to identify gaps that could cause downtime, security breaches, or operational failures during credential rotation.

Review the following architecture description against the criteria below. For each finding, provide a severity rating (CRITICAL, HIGH, MEDIUM, LOW), a clear explanation of the gap, and an actionable recommendation.

ARCHITECTURE DESCRIPTION:
[ARCHITECTURE_DESCRIPTION]

REVIEW CRITERIA:
1. Rotation Triggers: Are the events that initiate a rotation (e.g., time-based, event-driven, manual) clearly defined, reliable, and free of race conditions?
2. Dual-Credential Windows: Does the design support overlapping validity periods for old and new credentials to prevent authentication failures during propagation?
3. Client Reload Behavior: How do consuming clients discover and load new credentials? Is the reload mechanism atomic, and does it handle partial failures gracefully?
4. Failure Recovery: What happens when a rotation step fails? Are there explicit rollback procedures, retry logic with backoff, and idempotency guarantees?
5. Rotation Atomicity: Is the rotation process transactional across the secret store and all configuration injection points? Can a partial rotation leave the system in an inconsistent state?
6. Secret Store Integration: How does the system interact with the backing secret store (e.g., HashiCorp Vault, AWS Secrets Manager)? Are there issues with rate limiting, authentication to the store, or secret versioning?

OUTPUT FORMAT:
[OUTPUT_SCHEMA]

CONSTRAINTS:
[CONSTRAINTS]

To adapt this template, replace the placeholders with your specific context. [ARCHITECTURE_DESCRIPTION] should contain the full text, diagrams (described in text), and configuration snippets of the system under review. [OUTPUT_SCHEMA] should define the exact JSON or Markdown structure you want the findings in, such as a JSON array of objects with finding_id, criterion, severity, description, and recommendation fields. [CONSTRAINTS] is where you add rules like "Ignore the use of TLS 1.2 as it is a known, accepted risk" or "Focus only on the control plane, not the data plane." After copying, run the prompt with a known-good architecture to calibrate its sensitivity before using it on a new design.

This prompt is designed to operate as a gated design review step before rotation logic is committed to code or applied to infrastructure. It should not be called in an unattended automation loop that directly modifies secrets or rotation schedules. Instead, integrate it into a pull-request workflow, a security architecture review queue, or a pre-deployment checklist where a human engineer provides the design description and receives a structured critique. The prompt expects a detailed textual description of the proposed rotation architecture as its primary input, along with optional context about the secret store, client libraries, and deployment environment.

Wire the prompt into an application by building a thin API wrapper or CLI tool that accepts the design description, injects it into the [DESIGN_DESCRIPTION] placeholder, and calls your LLM provider. Validation is critical: parse the model's output against the expected JSON schema (fields like rotation_triggers, dual_credential_window, client_reload_behavior, failure_recovery, gaps, and risk_score). If parsing fails, retry once with a stricter schema instruction appended to the prompt. Log every invocation—including the input design, raw output, parsed JSON, and validator result—to an append-only audit store. For high-risk systems (e.g., production database credentials, payment API keys), require a human to approve the review findings before the rotation design is accepted. The human approval step should be enforced by your pipeline, not just suggested by the prompt.

Model choice matters: use a model with strong reasoning and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) because the task requires multi-step analysis of failure modes and dependency chains. Avoid small or fast models that may miss subtle race conditions. If your secret store has a documented API or configuration schema, consider providing it as part of [CONTEXT] to ground the analysis in real constraints. Do not pass live secrets or connection strings to the model. Tool use is generally unnecessary for this prompt, but you may extend the harness to call internal APIs that fetch the current rotation policy or client library documentation and inject that as additional context before invoking the prompt. The output should be stored alongside the design document in your architecture decision record system, creating a traceable link between the proposed design and its security review.

What to avoid: Do not use this prompt as a substitute for actually testing the rotation in a staging environment. The prompt identifies design-level gaps, not runtime bugs. Do not feed it partial or vague descriptions and expect a thorough review—garbage in, garbage out applies. Finally, do not skip the human approval gate for secrets that protect production data or infrastructure; the model can miss novel attack vectors or organization-specific compliance requirements that a trained security engineer would catch.