agent loop detected: re-authenticating to Okta without progress, run failed

Not specified by the original author.

TL;DR

The agent gets a 401, re-authenticates, gets another 401, and loops. Break it: after two consecutive failed authentications, stop the run and surface the credential problem instead of retrying.

agent loop detected: re-authenticating to Okta without progress, run failed

Use this when

• An agent loops on Okta authentication failures.
• Each re-auth fails the same way.
• The run burns rate limit on retries.

Not for this skill when

• Auth fails once then succeeds. That is a transient.
• The failure is not auth. Fix the real error.
• The credential was just fixed. Re-run cleanly.

Steps

1. Count consecutive authentication failures in the run. Verify: the counter increments.
2. After two failures, stop the run. Verify: no third attempt fires.
3. Report the failing credential and the last error. Verify: the report is specific.
4. Fix the credential: rotate, unlock, or correct the stored value. Verify: the fix addresses the error.
5. Re-run from the start. Verify: authentication succeeds.

Variant phrasings

re-auth loop

The short phrasing.

401 loop

The status-first search.

authentication retry loop

The generic phrasing.

Compatibility: Any agent authenticating to Okta in a loop.

Why it happens

Re-authenticating with a broken credential never succeeds. The loop just burns rate limit and delays the real fix, which is always credential repair.

Edge cases / pitfalls

• The credential fixed mid-loop by someone else; still stop and re-run clean rather than trusting the loop state.
• Two attempts being too few for flaky networks; distinguish network flakes from auth failures.
• The report needing to name the credential, or the fix goes to the wrong place.
• Backoff between the two attempts: a brief pause avoids hammering, but the cap is what matters.

Provenance

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

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

Thread query: agent loop detected: re-authenticating to Okta without progress, run failed

TL;DR: The agent gets a 401, re-authenticates, gets another 401, and loops. Break it: after two consecutive failed authentications, stop the run and surface the credential problem instead of retrying.

Not specified by the original author.

TL;DR

Break the loop by measuring progress, not by letting the agent try harder. Log the inputs and the result hash of the step that tries to pull Okta group membership, and if two consecutive attempts use identical inputs and produce identical results, stop the run and change something real: the scope, the tool, or the data the step depends on. Add a hard attempt cap and a human escalation so a future loop ends with a useful report instead of a burned run.

agent loop detected: agent kept repeating the same pull Okta group membership step and failed with error

Use this when

• The agent repeats the pull Okta group membership step with the same parameters and the same outcome.
• Run logs show many attempts and no state change in the target system.
• The run only ends when it hits a global limit or is killed manually.

Not for this skill when

• The step fails once with a clear platform error. Fix the platform error and retry normally.
• The agent is working through a long list where each step differs. That is progress, not a loop.

Steps

1. Extract the repeated step calls from the run log and compare their parameters and results side by side to prove whether they are truly identical or slowly changing. Verify: the loop is characterised as identical repeats or near repeats with evidence.
2. Check the target state in SailPoint after the attempts to see whether any attempt actually advanced the work to pull Okta group membership, since a reporting bug can make real progress look like repetition. Verify: target state is known independently of the agent own reporting.
3. Identify what the step is waiting for or missing, such as a status that never flips, a file that never appears, or a precondition the agent cannot see, by testing that precondition directly. Verify: the unmet precondition or false assumption is named.
4. Fix the precondition, or change the strategy for this step to a different tool or a smaller scope, rather than replaying the same call with new hope. Verify: the revised step differs from the looped one in a recorded way.
5. Add loop guards to the workflow: a per step attempt cap, a check that compares the result of each attempt with the previous one, and an automatic stop with a summary when no progress is detected. Verify: the guards are configured and visible in the workflow settings.
6. Rerun the guarded workflow on the affected scope and watch it either complete the step to pull Okta group membership or stop early with the no progress summary. Verify: the rerun ends in completion or in a clean early stop, not a long loop.
7. File the loop summary, the root precondition and the guard settings with the review evidence so the pattern is recognisable if it recurs on another step. Verify: the evidence contains the loop analysis and the final guard configuration.

Why it happens

Agents loop when a step result does not match the condition the agent expects next, and retrying feels safer than escalating. Without an external progress measure, identical calls look like persistence from the inside. The missing ingredient is almost always a state the agent cannot observe, a status field it misreads, or a precondition owned by another system. Guards that compare consecutive results make the loop visible mechanically, and a strategy change addresses the cause instead of rationing the symptom.

Variants and edge cases

agent stuck repeating pull Okta group membership step

The operations phrasing. Prove identical inputs and outputs from the log before changing the workflow; similar looking steps may be genuine list processing.

how to add loop detection to an access review agent

The engineering phrasing. A result comparison plus an attempt cap per step catches most loops within two wasted calls.

same SailPoint call repeated with no progress in agent run

The log phrasing. Check target state independently; sometimes the loop is in the agent reporting, not in the platform.

Edge cases to check before closing the review cycle:

• Never assume a timed out call did nothing. Always check the live Okta group member list before retrying a change.
• Two retries at the same settings prove nothing. Change one variable, size, timing or timeout value, per attempt and record it.
• Keep the run identifier on every output so a resumed run can prove it belongs to the same review cycle.

Compatibility: Agent workflow tooling with checkpointed tool calls, the named platform APIs at current versions, and a human reviewer able to verify results in the source system.

Provenance

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

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

Thread query: agent loop detected: agent kept repeating the same pull Okta group membership step and failed with error

TL;DR: Break the loop by measuring progress, not by letting the agent try harder. Log the inputs and the result hash of the step that tries to pull Okta group membership, and if two consecutive attempts use identical inputs and produce identical results, stop the run and change something real: the scope, the tool, or the data the step depends on. Add a hard attempt cap and a human escalation so a future loop ends with a useful report instead of a burned run.

Not specified by the original author.

TL;DR

Make the run survive its own credential lifetime instead of racing it. Long access review runs routinely outlive the short lived credentials they start with, so the workflow should refresh authentication before expiry, checkpoint after every batch, and on a 401 response re-authenticate once and resume the interrupted batch rather than failing the run. Check the credential lifetime in SailPoint, set the refresh point well inside it, and keep credential material in the vault the workflow reads, never in logs or prompts.

auth token expired mid-revocation verification run: agent failed with error 401 unauthorized

Use this when

• A run to pull Okta group membership works for a while and then fails with a 401 response.
• Short test runs succeed and full review runs fail near a consistent elapsed time.
• Restarting the run works immediately, which points at expiry rather than permissions.

Not for this skill when

• The very first call returns unauthorized. That is a wrong, revoked or under-scoped credential, not an expiry.
• Calls fail with a forbidden response after successful authentication. That is authorization scope, handled separately.

Steps

1. Measure the failure point: note the run start, the time of the first 401 response and the step in progress, and compare it with the credential lifetime the platform issues. Verify: elapsed time to failure and the issued lifetime are compared with numbers.
2. Confirm the diagnosis by checking in SailPoint that the credential or session was valid at run start and shows an expiry or revocation event near the failure time. Verify: the expiry explanation is confirmed from platform records.
3. Add a checkpoint save after every completed batch in this workflow if one is not already present, so re-authentication never means restarting from zero. Verify: the workflow writes checkpoints that a resumed run can read.
4. Configure the workflow to refresh or re-acquire its authentication at a set fraction of the known lifetime, and to do so between batches rather than in the middle of a multi-call operation. Verify: the refresh point is configured and occurs between batches.
5. Add a single guarded recovery for a 401 response: pause, re-authenticate through the approved vault backed flow, verify one read call succeeds, then resume the interrupted batch exactly once. Verify: a simulated expiry mid-run recovers and completes the batch.
6. Run the full task to pull Okta group membership past the previous failure time and confirm it completes, with refresh events visible in the log and no credential values anywhere in that log. Verify: the full run completes past the old expiry point with a clean log.
7. Record the credential lifetime, the refresh setting and the recovery behaviour in the workflow notes so future long steps inherit the design. Verify: the notes state the lifetime and the refresh rule for this platform.

Why it happens

Short lived credentials are a deliberate security feature, and review workloads are long by nature, so expiry mid-run is a design condition, not bad luck. Workflows built as one long authenticated session collide with it every time the review grows. Refreshing proactively inside the lifetime, checkpointing between batches and treating a 401 as a resumable event align the workflow with how the platform intends credentials to be used, without weakening security by reaching for long lived credentials.

Variants and edge cases

401 unauthorized halfway through pull Okta group membership run

The timing phrasing. A consistent time to failure is the signature of expiry; permissions fail immediately.

how to refresh agent authentication during a long review run

The design phrasing. Refresh between batches at a fraction of the lifetime, and verify with one read before resuming writes.

SailPoint session expires before review finishes

The platform phrasing. Check whether the platform offers a refresh flow or a service identity suited to automation instead of stretching a user session.

Edge cases to check before closing the review cycle:

• Never assume a timed out call did nothing. Always check the live Okta group member list before retrying a change.
• Two retries at the same settings prove nothing. Change one variable, size, timing or timeout value, per attempt and record it.
• Keep the run identifier on every output so a resumed run can prove it belongs to the same review cycle.

Compatibility: Agent workflow tooling with checkpointed tool calls, the named platform APIs at current versions, and a human reviewer able to verify results in the source system.

Provenance

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

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

Thread query: auth token expired mid-revocation verification run: agent failed with error 401 unauthorized

TL;DR: Make the run survive its own credential lifetime instead of racing it. Long access review runs routinely outlive the short lived credentials they start with, so the workflow should refresh authentication before expiry, checkpoint after every batch, and on a 401 response re-authenticate once and resume the interrupted batch rather than failing the run. Check the credential lifetime in SailPoint, set the refresh point well inside it, and keep credential material in the vault the workflow reads, never in logs or prompts.