A Backup Sign-In Path for the Tools Your Agents Depend On

Start by listing every system the agent authenticates to, not every system it mentions. The practical way to find them is to read the agent's actual traffic for a representative week: outbound network logs, connector configuration, environment variables that hold endpoints, and the scopes granted to its service account. Include anything it uses only occasionally, because the occasional dependency is exactly the one nobody tests.

A workable first-pass list for most agent deployments:

Build the list in a spreadsheet or a page in your runbook system, and give each row an owner, an auth method, a secret location, and a fallback. The AWS documentation on retrieving secrets with AI coding agents is a useful reminder of why secrets should not live in the agent's shell environment at all: the guidance is built around references like {{resolve:...}} and a wrapper that runs a command with secrets injected, rather than letting the agent call get-secret-value and receive plaintext in AWS Secrets Manager. If the agent can read the secret directly, so can anything that compromises the agent, and your fallback credential becomes the attacker's second key too.

Two inventory rules that save time later. First, record where the credential lives, not just what it is: "CI variable in project X" and "safe in office 2" are different recovery times. Second, record the last date each credential was used and the last date it was tested. A fallback that has never been used in months is a hypothesis, not a control.

Not every broken link deserves the same response. Sort each system into one of three buckets, and write the classification next to the row. This is the highest-value decision in the whole exercise, because it tells you which fallback must exist before an incident and which one can be improvised during one.

Hard fail. The agent cannot do its job without this system and its primary auth path. Typical hard fails are the identity provider that issues the agent's workload token, the secrets store that holds every downstream credential, and the token issuer. If any of these is unavailable, the agent stops.

Degraded. The agent can continue in a reduced mode. Source control being unreachable means it writes to a local branch and the commit is pushed later. Ticketing being unreachable means the ticket is queued. A database outage with a read-only replica means the agent can plan but not commit.

Non-blocking. The webhook receiver is down, but the result is stored and can be resent. The notification channel is down, but the work finished.

A worked example makes the arithmetic concrete. Suppose an agent run takes 20 minutes and has 40 steps, and the token issuer is unreachable at step 31. If the run has no checkpointing, you lose the whole 20 minutes and any side effects already applied, and you must reconcile them by hand. If the ticketing system is unreachable at step 31 and the agent can queue the update, you lose nothing but latency. The cost of a missing fallback is proportional to how much unrecoverable state the agent has already written, so the classification should drive where you spend effort: hard fails first.

There is also an assurance dimension. If your organization has mapped agent infrastructure to NIST's authenticator assurance levels, the fallback must not quietly sit at a lower level than the path it replaces. NIST's description of AAL2 requires two authentication factors and adds requirements on reauthentication time, replay resistance and authentication intent, while AAL3 adds hardware-based authenticators, verifier impersonation resistance and verifier compromise resistance per NIST's AAL guidance, and Microsoft's summary recommends at least AAL2 with phishing resistance for Entra deployments. A fallback that drops to a single shared password is a different, weaker control than the one you thought you had.

Four fallback patterns cover most cases. Match the pattern to the classification rather than applying one pattern everywhere.

Separate credential, same system. A second API key, a second OAuth app, or a second service account with the same scopes, stored separately. This is the cheapest fallback and the right one for API gateways, ticketing and source control. Its weakness is that both credentials usually depend on the same provider, so it survives a revocation but not a provider outage.

Different identity provider. A backup IdP, or an existing on-premises IdP used as the secondary, with its own SAML profile in the target cloud. This is Google's recommended pattern for continuous access and it is the only pattern that survives an outage of your primary IdP in Google Cloud's guidance. It is heavy to maintain, so reserve it for the identity layer itself and for the small number of systems that will not accept a local credential.

Pre-provisioned service account or emergency account. A dedicated account that lives outside the normal identity dependency chain, used only for emergencies. The Cloud Security Alliance's break-glass guidance is blunt about what happens without this: misuse or compromise of highly privileged static accounts can lead to breaches with catastrophic consequences, so these accounts need isolated monitoring, documented approval and periodic testing per the CSA's break-glass best practices. The IDSA's write-up adds the two rules that matter most for agents: the account must not rely on the same identity provider that could fail, and any use must be followed by rotating and resecuring the credential per the IDSA on break-glass accounts.

Manual token issue. A human with the right privilege issues a short-lived token by hand. This is the last resort, and it is legitimate when the alternative is a standing privilege that never expires. It only works if the procedure is written, the human is reachable, and the token is scoped to the minimum the agent needs.

For machine-to-machine calls specifically, the strongest structural fallback is not a second secret but the absence of a first one. Workload identity federation lets an external workload exchange a native identity token, such as a CI job's OIDC token or a cloud IAM role, for a short-lived credential, which one practical walkthrough describes as creating no key files at all for GCP workload identity federation, and AWS's write-up of the same pattern notes that the credentials expire in minutes in AWS's workload identity overview. A federation trust is a configuration object, not a secret: it can be re-created quickly and it cannot be copied out of a repo. If a fallback must be a secret, make it the exception, not the default.

One page per row in your inventory table. Write it so that a competent on-call engineer who has never touched the system can execute it at 3 a.m. without asking a question. A template that holds up in practice:

SYSTEM: token issuer (OAuth token endpoint)
CLASS: hard fail
PRIMARY AUTH: client credentials, key held in CI secret store
OWNER: platform-oncall (rotation), identity-team (issuer config)
TRIGGER: token request returns 4xx/5xx for 3 consecutive attempts, or exchange latency > 10s for 5 minutes
DETECT: alert on token-request error rate, dashboard link inside runbook
FALLBACK: secondary client registered for the same scopes, key in office safe, sealed envelope 4
STEPS:
  1. Confirm failure is auth, not network: curl token endpoint from bastion, check DNS and egress allowlist
  2. If auth, retrieve sealed envelope 4 with second witness, log safe access
  3. Set AGENT_CLIENT_ID and AGENT_CLIENT_SECRET from envelope, redeploy agent config only
  4. Re-run the failed step; reconcile side effects from the checkpoint log
  5. After service restored: rotate both client secrets, reseal envelope, file incident note
ROLLBACK: revert to primary client, confirm token exchange succeeds, revoke secondary if it was exposed

Three details separate a runbook that works from a document that merely describes the system. First, the trigger is measurable: error counts and latency thresholds, not "when it seems broken." Second, the steps name the exact variables and the exact command, because the person executing them may not know your naming conventions. Third, the rollback and the post-use rotation are written down. Emergency access that is not rotated after use is the most common way a fallback becomes the new primary attack surface, which is why both the IDSA and Cloud Security Alliance stress rotation and resecuring after every use per the IDSA and the CSA.

Keep the collection in one place, version it next to the agent's configuration, and review it when the agent's scopes change. A runbook that describes a connector the agent no longer uses is worse than no runbook, because it consumes trust.

A fallback path is a control in the same sense as a fire extinguisher, and fire extinguishers get inspected. The pattern most teams converge on is a quarterly drill for soft dependencies and a monthly or per-change check for the identity layer, with the drill logged like any other change.

A drill that takes under an hour:

1. Pick one system from the inventory with a hard-fail classification.
2. Announce the drill in the on-call channel and set a time box.
3. Disable or suspend the primary credential at the provider, not in your own configuration, so you are testing the provider's response rather than your code's.
4. Run the agent's smoke task that exercises that dependency.
5. Time how long the fallback takes to work, and note every step that required someone who was not in the room.
6. Restore the primary, confirm the agent works on it, and rotate anything the drill exposed.
7. Record the result in the inventory row: date tested, worked or not, time to recover, and what to fix.

Track two numbers across drills: time from trigger to fallback working, and number of unplanned people consulted. Both should fall. If they do not, the runbook is doing the wrong job.

Passkeys are a specific case worth planning for, because they change what "losing the device" means. Microsoft reports that 99 percent of users successfully register synced passkeys, and that for its own account users a synced passkey sign-in is 14 times faster than a password plus traditional MFA combination, 3 seconds against 69 seconds, with 95 percent sign-in success versus 30 percent for legacy methods in Entra's passkey documentation. The trade-off for recovery is documented too: synced passkeys do not support attestation, while device-bound passkeys never leave the single device per the same Entra documentation. For an emergency account, that argues for registering more than one key and storing the spare physically, as one practical walkthrough on deploying FIDO2 keys recommends giving every user at least two keys and registering both in a Windows 365 FIDO2 walkthrough. The same reasoning applies to agents: if an agent's fallback is a hardware key on a rack shelf, register two and put one in a different building.

One dependency deserves separate treatment because it is easy to forget in an auth inventory: the model endpoint itself. If your agent authenticates to several providers with different keys and quota, an outage at one of them is exactly the kind of degraded event the classification should catch, and a fallback provider with its own credential and its own egress path is a legitimate part of the chain. Quanta Inference puts text, image, video, audio and embedding models behind one API key, OpenAI-compatible and prepaid in US dollars (https://quantaintelligence.ai/inference), which reduces the number of credentials in the inventory without removing the need for a second path to each system around it.

If the inventory and the drills turn up gaps you cannot close with the team you have, a free half-hour scoping call is often the fastest way to prioritize which fallbacks to build first (https://quantaintelligence.ai/calendar).