Credential Rotation Without Touching 1Password — Agent Handles the Keys

The Problem

I have 31 agents. They use API keys for GitLab, Twitter, Gemini, Stripe, Notion, and a dozen other services. Each key needs rotation. Industry best practice says every 90 days. Reality says I rotated them when something broke — which means some keys were 6 months old. Some were older.

Manual credential rotation is a five-step nightmare:

1. Log into the service. Navigate to API settings.
2. Generate new key. Copy it.
3. Open 1Password. Find the entry. Update it.
4. Find every config file or environment variable that uses the old key. Update them.
5. Verify nothing broke.

Per key: 5-10 minutes. With 20+ keys to rotate quarterly, that's a full afternoon of mind-numbing work. So it doesn't happen. The keys age. The risk compounds.

The security implications are obvious. A leaked 6-month-old key gives an attacker 6 months of valid access. A leaked 30-day-old key gives them 30 days. Rotation limits blast radius. But only if it actually happens.

The Solution

Alfrawd manages the full rotation lifecycle. Generate → store → deploy → verify. On schedule. Every 90 days. No human in the loop except for the audit report.

The agent reads from 1Password, writes to 1Password, and never — ever — logs the secret value. The plaintext exists in memory for the duration of the rotation, then it's gone.

The Process

The 1Password CLI (op) is configured on the gateway. The agent orchestrates:

# Step 1: Generate new API key from the service
NEW_KEY=$(curl -s -X POST "https://api.service.com/keys" \
  -H "Authorization: Bearer $(op read 'op://Vault/Service/api-key')" \
  | jq -r '.new_key')

# Step 2: Store in 1Password (overwrites old value)
op item edit "Service API Key" \
  "api-key=$NEW_KEY" \
  --vault "Agent Credentials"

# Step 3: Update service config
# (agent updates env vars or config files, never echoing the key)
op read 'op://Agent Credentials/Service API Key/api-key' \
  | xargs -I {} sed -i "s/SERVICE_API_KEY=.*/SERVICE_API_KEY={}/" .env

# Step 4: Verify the new key works
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer $(op read 'op://Agent Credentials/Service API Key/api-key')" \
  "https://api.service.com/verify"
# Returns 200 → rotation successful

The scheduled rotation runs as a cron job:

# Credential rotation schedule
rotation:
  - name: "GitLab PAT"
    vault: "Agent Credentials"
    interval: 90d
    last_rotated: 2026-01-12
    next_rotation: 2026-04-12

  - name: "Twitter Bearer"
    vault: "Agent Credentials"
    interval: 90d
    last_rotated: 2026-02-01
    next_rotation: 2026-05-02

  - name: "Gemini API Key"
    vault: "Agent Credentials"
    interval: 90d
    last_rotated: 2026-02-15
    next_rotation: 2026-05-16

The audit report I can pull anytime:

Me: which credentials are older than 60 days?

Alfrawd: Credential age report:

| Credential      | Age    | Last Rotated | Next Due   | Status  |
|----------------|--------|--------------|------------|---------|
| GitLab PAT     | 61 days | 2026-01-12  | 2026-04-12 | ⚠️ Aging |
| Stripe Secret  | 45 days | 2026-01-27  | 2026-04-27 | ✅ OK   |
| Twitter Bearer | 40 days | 2026-02-01  | 2026-05-02 | ✅ OK   |
| Gemini Key     | 26 days | 2026-02-15  | 2026-05-16 | ✅ OK   |
| Notion Token   | 72 days | 2025-12-31  | 2026-03-31 | ⚠️ Aging |

Action: 2 credentials approaching rotation window.
Shall I rotate GitLab PAT and Notion Token now?

The Results

The plaintext exposure metric matters more than people think. Every time you copy-paste an API key, it sits in your clipboard. It might appear in terminal history. It might get accidentally committed. The agent avoids all of these vectors — the key goes from 1Password to config and nowhere else.

Try It Yourself

1. Install the 1Password CLI and configure service accounts
2. Create a rotation schedule YAML with all credentials and intervals
3. Set up cron jobs for automated rotation on schedule
4. Run monthly audit reports: "show credential ages"

Start with your most sensitive keys. Expand once you trust the process. The agent should never have permission to read credentials it doesn't need to rotate.

The most secure credential is the one that expires before anyone can abuse it. Automate the clock.