How Should You Handle API Keys in Your Automations?

Where should the API keys for your automations actually live?

In a secrets manager, injected at run time, scoped to one job, and rotated on a schedule nobody has to remember. Not in a spreadsheet, not pasted into a workflow step, and not in a shared password note. The pattern is well documented and most teams are still one step behind it.

Automations are where this slips. A marketing team wires up a model provider key, a CRM token and a webhook secret in an afternoon, and the credentials go wherever the tool made it easiest to put them. Six months later nobody knows which keys exist or who holds them.

We treat this as a build task with its own checklist, the same as forms or redirects. Here is the checklist we use and what the published guidance behind it actually says.

Why are automation keys riskier than app keys?

Because they are broad and they are unattended. An application key usually does one thing for one service. An automation key often has write access to your CRM, your email platform and a model provider, and it runs on a schedule with nobody watching the output.

They also spread. The same token gets reused in a second workflow because that was faster than making a new one, then in a test scenario, then in someone's local script. OWASP names this problem directly: many organisations have secrets "hardcoded within the source code in plaintext, littered throughout configuration files".

The third difference is cost. A leaked model provider key is not only a data risk, it is a billing risk, because inference is metered. We wrote about capping that separately in setting spending limits on AI agents.

What does OWASP say the baseline is?

Four things, and they are not complicated. Centralise: OWASP advises you "standardize and centralize the secrets management solution with care". Restrict: apply "fine-grained access controls on each object" on a least privilege basis, and accept that "engineers should not have access to all secrets".

Automate: the cheat sheet pushes for a secrets pipeline, dynamic secrets and "automated rotation of static secrets" specifically to remove human handling. Audit: keep a record of "who requested a secret", "when the secret was used and by whom", and "when the secret has expired".

Read that list against your current automation stack and the gap is usually the audit line. Most teams can tell you where a key is stored. Very few can tell you which workflow used it last Tuesday.

How often should you rotate a key?

As often as the blast radius demands. OWASP's framing is useful because it refuses a single number: "regularly rotate secrets so that any stolen credentials will only work for a short time", with a duration that runs from minutes to years depending on what the secret protects.

Our own defaults for automation credentials are quarterly for anything with write access to customer data, and immediately on any personnel change that touched the credential. A key with read access to a public feed can sit longer. A key that can send email as your domain should not.

One nuance worth knowing: OWASP notes that user credentials are excluded from regular forced rotation, following NIST guidance. That is about people's passwords, not machine tokens. Machine tokens are exactly the thing rotation was designed for.

What does automated rotation look like in practice?

A managed service doing the work on a timer. AWS Secrets Manager is the clearest published example: you turn on automatic rotation, set a schedule in UTC that it stores as a rate or cron expression, and attach a rotation function that updates both the stored secret and the service it belongs to.

The published limits are specific. AWS states you "can rotate a secret as often as every four hours". You can also set a window duration, and if you do not, an hourly schedule closes its window after one hour while a daily schedule closes at the end of the day. If a rotation fails, Secrets Manager retries it.

The design lesson generalises past AWS. Rotation only works if the new credential is written to both sides in one controlled step. That is why a rotation function exists at all, and it is why manual rotation breaks automations: someone updates the provider and forgets the workflow.

Can you avoid long-lived keys altogether?

Increasingly, yes, and this is the change worth chasing. Federated identity replaces a stored key with a short-lived token minted for one job. GitHub describes the benefit of OpenID Connect in Actions plainly: "You won't need to duplicate your cloud credentials as long-lived GitHub secrets."

The mechanics are the point. With OIDC, GitHub says, "your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires". The token lives "only for the duration of the job". There is nothing left behind to steal.

Not every automation platform supports this yet. Where it is available, we take it, because a credential that expires on its own removes rotation from the human agenda entirely. Where it is not, we fall back to a managed secret with automated rotation.

How do you scope a key so a leak is survivable?

One key per workflow, one permission set per key, and no key that can do something the workflow never needs. This is the least privilege principle applied at the granularity of the job rather than the team.

In practice that means separate credentials for the automation that reads form submissions and the automation that writes to your CRM, even when both run on the same platform. It costs ten minutes at build time. It means a leak takes down one path instead of your whole stack.

The same logic applies to what an agent can reach, which is a slightly different problem with the same shape. We set that out in giving AI agents least privilege access.

What do you do in the first hour after a key leaks?

Revoke first, investigate second. The instinct is to work out how bad it is before acting. That order is backwards, because a key stays valuable to an attacker for exactly as long as it works.

So: revoke the credential at the provider, mint a replacement, update the secret store, confirm the automations resume, and only then read the logs. If you cannot do the first four steps in under fifteen minutes, that is the thing to fix before the next incident.

This is where OWASP's audit requirements earn their keep. Knowing when the secret was used and by whom is the difference between a contained incident and a guess. If your automations write no audit trail, add one; we covered how in audit trails for AI automations.

How do you catch a secret before it ships?

Scan for it automatically. OWASP recommends creating "detection rules for each of the stages of the secret lifecycle" and names tooling in this space, including Yelp's Detect Secrets, which it describes as having signature matching for around twenty secret types.

In a repository, that means a pre-commit hook plus a server side scan, because a hook on a developer machine is advice rather than a control. In a no-code automation platform, it means periodic review, since there is no commit to scan.

Container and deployment configuration deserves its own pass. OWASP warns that "secrets themselves should never be hardcoded using docker ENV or ARG commands, as these can easily leak", and advises letting an orchestrator overwrite the environment variable with the real secret at run time.

What about the secrets your CI already holds?

Treat them as production credentials, because that is what they are. OWASP's pipeline guidance is to avoid one large shared secret, rotate what is there, confirm that "forking should not leak", and log enough to detect secret extraction or misuse.

The forking point is the one teams miss. A public repository whose workflow reads a secret is one pull request away from a problem unless the platform prevents it. Check the behaviour rather than assuming it.

Webhook signing secrets sit in the same bucket and get even less attention, even though they are what stops anyone from posting fake events at your automations. We wrote up the verification side in verifying webhook signatures.

What we set up on every automation build

A single secret store, one credential per workflow, the narrowest permissions the workflow can run on, automated rotation where the provider supports it, federated short-lived tokens where that is an option, secret scanning in the repository, and a written revoke path that a non-specialist could follow.

None of that is exotic. All of it is cheaper to do at build time than to retrofit after an audit, and much cheaper than doing it during an incident. The work is mostly decisions, not code.

If you have automations running on credentials nobody has reviewed in a year, that is a good afternoon of work and we are happy to do it with you. Start a conversation at phoenix.studio and we will map what you have first.