The Standing Credential: Why Long-Lived Tokens Are a Class of Risk to Retire

Why standing credentials persist in agent runtimes

The first integration any team builds against a new platform almost always uses a long-lived token. The platform offers it; the documentation demonstrates it; the engineering effort to set it up is twenty minutes. Better patterns exist — installation tokens, workload identity federation, managed identities — but they require additional setup and frequently a platform team's involvement. The path of least resistance produces a standing credential, and most organisations stop there.

For agent runtimes the cost is higher than for other applications. The credential lives in the agent's process memory for the entire session, reachable by every tool call the agent decides to make. A model with broad tool access and a broad credential is a model whose worst-case behaviour is bounded only by the model's judgement — not a structural property an architect would design.

Industry guidance has been unambiguous on this for years. Microsoft's Secure Future Initiative Safe Secrets Standard requires moving away from long-lived secrets toward system-managed credentials. NIST SP 800-63B establishes the broader identity-management principles, including the preference for short-lived authenticators. The pattern is established; only the adoption lags.

The actual cost of a standing credential

The hidden costs are not difficult to enumerate once one looks for them:

The Standing Credential anti-pattern

A hypothetical compromise scenario

The following illustrates a plausible failure mode under the Standing Credential anti-pattern. It is constructed from elements common to several reported industry patterns; no specific incident is implied.

An engineer enables a coding-assistant integration on their workstation. The integration requires a long-lived credential with broad scope across the source-control platform; the engineer creates one and pastes it into the configuration prompt. The credential lives in the integration's process memory for every session, and on disk in the operating system's credential store between sessions.

Six months later, the engineer installs a productivity extension to the same editor. The extension is benign in itself, but is dependent on a third-party package that has been compromised at the publisher. The compromised package reads the credential store, exfiltrates every long-lived credential it finds, and reports them to the attacker.

The attacker now has a broad-scope credential that does not expire for another five months. They use it to access every repository the engineer's account can see. The integration that provisioned the credential is not the compromised software; nothing about the agent runtime malfunctioned. The standing credential simply did the thing standing credentials do: persisted long enough to be useful to a different attacker on a different day.

A standing credential outlives the session it was created for. That property is its hazard.

The replacement pattern: JIT, narrow, minted

The pattern that retires standing credentials has three properties:

1. Just-in-time. The credential exists only when the agent is about to use it. It is minted from a more durable underlying identity, used for the call, and discarded.
2. Narrow. The minted credential is scoped to the specific resources and verbs the call requires — not the maximum scope the platform offers.
3. Minted from a workload identity. The bootstrap identity is something the platform managed (a managed identity, a workload-identity-federated principal, a registered application with a private key), not a human user's static token.

This pattern is well-supported on every major platform. The implementation details differ; the architectural shape does not.

How this looks on each major platform

On every platform, the underlying identity (the App, the managed identity, the registered application) is something the platform can revoke, audit, and rotate. The short-lived credentials minted from it are observable, scoped, and expire automatically. The cost of getting the pattern in place is one engineering project; the cost of getting the pattern wrong is unbounded.

A practical checklist

• Every credential available to an agent runtime has a documented lifetime, and the lifetime is measured in hours, not months.
• Every credential available to an agent has a documented scope, and the scope matches the verbs in the agent's tool catalogue.
• Static personal access tokens are not used for source-control access by agent integrations.
• Cloud-platform integrations use managed identities or workload identity federation, not static service-account credentials.
• Credentials are minted just-in-time and not persisted beyond the session that requires them.
• Bootstrap credentials (App private keys, federation trust anchors) are stored in a managed secrets platform, not in environment variables or repositories.
• Credential rotation is automatic; no credential's continued validity depends on a human remembering to rotate it.
• An inventory records every long-lived credential that remains, its named owner, its lifetime, and its scheduled retirement.
• Credential use is audited; the audit trail distinguishes between mint events and use events.
• Secret-scanning is enabled on every repository where an agent configuration might land, including private and archived repositories.

Test your own agent in ten minutes

The fastest way to find out whether this anti-pattern is present in your own system is to ask an AI coding assistant to look for it. Run the prompt below in a fresh chat session, on its own — and judge the system by what the code actually does, not by what its documentation claims.

Search the whole repository to find where this applies — do not
wait for me to list files. Ignore generated, vendored, and dependency
folders (build output, node_modules, vendor). Identify every location
the failure mode below could occur, read those files in full before
you judge, and list the search terms you used so I can confirm nothing
was missed.

You are looking for one specific failure mode: the agent process
holds a credential that is long-lived (no automatic rotation), broad
in scope, and continuously available in memory or on disk —
for example a static API key, a personal access token, or a
service-account secret read from environment variables at startup
and never refreshed.

A short-lived token minted just-in-time per call from a workload
identity counts as not-present.

Respond with exactly these four sections:
1. VERDICT: one of [present / not present / unclear]
2. EVIDENCE: file path + line numbers + a one-line quote per claim
3. WHY IT MATTERS: two sentences, plain English
4. FIX: a concrete change, with a short before/after code snippet
   if applicable. If "unclear", list the one piece of context you
   need to decide.

Insist on the four-part answer: a verdict with a file path, a line number, and a one-line quote is something you can act on; a verdict on its own is just an opinion. If the result is present, the FIX section is your starting point — mint the credential just-in-time, scope it narrowly, and source it from a workload identity. Re-run the same prompt after the change to confirm the verdict flips to not present.

Conclusion

The standing credential is not a configuration choice but an architectural decision — and it is the wrong one for any system the organisation expects to be present for years. Short-lived, narrowly-scoped, just-in-time credentials are the available alternative on every major platform. The work to migrate is bounded; the savings — in audit findings, in rotation toil, and in the bounded impact of any compromise that does occur — compound across the lifetime of the system.

The next credential added to an agent's configuration is an opportunity to set the standard. Make it short-lived, make it narrow, mint it from a workload identity. The pattern that made the first version easy does not have to define the next ten years.