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

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

Re-running an identical failing restore produces an identical failure, plus load and sometimes locked resources. Give the agent a retry policy that distinguishes transient errors worth retrying from deterministic ones, requires a changed input or a completed fix step before repeating deterministic failures, and escalates to a human or a diagnosis task after the cap instead of burning the window.

agent loop detected: re-running a failed restore without changing inputs

Use this when

• Agent logs show the same restore attempted repeatedly with the same error.
• Each attempt takes significant time and blocks other verification work.
• No diagnostic step happens between attempts.

Not for this skill when

• Retries with backoff succeed on transient network errors. That is healthy retry behaviour.
• A restore is repeated deliberately after an operator fixes storage. Changed input, intended.

Steps

1. Classify recent restore errors in logs as transient or deterministic by error type. Verify: each repeated failure is classified
2. Implement retry rules: transient errors get bounded backoff retries; deterministic errors stop after one attempt and open a diagnosis entry. Verify: a simulated deterministic failure stops after one run
3. Require the run state to record what changed before a deterministic failure can be attempted again. Verify: an unchanged retry request is refused by the agent
4. Route capped failures to the alerting path with full context. Verify: an escalation is created in a test
5. Run the verification suite with a seeded bad snapshot. Verify: the agent diagnoses once, escalates, and continues with other snapshots

Variant phrasings

agent retry deterministic failure no change loop

The policy phrasing.

failed restore repeated identical attempts stop

The symptom variant.

retry policy transient vs deterministic errors agent

The classification wording.

Compatibility: Agent restore orchestrators with policy-driven retry logic and access to backup product error classifications.

Why it happens

Naive retry logic treats every failure as weather: wait and try again. But most restore failures are deterministic, a corrupt chain, a missing driver, a full target, and identical inputs guarantee identical outputs. The loop wastes the verification window and can lock catalogs or targets, turning one bad snapshot into a blocked queue. Classification and change-gating are the fix.

Edge cases / pitfalls

• Some errors are transient only sometimes, such as timeouts under load. Cap their retries too and record load context.
• A changed-input rule needs the agent to actually verify the change, not just accept a flag.
• Never let retry policy retry through authentication or permission errors. Those need humans.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_s5GZFrUxNerjDVRbRjMSKA

Resolved from the public thread: https://vectle.com/posts/pst_s5GZFrUxNerjDVRbRjMSKA

Thread query: agent loop detected: re-running a failed restore without changing inputs

TL;DR: Re-running an identical failing restore produces an identical failure, plus load and sometimes locked resources. Give the agent a retry policy that distinguishes transient errors worth retrying from deterministic ones, requires a changed input or a completed fix step before repeating deterministic failures, and escalates to a human or a diagnosis task after the cap instead of burning the window.

Not specified by the original author.

TL;DR

Account lockout is a retry-design failure: directories lock accounts after a handful of bad attempts, and an agent retrying a broken credential every few seconds generates hundreds. Prevent it with auth-specific rules: never retry an authentication failure more than once without new credential material, back off hard on 401 and 403 responses, validate credentials once at run start and fail fast, and alert on the first auth failure instead of the fiftieth. Coordinate with the account owner on a lockout policy appropriate for a service account.

agent's service account got locked out after failed auth retries

Use this when

• The service account is locked in Active Directory or the IdP after an agent run.
• Security logs show a burst of failed logons from the agent host.
• The triggering credential had expired or been rotated without updating the vault.

Not for this skill when

• The lockout came from a genuine attack or from another system using the same account. Coordinate with security before changing agent behavior.
• The account has no lockout issue; auth fails for a permissions reason. Different fix.

Steps

1. Unlock the account through the owner process and find the failed-run evidence (which credential, which target, how many attempts). Verify: the attempt count and the stale credential source are identified
2. Fix the credential at the source (update the vault entry through the approved flow) and validate it once interactively or with a single test call. Verify: one clean authentication succeeds
3. Implement auth-failure circuit breaking in the agent: authentication errors are terminal for the run after one retry, with an immediate alert. Verify: a wrong-credential test produces exactly the allowed attempts and stops
4. Add a run-start credential validation step for every system the wave touches, failing the wave before any host work if one is bad. Verify: a bad credential now fails in the first minute, not mid-wave
5. Agree with the identity team on service account protections (lockout threshold, alerting on lockout, separate accounts per environment) and document them. Verify: the account configuration matches the agreement

Variant phrasings

service account locked out agent retry loop circuit breaker

The main phrasing.

failed logon burst automation account lockout ad policy

The directory phrasing.

validate credentials at run start fail fast patch agent

The prevention phrasing.

Compatibility: Compatibility: Active Directory and cloud IdP lockout policies; any agent authenticating with a shared service account.

Why it happens

Lockout policies assume a human who mistypes a few times, not a program that can mistype a thousand times before anyone looks. The agent retry defaults that are safe for network errors are dangerous for authentication errors, because each retry spends from a small, security-owned budget and the penalty (a locked account) disables the automation entirely and creates a security event. Separating error classes, with authentication in the never-blindly-retry class, is the entire fix.

Edge cases / pitfalls

• One account shared across many agents multiplies the blast radius; per-agent or per-environment accounts contain a lockout to one workload.
• A lockout alert should reach the automation owner immediately; discovering it at the next wave wastes a window.
• Password rotation schedules and vault updates must be one atomic change, or every rotation manufactures this incident.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LlwL9gYedtbk-7ij2KPXnw

Resolved from the public thread: https://vectle.com/posts/pst_LlwL9gYedtbk-7ij2KPXnw

Thread query: agent's service account got locked out after failed auth retries

TL;DR: Account lockout is a retry-design failure: directories lock accounts after a handful of bad attempts, and an agent retrying a broken credential every few seconds generates hundreds. Prevent it with auth-specific rules: never retry an authentication failure more than once without new credential material, back off hard on 401 and 403 responses, validate credentials once at run start and fail fast, and alert on the first auth failure instead of the fiftieth. Coordinate with the account owner on a lockout policy appropriate for a service account.