Credential Rotation Readiness Playbook

What You Will Learn

• If required catalogs are missing, ask the agent to import them and verify auth headers first.
• Run read-only credential inventory and usage checks by provider.
• Identify stale, unused, or high-risk credentials and map blast radius.
• Generate a phased rotation plan with explicit verification gates.
• Separate readiness assessment from mutation steps.

Purpose

Use this playbook to determine if your environment is ready for safe credential rotation without making any changes.

If required provider catalogs or mandatory auth headers are not yet configured, begin with an import-and-verify step before running readiness prompts.

Use it for quarterly security hygiene reviews, pre-rotation planning, and incident-driven key compromise response.

tip For manual header verification or updates, use `/docs/learn/library-and-catalogs#headers-management`.

tip For execution safeguards and approval flow, use `/docs/learn/how-oatty-executes-safely` and `/docs/learn/workflows-basics`.

Validated Read-Only Signals

Representative rotation-readiness signals available through Oatty command catalogs:

Datadog API keys: `datadog api_keys:list` (includes last-used metadata).

Datadog application keys: `datadog current_user:application_keys:list` (includes last-used timestamps).

AWS IAM credential report: `aws #Action=GetCredentialReport:list` (account-wide credential age/status, when auth is configured).

AWS IAM access keys: `aws #Action=ListAccessKeys:list` (principal key inventory, when auth is configured).

GitHub SSH/GPG keys: `github user:keys:list`, `github user:gpg_keys:list` (requires authenticated user context).

expected These read-only signals are sufficient to produce a practical readiness report and a phased rotation plan before any write actions.

How to Use This Guide (Goal-Oriented, NL-First)

Describe the rotation goal, systems in scope, and time constraints. Let the agent discover exact commands for your environment.

If provider catalogs are missing, have the agent import them first and verify required headers before collecting evidence.

Keep this phase read-only: inventory credentials, map usage and owners, and highlight rotation blockers.

Require outputs in a normalized schema so readiness can be compared across runs.

tip If you need a command-discovery refresher, see `/docs/learn/search-and-run-commands`.

Prompt Patterns: Prompt -> Expected Agent Actions

Use these patterns to run a consistent readiness assessment before rotating credentials.

Pattern 1: Credential Inventory (Read-Only)

Start by listing all relevant credential objects and their owners.

Prompt:
Run a read-only credential inventory for GitHub, AWS IAM, and Datadog. If a required catalog is missing, import it first and verify required headers. Return keys/tokens by owner with creation time, last-used time, and status.

expected Expected agent actions: import missing catalogs when needed, verify required headers, collect credential inventories per provider, normalize fields, and return counts plus owner mapping.

Pattern 2: Risk Classification

Classify stale or risky credentials before proposing rotation sequence.

Prompt:
Classify credentials into risk tiers (unused, stale, high privilege, unknown owner). Show evidence for each classification and keep this read-only.

expected Expected agent actions: apply risk rules to inventory signals, flag high-priority credentials, and include confidence notes where data is incomplete.

Pattern 3: Blast Radius and Dependency Mapping

Map operational impact before any key/token change is attempted.

Prompt:
For each high-risk credential, estimate blast radius: dependent services, automation paths, and likely failure impact if revoked. Keep it evidence-based and read-only.

expected Expected agent actions: map dependencies and affected systems, identify unknown ownership, and separate confirmed dependencies from inferred ones.

Pattern 4: Phased Rotation Plan

Generate a no-surprises plan with verification and rollback gates.

Prompt:
Draft a phased rotation plan (prepare, rotate, verify, revoke-old) with approval gates, rollback steps, and success criteria for each provider. Do not execute changes.

expected Expected agent actions: produce an ordered, low-risk rotation plan with per-phase checks and a clear operator approval model.

Pattern 5: Read-Only Executive Summary

Use this for leadership review before scheduling rotation windows.

Prompt:
Provide an executive readiness summary: current risk posture, top blockers, phased rotation recommendation, and unresolved unknowns. Keep this read-only.

expected Expected agent actions: summarize key risks, readiness level, and immediate next actions with owners and priority.

Recommended Output Schema

Use a fixed structure for auditability and comparison over time:

1) `scope` (providers, credential types, time window).

2) `credential_inventory` (object, owner, age, last_used, status).

3) `risk_classification` (tier, reason, confidence).

4) `blast_radius` (dependencies, impact, unknowns).

5) `rotation_plan` (phases, gates, rollback).

6) `open_questions` (missing evidence and owner follow-ups).

tip Redact sensitive values and include only identifiers needed for operator action.

Next Steps

After readiness is approved, run rotation in a separate write-enabled workflow with explicit pause points.

Export readiness outputs and plan artifacts into repository docs for quarterly evidence and change review.

tip Use `/docs/learn/workflows-basics` to review and run staged workflows with clear approval gates.