Rotate stored credentials

Swap a storage connection's secret in place - no re-registration, tables and sharing untouched.

Rotate a storage configuration's stored credential in place. The config keeps its ID, name, discovery settings, workspace ownership, and every registered table - only the secret changes. Other holders of a shared config are cut over immediately.

Before you start

  • Requires storage:configure; a workspace-owned config additionally requires storage_configs:share (Builder or Admin).
  • The new credential must be for the same provider as the config - you can't rotate an S3 config with Azure fields.
  • Have the replacement secret ready. Rotation validates nothing until the next storage access, so a wrong secret surfaces as probe-style failures on the next query.

Rotate

# prompted on stdin (preferred - flags leak into shell history)
eddytor set storage-credentials <config-id> --provider s3

# or pass fields explicitly
eddytor set storage-credentials <config-id> --provider az \
  --client-id "$CLIENT_ID" --client-secret "$CLIENT_SECRET" --tenant-id "$TENANT_ID"

Omitted secrets are prompted on stdin; the prompt goes to stderr so piped stdout stays clean.

PUT /v1/storages/configs/{config_id}/credentials/az
Authorization: Bearer edd_live_…

{ "clientId": "…", "clientSecret": "…", "tenantId": "…",
  "expiresAt": "2027-08-01T00:00:00Z" }

The path segment (s3 | az | gcs) must match the config's provider, and the rotate bodies are camelCase (unlike the snake_case register bodies). expiresAt (optional, RFC 3339) records when the new credential expires.

Good to know

Rotation is deliberately not exposed over MCP: the payload is raw secret material, which must not transit an LLM tool call or land in model context. Use the CLI or REST.

What rotation does not do

Heads up

Rotation cannot revoke the superseded secret. Eddytor's secret store has no per-secret revocation - the old handle decrypts until the master key rotates. Revoke the old credential at the provider (Azure portal, IAM, etc.), or rotate EDDYTOR_ENCRYPTION_KEY per backups & key rotation if it may have leaked.

On this page