Keeping Client API Keys Straight Across AI Agent Workflows

Automation agencies reuse templates constantly, because building the same lead-qualification agent from scratch for every client wastes billable time. The risk is that a template carries a hard-coded credential with it. Once that template gets duplicated for a new client, the original key comes along unless someone deliberately strips it out, and duplication happens faster than manual review can keep up with.

It rarely starts as carelessness. A developer testing a new workflow pastes a working key in to confirm the logic runs, ships it, and moves to the next ticket without swapping the key for a placeholder. Multiply that across a dozen client workflows built under deadline pressure, and a shared key ends up living in more places than anyone can list from memory.

Doppler lets each client's keys live in their own project, referenced by the workflow platform's environment variables instead of pasted directly into a node's configuration. A developer building a new workflow pulls the current client's key from Doppler rather than copying one from an old template, which removes the step where a stale key gets carried forward by habit.

As an agency's agent count grows into the hundreds, Vault's dynamic secrets let a workflow request a short-lived credential at runtime instead of holding a standing key indefinitely. When an agent workflow breaks because a secret rotated out from under it, that failure counts against the same change failure rate any other broken deploy does, and a client doesn't care that the cause was a credential instead of a code bug¹.

The moment you suspect a key was reused across clients, rotate it immediately and check the provider's usage dashboard for the client whose key it was, since API billing is often the first place a leak shows up as a real dollar cost. Then check every other client's workflows for the same template, because if one carried a stale key, others built from it probably did too.

If you suspect a key was reused across clients:

1. Rotate the key immediately through the provider's dashboard so the exposed value stops working.
2. Check the provider's usage dashboard for the client whose key it was, since API billing is often the first place a leak shows up.
3. Check every other client's workflows built from the same template, because if one carried a stale key, others probably did too.
4. Trace how the key got into the workflow in the first place, once the leak is contained.
5. Replace literal keys with variable references to each client's own scoped project or namespace.

An agency's fastest path to a new client's first automation is copying a working template from a previous engagement and swapping in the new client's details. The step that gets skipped under deadline pressure is checking every node in that template for a hard-coded reference to the old client's credential, especially in nodes that were configured once during testing and never touched again.

A workflow platform's version history can help here: before duplicating any template for a new client, search it for anything that looks like a literal key rather than a variable reference. If your team can't quickly answer which client a given template was originally built for, that's a sign the template itself needs cleaning up before it gets reused again.

Not every automation needs a uniquely scoped key, but any workflow that touches a specific client's billing account, customer data, or anything with a usage-based cost attached to it should never share a credential with another client's workflow, full stop. That's the line worth drawing before an agency's automation count grows past what any one person can track from memory.

A simple test: if you can't say, without checking, exactly which client's quota a given workflow's API calls are billed against, that workflow's credential setup needs to be revisited. Workflows that only touch shared, non-client-specific tooling, like an internal Slack notification bot, are lower stakes and can reasonably share infrastructure without the same isolation requirement.

An agency building automated workflows accumulates a different kind of secret than a typical software shop: API keys for the language model providers, search tools, and third-party actions a given workflow calls at runtime. A single client's agent might touch several separate provider keys, and none of them should be visible to a workflow that doesn't call that provider.

Scope each key to the specific workflow or agent that needs it, not to the whole client project by default. When a workflow gets rebuilt or retired, that's also the moment to check whether the key it used is still referenced anywhere else before you assume it's safe to revoke.

The same discipline applies to any key a client's own team hands you to connect their existing tools. Treat it as scoped to that one integration, and confirm with the client before reusing it anywhere else in the workflow you're building for them.