Feature request: automated credential lifecycle — provision, rotate, validate, store

[ameet]

Problem

One CLI makes it easy to use 250+ platform APIs once connected. But the credential lifecycle around those connections is entirely manual:

1. Provision — Go to each platform's settings page, find the API section, create a key, copy it, paste it into one add
2. Rotate — Remember which keys are stale, go back to each platform, create new key, update the connection, revoke the old one
3. Validate — No way to know if a stored credential is still valid until an action fails
4. Store — Keys end up in various places (env vars, .secrets/ files, clipboard history) with no unified secure storage

This is manageable with 3-5 connections. At 15+, it becomes a real operational burden. At 50+ (where power users are headed), it's untenable.

Current workarounds

• Manual key rotation on a calendar reminder (often forgotten)
• Keys stored in plaintext files (~/.secrets/platform/api-key.txt)
• No validation until runtime failure — stale keys surface as mysterious action errors
• Each new platform requires a unique sign-up-and-configure flow that can't be automated

Proposed solution: `one credentials` command group

A credential lifecycle manager integrated into One CLI:

```bash

Check health of all stored credentials

one credentials validate # Tests each connection, reports stale/expired/valid

Rotate a credential

one credentials rotate # Provisions new key, updates connection, revokes old

Provision a new credential (interactive or automated)

one credentials provision # Guided setup with secure storage

Import from a secret manager

one credentials import --from 1password # Pull credentials from 1Password/Doppler/etc.
one credentials import --from env # Pull from environment variables
one credentials import --from dotenv .env # Pull from .env file
```

Implementation approaches (not mutually exclusive)

Tier 1 — Validate + alert (simplest, highest value)

• `one credentials validate` calls a lightweight endpoint per connection (e.g., "whoami" or "list" with limit=1)
• Reports: valid, expired, rate-limited, revoked, unknown
• Could run on a schedule: `one credentials validate --schedule daily`
• This alone would prevent the "action failed because the key expired 3 weeks ago" problem

Tier 2 — Secret manager integration

• Import/export credentials from 1Password CLI (`op`), Doppler, AWS Secrets Manager, or Bitwarden CLI
• `one credentials import --from 1password --vault "API Keys"` scans vault items tagged with platform names, matches to One CLI connections
• Credentials stay in the secret manager as source of truth; One CLI reads them at execution time
• This solves secure storage without One CLI needing to build its own vault

Tier 3 — Automated provisioning via browser automation

• For platforms that don't have API-based key management (most don't), use a browser automation layer to:
  • Navigate to the platform's API settings page
  • Create a new API key
  • Copy the key and configure it in One CLI
  • Optionally revoke the old key
• This could integrate with services like Deck.co (computer-use agents for browser automation) or similar tools
• User provides platform credentials (username/password or SSO) once; the automation handles key creation
• This is the "zero-touch provisioning" path — `one credentials provision stripe` handles everything

Tier 4 — Automated rotation

• Combine Tier 1 (validation) + Tier 3 (provisioning) into scheduled rotation
• `one credentials rotate --schedule monthly` automatically provisions new key, updates connection, revokes old
• Rotation policy per platform (some keys expire, some don't, some require manual approval)

Why this matters beyond convenience

1. Security — Stale, forgotten API keys are a top-3 credential security risk. Automated rotation is a security feature, not just convenience.
2. Onboarding — The biggest friction in One CLI adoption is connecting platforms. Reducing `one add` from "go find your API key" to "authenticate and we'll handle it" dramatically lowers the barrier.
3. Scale — Power users connecting 20+ platforms need lifecycle management, not just a key-value store.
4. Trust — `one credentials validate` gives users confidence that their connections are healthy without running a real action to find out.

Prior art

• Terraform has provider authentication management but no rotation
• Doppler/Infisical solve secret storage but not provisioning
• 1Password CLI (`op`) handles storage and retrieval but not platform-specific provisioning
• No existing tool combines validate + provision + rotate + store in a platform-aware way

Smallest useful increment

Start with `one credentials validate` — it's the highest-value, lowest-complexity piece. Just test each connection and report health. Everything else builds on that foundation.