Credentials That Heal Themselves: Inside ServiceHub's Secrets Management

Agentic automation lives or dies on one unglamorous detail: the credentials behind it. A token quietly expires, and a workflow that ran perfectly yesterday fails today — not because the logic broke, but because a token did. Secrets Management is built so that does not happen: credentials are treated as living things that stay healthy on their own, with no code to write when you add a provider.

Data-driven by design

A credential's shape is not hardcoded anywhere. It is declared as a schema, and its values are configured against that schema. Tool and process configuration sit alongside it, so the runtime properties a credential needs are read from configuration rather than baked into the application.

The payoff: the same machinery works across every tool and connector, and onboarding a new provider means declaring its schema — not shipping code and waiting for a release.

Three ways a credential stays alive

• Manual refresh and sign-in. Every credential has its own controls. Refresh forces a new access token. Sign In covers what a background refresh cannot recover from: a corrupted or missing credential, or a refresh token that is itself dead. That distinction matters — retrying a dead refresh token forever is how an integration ends up hammering a provider until it is rate-limited.
• Automatic refresh. A scheduled pass runs every five minutes and is status-driven. It refreshes credentials that are healthy but expiring within ten minutes, or already expired; leaves healthy ones alone; and sets aside the ones only an interactive sign-in can fix. The same pass runs once at startup, so tokens are fresh the moment the platform comes back up rather than on the first failure after it.
• Automatic recovery. A token can still die at the exact moment a service needs it — the five-minute window is small, not zero. When a service hits a token error, the credential is refreshed in place, the stale cached value is cleared, and the call proceeds. The operation recovers mid-flight instead of surfacing an error to whoever is watching.

One definition, every tier

What makes this robust rather than fragile is that all three paths share a single data-driven definition of how a given credential is refreshed. The manual button, the five-minute pass and the mid-request recovery resolve the same schema and dispatch through the same execution path.

There is no per-provider special-casing to drift out of sync — which is the usual way a system like this rots. The scheduled path gets fixed, the manual one does not, and nobody notices for a quarter.

The part that only breaks in production

One detail worth naming, because it looks fine until it is not.

The scheduled pass fires on every replica. Run four instances and, without coordination, all four refresh the same credential at the same moment. With providers that invalidate the previous refresh token the instant a new one is issued, that is not a wasted call — it is an outage: one instance wins, and three are left holding tokens the provider has already revoked.

So the pass takes a cross-process lock, and exactly one instance does the work. It is a small piece of configuration guarding a failure that only appears once you scale out, which is the worst possible time to find it.

Why it matters

Automation you cannot trust is automation you will not use. Because credentials refresh proactively, recover reactively, and can always be driven by hand, agentic workflows keep running without anyone babysitting tokens — and because the framework is schema-driven, that reliability extends to every new integration you add.