## TL;DR
An expired credential will never start working again, so an agent retrying it is not being persistent, it is being broken in a loop and delaying the case while burning rate limits. Classify auth errors separately from transient errors: on the first expiry style failure, stop the retry schedule, reload the current credential from the secret store, make one validation call, and resume only if it succeeds. If the reloaded credential fails too, park the case and alert a human with the credential version and expiry evidence, because the rotation or the secret store itself is now the incident.

```text
fraud agent's sift api token expired mid-review and it kept retrying with the old one
```

## Use this when
- Agent logs show repeated Sift auth failures with identical requests over minutes or hours.
- A review finished late because the agent spent its window retrying.
- The credential in the secret store is newer than the one the agent is using.

## Not for this skill when
- The credential was revoked for cause, for example a suspected leak. Do not auto refresh and resume; follow the security incident path.
- Failures are rate limits or 5xx from Sift. Those use backoff retry, the opposite handling.

## Steps
1. Confirm the loop from logs: count identical auth failures per case and identify the credential version the agent loaded at start. Verify: you can state how many retries burned and which version was used.
2. Separate error classes in the agent HTTP layer: auth expiry gets zero blind retries and routes to the refresh path; transient errors keep their backoff schedule. Verify: a staged expired credential produces one failure, one refresh, and no retry storm.
3. Implement the refresh: reload from the secret store, validate with a lightweight read, swap the client credential without restarting the whole case, and log the version change on the case. Verify: a mid review expiry in staging resumes with the new version and a case note.
4. Add the loud failure: if validation after refresh fails, park the case in a blocked on credentials state and page the integration owner. Verify: a staged bad store credential pages instead of looping.
5. Prevent recurrence: load credentials at run start from the store, never from cached clients or static config, and surface credential expiry dates in the ops dashboard. Verify: the dashboard shows days to expiry for the Sift credential with an alert threshold.

## Variant phrasings
### agent retrying expired sift credential loop
Loop phrasing.
### sift auth expired agent did not refresh
Refresh phrasing.
### fraud agent stuck on 401 sift review
Status code phrasing.

Compatibility: Sift API integrations with credentials held in Vault, AWS Secrets Manager, GCP Secret Manager, or environment delivered secrets, and any agent framework with a tool error handling layer. The pattern applies to every vendor credential the agent holds.

## Why it happens
Retry logic is written for the failures engineers fear, flaky networks and busy servers, where trying again is right. Expiry is a different species: deterministic, permanent, and worsened by repetition. Without an explicit class for it, the generic retry policy treats a dead credential as a slow server, and the agent faithfulness to its retry schedule becomes the outage.

## Edge cases / pitfalls
- Some vendors return the same status for expired and under scoped credentials. The refresh path must distinguish them by testing scope after refresh, or it will loop between two different faults.
- Credential expiry dates should alert weeks ahead. The runtime refresh is the seatbelt; the dashboard alert is the brakes.
- Never log the credential value while debugging the loop. Log version labels and fingerprints only.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GswbJbYT0TEqSpwJT1-H4A