Secrets Rotation Approval Prompt for DevOps Agents

This prompt is designed for security engineering and DevOps teams building AI agents that automate credential lifecycle management. Use it when your agent identifies a secret due for rotation and must generate a structured approval request for a human operator before executing the rotation. The prompt forces the agent to compile the secret identifier, affected services, rotation window, dependent system impact, verification steps, and rollback secret availability into a single, auditable payload. It is appropriate for workflows involving API keys, TLS certificates, database credentials, and IAM access keys where an unauthorized or poorly timed rotation could cause an outage.

Before wiring this prompt into your agent, verify that your system has access to the following concrete inputs: a unique secret identifier from your secrets manager, a current list of services consuming that secret from your service discovery or configuration store, a maintenance window schedule, and a rollback secret (the previous valid credential) that can be restored if rotation fails. The prompt template uses square-bracket placeholders for these fields—your application code must populate them before the model call. If your agent cannot resolve all required fields, the workflow should abort and escalate to a human with a missing-information interruption rather than generating an incomplete approval request. Do not use this prompt for low-risk, non-production secrets or fully autonomous rotation pipelines where human approval is not required. For those cases, a silent rotation with automated verification is more appropriate.

The primary failure mode to watch for is an agent that generates a plausible-looking approval request despite missing critical impact analysis. Your eval suite should include test cases where the [AFFECTED_SERVICES] list is empty, where [ROLLBACK_SECRET_AVAILABLE] is false, and where the rotation window falls outside approved maintenance hours. In each case, the expected behavior is that the prompt produces a blocking condition in the output rather than a routine approval request. After reading this section, proceed to the prompt template to copy the exact instructions, then review the implementation harness for validation and retry logic before deploying to production.

This prompt template is designed to be pasted directly into your DevOps agent's system instructions or a tool-calling layer. It forces the agent to act as a security-aware gatekeeper, not an autonomous executor. Before any rotation proceeds, the agent must produce a complete approval payload that a human can review. The template uses square-bracket placeholders for variables that your application should inject at runtime from a secrets management system (e.g., HashiCorp Vault), a service registry, and a deployment scheduler.

textCopy
You are a DevOps security agent responsible for preparing secrets rotation approval requests. You do not execute rotations. Your only job is to generate a complete, structured approval payload for a human operator.

When asked to prepare a rotation for [SECRET_IDENTIFIER], perform the following steps:

1. Retrieve the secret's metadata from the [SECRETS_MANAGEMENT_SYSTEM].
2. Query the [SERVICE_REGISTRY] to identify every service with a direct or transitive dependency on [SECRET_IDENTIFIER].
3. Consult the [DEPLOYMENT_SCHEDULER] to find the next available maintenance window for the affected services that is at least [MIN_ADVANCE_NOTICE_HOURS] hours from now.
4. Generate a rollback secret value and confirm it is stored and accessible in [SECRETS_MANAGEMENT_SYSTEM] under the identifier [ROLLBACK_SECRET_IDENTIFIER].
5. If any service dependency is unknown, the impact cannot be fully assessed, or a rollback secret cannot be verified, you MUST set the `approval_blocking_issues` field and recommend against proceeding.

Your final output must be a single JSON object conforming to this schema:
{
  "secret_identifier": "string",
  "rotation_window": {
    "start_time": "ISO 8601 datetime",
    "end_time": "ISO 8601 datetime"
  },
  "affected_services": [
    {
      "service_name": "string",
      "dependency_type": "direct | transitive",
      "expected_impact": "string describing the effect during rotation"
    }
  ],
  "verification_steps": ["ordered list of post-rotation validation commands"],
  "rollback_secret_available": true,
  "approval_blocking_issues": ["list of reasons to deny approval, empty if none"],
  "recommendation": "PROCEED | HOLD"
}

[CONSTRAINTS]
- Never output a recommendation of "PROCEED" if `approval_blocking_issues` is not empty.
- If the [RISK_LEVEL] for the secret is "HIGH" or "CRITICAL", the `verification_steps` must include a manual confirmation step by a second human.
- Do not include the secret value or the rollback secret value in the output.

To adapt this template, replace the bracketed placeholders with data from your live infrastructure. [SECRET_IDENTIFIER] should be populated from the triggering event. [SECRETS_MANAGEMENT_SYSTEM], [SERVICE_REGISTRY], and [DEPLOYMENT_SCHEDULER] should be replaced with the specific tool names and API endpoints your agent is authorized to call. [MIN_ADVANCE_NOTICE_HOURS] and [RISK_LEVEL] should be injected from your organization's security policy configuration. The output schema is a contract; your application layer should parse this JSON and route it to a human review queue if recommendation is "PROCEED" or block execution entirely if it is "HOLD". Before deploying, test this prompt against edge cases such as a secret with zero known dependents or a missing rollback secret to ensure the approval_blocking_issues logic triggers correctly.

This prompt is a gate, not a notification. It must be wired into a workflow where the agent cannot proceed to the rotation step until it receives a structured, validated approval. The harness should call the LLM to generate the approval request, validate the output against a strict schema, present it to a human reviewer through a ticketing or chat-ops interface, parse the human's decision, and only then invoke the secrets rotation tool. The prompt itself is stateless; the harness owns the state machine that transitions from PLANNING to AWAITING_APPROVAL to EXECUTING or REJECTED.

Start by defining the output schema in code, not just in the prompt. Use a typed object (e.g., a Pydantic model or JSON Schema) with required fields: secret_identifier, rotation_window_utc, affected_services (array of objects with service_name and impact_description), dependent_systems, verification_steps (array of strings), rollback_secret_available (boolean), and risk_classification (enum: LOW, MEDIUM, HIGH). After the LLM generates the payload, run a validator that rejects the output if rollback_secret_available is false without an explicit HIGH risk classification, or if affected_services is empty. If validation fails, retry once with the validation errors injected into [CONSTRAINTS]. If the second attempt also fails, escalate to a human operator with the raw output and error log—do not loop indefinitely.

For the human review step, render the validated payload into a concise approval card in Slack, PagerDuty, or a custom internal tool. The card must include: the secret name, the rotation window, a bulleted list of affected services with impact, the verification steps, and a clear Approve / Reject button. Log the full payload, the reviewer's identity, and the timestamp to an audit table before executing the rotation. After execution, run the verification steps as automated checks (e.g., curl health endpoints, check dependent service logs for auth errors) and log the results. If any verification step fails, trigger the rollback procedure immediately and page the on-call. Never allow the agent to mark a rotation as successful without passing all verification checks. The prompt is the approval language; the harness is the safety envelope.