Secrets Rotation Verification Prompt

This prompt is designed for security engineers and platform operators who need to confirm that a recently rotated secret—such as an API key, database credential, or TLS certificate—has been fully propagated across all consumers in a live environment. The job-to-be-done is not to rotate the secret itself, but to produce a structured verification report that answers a single question: 'Is every service, pod, or function using the new secret, or are there stale references that will cause an outage when the old secret is revoked?' The ideal user has access to deployment manifests, runtime environment variables, mounted secret volumes, and logs, and needs a systematic, auditable check before deactivating the old secret.

Do not use this prompt when the secret value itself must be passed into the model context. The prompt is designed to work with secret references, version identifiers, or hashes—never the raw secret material. If your verification workflow requires comparing actual secret values, that comparison must happen in the application harness outside the model boundary. This prompt is also inappropriate for initial secret generation, for rotation orchestration, or for diagnosing why a rotation failed; those are separate workflows with different safety and context requirements. Use this prompt when you have a known rotation event and a list of consumers to check, and you need a structured pass/fail report with actionable stale-reference alerts.

Before using this prompt, gather the required inputs: the secret identifier, the expected new version or reference, a list of consumer locations (service names, pod identifiers, function names, or configuration paths), and the method by which each consumer should reference the secret (environment variable, mounted file, external secret store reference). The prompt will produce a verification report, but the real safety comes from the harness: never log or transmit raw secret values, run the verification in a controlled environment, and ensure any stale-reference alerts trigger a human-reviewed remediation workflow before the old secret is revoked. Proceed to the prompt template to see the exact input structure and output schema.

This template is designed to be copied directly into your AI harness or prompt management system. It accepts a structured input of target secrets, consumer services, and verification evidence, then produces a standardized verification report. The square-bracket placeholders represent variables your application must populate before sending the prompt to the model. Never hardcode secret values into the prompt itself—use reference identifiers and let your harness inject only the metadata required for verification.

textCopy
You are a secrets rotation verification analyst. Your task is to verify that rotated secrets have propagated correctly across all registered consumers and to identify any stale references.

## INPUT
[INPUT]

## CONSTRAINTS
- Never output raw secret values. Reference secrets by their identifier only.
- Flag any consumer that still references a previous secret version as STALE.
- Flag any consumer where verification evidence is missing or inconclusive as UNVERIFIED.
- If a consumer's expected secret version cannot be determined from the input, mark it as INDETERMINATE.
- Do not speculate about the cause of a stale reference. Report only what the evidence shows.
- If the input contains actual secret material, stop processing and respond with a SECURITY_BLOCK error.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "verification_summary": {
    "total_secrets_rotated": number,
    "total_consumers_checked": number,
    "consumers_verified": number,
    "consumers_stale": number,
    "consumers_unverified": number,
    "consumers_indeterminate": number,
    "overall_status": "PASS" | "FAIL" | "PARTIAL"
  },
  "findings": [
    {
      "secret_id": "string",
      "consumer_id": "string",
      "consumer_type": "service" | "pod" | "function" | "container" | "job" | "other",
      "expected_version": "string | null",
      "observed_version": "string | null",
      "status": "VERIFIED" | "STALE" | "UNVERIFIED" | "INDETERMINATE",
      "evidence_source": "string",
      "last_verified_at": "ISO8601 timestamp | null",
      "stale_duration_minutes": "number | null"
    }
  ],
  "alerts": [
    {
      "severity": "CRITICAL" | "HIGH" | "MEDIUM" | "LOW",
      "consumer_id": "string",
      "secret_id": "string",
      "message": "string"
    }
  ]
}

## VERIFICATION RULES
1. A consumer is VERIFIED when its observed secret version matches the expected rotated version and evidence is available.
2. A consumer is STALE when its observed version matches a previous version, not the current rotated version.
3. A consumer is UNVERIFIED when evidence is missing, inaccessible, or insufficient to determine the observed version.
4. A consumer is INDETERMINATE when the expected version for that consumer cannot be determined from the input.
5. Generate a CRITICAL alert for any STALE consumer that handles authentication, encryption, or API access.
6. Generate a HIGH alert for any STALE consumer that handles internal service communication.
7. Generate a MEDIUM alert for any UNVERIFIED consumer.
8. Generate a LOW alert for any INDETERMINATE consumer.
9. overall_status is PASS when all consumers are VERIFIED.
10. overall_status is FAIL when any consumer is STALE.
11. overall_status is PARTIAL when no consumers are STALE but some are UNVERIFIED or INDETERMINATE.

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace each placeholder with data from your secrets management system and infrastructure inventory. The [INPUT] placeholder should receive a structured JSON object containing the rotated secrets list, consumer registry, and any available verification evidence such as deployment logs, config snapshots, or health check results. The [EXAMPLES] placeholder can include one-shot or few-shot examples showing correct verification reports for common scenarios. The [RISK_LEVEL] placeholder should be set to "HIGH" when verifying secrets for production authentication systems, "MEDIUM" for internal service secrets, or "LOW" for non-sensitive configuration. If your harness cannot safely construct the input without exposing raw secret values, redesign the data pipeline before using this prompt.

Before deploying this prompt, validate that your harness strips all secret material and passes only identifiers and metadata. Run eval suites with synthetic consumer registries containing known stale references to confirm the model correctly classifies each status. In production, log every verification report and route any FAIL result to the on-call rotation immediately. Never use this prompt's output to automatically rotate secrets—it is a detection tool, not a remediation tool.

Wiring this prompt into an application requires treating the prompt's input and output as a security boundary. The prompt expects a list of service identifiers, their expected secret versions, and a verification timestamp. Never pass raw secret values into the prompt context. Instead, your application harness should resolve secret references to version identifiers or fingerprints (e.g., secret:prod-db-creds:v4) before populating the [SERVICE_SECRET_MAP] placeholder. The harness should also inject a [VERIFICATION_TIMESTAMP] to anchor the report and a [CONSTRAINTS] block specifying the allowed staleness window and any services excluded from rotation.

The application should implement a pre-prompt validation layer that rejects any input containing strings matching known secret patterns (e.g., private keys, connection strings, tokens). Use a regex allowlist for the [SERVICE_SECRET_MAP] structure. After the model returns the verification report, a post-prompt validation step must parse the structured output (preferably JSON) and check that every service in the input map appears in the report with a status of ROTATED, STALE, or UNKNOWN. Any service missing from the report should trigger a retry with a more explicit instruction. For high-security environments, route all STALE findings to a human approval queue before automated alerts are sent.

Choose a model with strong structured output capabilities and low latency for this workflow, as it often runs in deployment pipelines or scheduled verification jobs. Implement a retry strategy with exponential backoff (max 3 attempts) for malformed outputs or validation failures. Log every prompt invocation, the resolved service map (with secret values redacted), the raw model output, and the validation result to an audit trail. For production use, pair this prompt with a tool that can query a secrets manager API to confirm the current active version, allowing the model to cross-reference its analysis against live state. Never allow the model to directly call rotation or revocation endpoints—those actions must remain in the application layer with explicit human approval for any destructive changes.