Secret Rotation Audit Trail Prompt

This prompt is for security engineers and platform teams who need to convert unstructured or semi-structured reports of secret rotations into a strict, machine-readable audit trail. It takes a natural-language description of a rotation event—such as a ticket comment, a chat message, or a runbook note—and produces a JSON record with a validated secret identifier, rotation trigger classification, old version hash, and new version timestamp. The primary job-to-be-done is bridging the gap between human-reported operational actions and the structured logging required by credential management systems, vaults, or SIEM platforms. Use this when your compliance database, alerting system, or immutable audit log demands a consistent schema for every rotation event but the source data arrives in free-form text.

This prompt belongs in a pipeline where the output feeds directly into a downstream system of record. The ideal user is a platform engineer building an internal tool that ingests rotation notices from Slack, Jira, or email and normalizes them before writing to an audit store. Before using this prompt, you must have the raw text of the rotation report and a clear definition of the expected output schema, including the hash algorithm for the old version and the timestamp format for the new version. The prompt is designed to enforce field-level validation: it classifies the rotation trigger into a controlled vocabulary (e.g., scheduled, emergency, compromise_response), validates that the old version hash matches a hex or base64 pattern, and ensures the new version timestamp is ISO 8601. If the input text is ambiguous or missing required fields, the prompt should be configured to return a structured error object rather than hallucinating values, and the calling application must handle that error path with a retry or human escalation.

Do not use this prompt for non-credential events, general-purpose logging, or scenarios where the source data is already structured. It is not a replacement for a SIEM agent or a vault's native API. Avoid using it in high-throughput streaming contexts without batching and cost controls, as each invocation requires a full model call. The next step after reading this section is to review the prompt template and implementation harness to understand how to wire it into an application with proper validation, retries, and human review for high-risk rotation triggers like compromise_response.

This prompt template generates a structured audit trail record for a secret rotation event. It is designed for security engineers who need to feed credential lifecycle events into compliance systems, SIEM pipelines, or audit databases. The template enforces strict field-level validation, including SHA-256 hash format verification and controlled vocabulary for rotation triggers. Before using this prompt, ensure you have the secret identifier, the old credential hash, the rotation trigger reason, and the actor identity available. Do not use this prompt for real-time rotation execution—it is an audit recording tool, not a rotation orchestrator.

textCopy
You are an audit record generator for a secret rotation system. Your task is to produce a single, valid JSON object that documents a secret rotation event. Follow these rules exactly.

## INPUT
- Secret Identifier: [SECRET_ID]
- Old Version Hash (SHA-256): [OLD_HASH]
- Rotation Trigger: [ROTATION_TRIGGER]
- Rotated By (Actor): [ACTOR_IDENTITY]
- Rotation Timestamp: [ROTATION_TIMESTAMP]
- New Version Timestamp: [NEW_VERSION_TIMESTAMP]
- Additional Context: [ADDITIONAL_CONTEXT]

## OUTPUT SCHEMA
Return ONLY a valid JSON object with these exact fields:
{
  "audit_record_id": "string, UUID v4 format",
  "event_type": "secret.rotation",
  "secret_identifier": "string, the provided [SECRET_ID]",
  "old_version_hash": "string, must match regex ^[a-fA-F0-9]{64}$",
  "new_version_timestamp": "string, ISO 8601 format in UTC",
  "rotation_trigger": "string, one of: scheduled, emergency, compromise, manual, key_expiry, policy_change",
  "rotated_by": "string, the provided [ACTOR_IDENTITY]",
  "rotation_timestamp": "string, ISO 8601 format in UTC",
  "additional_context": "string or null, the provided [ADDITIONAL_CONTEXT]",
  "compliance_tags": ["array of strings, relevant compliance frameworks like SOX, SOC2, HIPAA, PCI-DSS, or empty array"]
}

## CONSTRAINTS
1. The `old_version_hash` field MUST be a 64-character hexadecimal string. If the provided [OLD_HASH] does not match this format, set the field to null and add a warning to `additional_context`.
2. The `rotation_trigger` field MUST be one of the enumerated values. If the provided [ROTATION_TRIGGER] does not match any allowed value, classify it as "manual" and note the original value in `additional_context`.
3. All timestamps MUST be in ISO 8601 UTC format (e.g., "2025-01-15T14:30:00Z"). If the provided timestamps are not in this format, convert them.
4. Generate a new UUID v4 for `audit_record_id` on every invocation.
5. Do not include any text outside the JSON object. No markdown fences, no explanations.

## EXAMPLES
Example Input:
[SECRET_ID]: "prod-db-main-credential"
[OLD_HASH]: "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2"
[ROTATION_TRIGGER]: "key_expiry"
[ACTOR_IDENTITY]: "automated-rotation-service"
[ROTATION_TIMESTAMP]: "2025-01-15T14:30:00Z"
[NEW_VERSION_TIMESTAMP]: "2025-01-15T14:30:00Z"
[ADDITIONAL_CONTEXT]: "Scheduled rotation per key expiry policy"

Example Output:
{"audit_record_id":"550e8400-e29b-41d4-a716-446655440000","event_type":"secret.rotation","secret_identifier":"prod-db-main-credential","old_version_hash":"a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2","new_version_timestamp":"2025-01-15T14:30:00Z","rotation_trigger":"key_expiry","rotated_by":"automated-rotation-service","rotation_timestamp":"2025-01-15T14:30:00Z","additional_context":"Scheduled rotation per key expiry policy","compliance_tags":["SOX","SOC2"]}

## RISK LEVEL
HIGH. This prompt generates audit records that may be used for compliance evidence. Always validate the output against the schema before persisting. Human review is required for records with `rotation_trigger` set to "compromise" or where `old_version_hash` is null.

To adapt this prompt for your environment, replace the square-bracket placeholders with real values from your secret management system—such as HashiCorp Vault, AWS Secrets Manager, or your internal credential store. The compliance_tags field should be populated based on your organization's regulatory obligations; you can hardcode a default set or pass them as an additional input. If your system uses a hash algorithm other than SHA-256, update the regex constraint in the old_version_hash field description and the validation logic accordingly. For production use, always run the output through a JSON Schema validator before writing to your audit store, and log any records where the model deviated from the enumerated rotation_trigger values.

This prompt is designed to be a component in a larger secret rotation pipeline, not a standalone chatbot. The primary integration point is a secure backend service that orchestrates the rotation of credentials for databases, API keys, or service accounts. After a rotation event is completed by your automation (e.g., a Kubernetes CronJob or a HashiCorp Vault script), the service should call the LLM with this prompt to generate a structured, machine-readable audit record. The LLM's output is then validated and directly inserted into your immutable audit log, such as a dedicated PostgreSQL table, an S3 bucket with object lock, or a SIEM system.

To implement this, wrap the prompt in a function with a strict contract. The function generate_rotation_audit_record should accept the required inputs: secret_identifier, rotation_trigger, old_version_hash, and new_version_timestamp. The function's first step is to validate these inputs before they reach the prompt. Check that old_version_hash matches the expected SHA-256 hex format (^[a-f0-9]{64}$) and that rotation_trigger is one of the allowed enum values (SCHEDULED, MANUAL, COMPROMISED, LEAKED). If validation fails, reject the request immediately and log a high-severity alert; do not call the LLM with invalid data. On success, populate the prompt template and make the API call with a low temperature setting (0.0-0.1) to maximize format reliability. The model's response must be parsed as JSON. If parsing fails, implement a single retry with a re-prompt that includes the raw output and a strict instruction to return only valid JSON. If the retry also fails, the system must escalate to an on-call engineer and write a raw failure event to the audit log, ensuring no rotation event is ever silent.

For high-assurance environments, the implementation must include a human review step for sensitive triggers. If rotation_trigger is COMPROMISED or LEAKED, the generated audit record should be placed in a review queue instead of being written directly to the immutable log. A security engineer must verify the record's accuracy, particularly the old_version_hash and the classification of the trigger, before approving its finalization. This prevents an automated system from creating a misleading audit trail for the most critical security events. The final step is to log the validated and approved record to your system of record, attaching the unique trace_id generated at the start of the workflow to link the rotation event, the LLM call, and the human review into a single, queryable chain of custody.