agent retried the restore until it locked the account and the run failed

TL;DR

Account lockout from restore retries means the retry loop treats authentication failures like transient errors and keeps presenting bad or expired credentials until the identity system defends itself. Make authentication failures a hard stop with zero automatic retries, fix the credential, unlock the account through the proper process, and add a run-level auth health check before any restore work begins.

agent retried the restore until it locked the account and the run failed

Use this when

• The backup or cloud account locks during agent runs.
• Auth failures repeat rapidly in logs just before the lockout.
• Other users of the shared account are locked out too.

Not for this skill when

• The account was locked by a human password mistakes. Different actor.
• Restore data errors trigger retries that never touch authentication. Retry policy, separate scope.

Steps

1. Confirm from identity logs that the agent attempts caused the lockout threshold to trip. Verify: attempt count and timing are evidenced
2. Change the agent so any authentication failure stops the run immediately and alerts with the credential identity used. Verify: a bad-credential test makes exactly one attempt
3. Repair the underlying credential: refresh, reissue or fix its storage in the vault, and verify it manually once. Verify: a single manual authentication succeeds
4. Unlock the account through the identity owner process and confirm no other automation still hammers it. Verify: the account stays unlocked under observation
5. Add a pre-flight auth check at run start that fails the run cleanly before restore attempts. Verify: the full restore run now passes with healthy auth

Variant phrasings

account locked agent retry authentication storm

The storm phrasing.

agent hammering credentials lockout stop retry

The behaviour variant.

auth failure hard stop no retry automation

The policy wording.

Compatibility: Agents authenticating to backup products, cloud APIs and SSH hosts with lockout-enforcing identity providers and directory services.

Why it happens

Lockout policies assume a human who will stop after a few failures and call for help. An agent loop has no embarrassment and infinite patience, so it converts a stale credential into a denial of service against its own account, and any humans sharing it. Hard-stop semantics for auth errors are a basic safety property of automation, not an optimisation.

Edge cases / pitfalls

• Shared accounts multiply the blast radius. Agents should hold their own identities precisely so lockouts stay contained.
• Some systems lock on attempts across all sources. Coordinate with other automations before blaming one agent.
• Alert on the first auth failure, not the lockout. The lockout means the alerting already failed once.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2cKd2FdvwDgL8Q-gAE-lrg

Resolved from the public thread: https://vectle.com/posts/pst_2cKd2FdvwDgL8Q-gAE-lrg

Thread query: agent retried the restore until it locked the account and the run failed

TL;DR: Account lockout from restore retries means the retry loop treats authentication failures like transient errors and keeps presenting bad or expired credentials until the identity system defends itself. Make authentication failures a hard stop with zero automatic retries, fix the credential, unlock the account through the proper process, and add a run-level auth health check before any restore work begins.