AI agents and API keys: why long lived keys are the wrong default

Give every AI agent its own identity and issue short lived, narrowly scoped credentials, instead of pasting one long lived API key into its config. A static key outlives the task, gets copied into prompts and logs, and cannot tell you which agent used it.

What goes wrong with a static key?

A coding agent usually starts with a key someone pasted in so it would work. That key tends to be broad, because narrowing it takes effort. It lives in an environment file, then in a shell history, then in a transcript the agent writes to disk. Nobody sets an expiry.

Agents add two problems that scripts did not have. They read untrusted content, such as web pages, tickets and files, and that content can try to steer them. And they act on their own, so a stolen or misused credential does more before a person notices.

OWASP lists Excessive Agency as one of the ten major risks for LLM applications. Its stated causes are excessive functionality, excessive permissions and excessive autonomy. A broad static key is the permissions problem in its purest form.

What does good look like?

The OWASP Secrets Management Cheat Sheet gives most of the answer, and none of it is specific to AI.

• Set expiry on secrets where possible. Static keys are acceptable only for material that must outlive a deployment, such as storage encryption keys.
• Use dynamic secrets where possible, with short leases, and revoke when no longer needed.
• Scope CI/CD service accounts only to the secrets and services their jobs need.
• Have consumers fetch their own secrets with a service identity, instead of passing secrets along through pipelines.
• Log who requested a secret, when it was used and when it expired. Alert on access from unexpected places.

Apply those to an agent and you get a pattern: one identity per agent, a token minted per task, and a lifetime measured in minutes.

Is there a working example?

Yes, in CI. GitHub's documentation on OpenID Connect describes workflows exchanging short lived tokens directly with a cloud provider, so you do not store a cloud credential as a long lived secret. Each token is valid for a single job and then expires. The same idea works for agents: trust is set up once between the platform and the provider, and the agent gets a temporary token at run time.

What about tools the agent calls?

Scope the tool, not only the key. OWASP's guidance on Excessive Agency says to offer only the extensions the agent needs, to prefer narrow tools over open ended ones such as shell execution or arbitrary URL fetching, and to run actions in the user's own context with least privilege. It also says to enforce authorization in downstream systems rather than trusting the model's judgment.

For high impact actions, put a person in the loop. A token that can only open a pull request is a smaller risk than one that can merge and deploy.

How do you find the keys you already have?

Search before you design. Scan repositories, config files and agent transcripts for secrets, including history. Safeguard's secrets scanning is built for this, and the in-browser Gold scan covers dependencies, not secrets, so use the secrets scanner for keys.

Then replace each key you find with a scoped, expiring credential and rotate the old one. Deleting a file does not revoke a credential. The cheat sheet makes the same point: stopping a consumer alone does not revoke its credentials.

What to do

1. Inventory every API key and token your agents use today.
2. Give each agent its own identity so logs show who did what.
3. Replace static keys with tokens that expire in minutes or hours.
4. Limit each credential to one task, one repository or one environment.
5. Remove open ended tools such as raw shell access unless the task needs them.
6. Require human approval for deploys, deletions and spending.
7. Log every credential request and alert on unusual use.
8. Rotate anything that has ever appeared in a prompt or transcript.

Quick check

Sources

• OWASP Secrets Management Cheat Sheet
• OWASP LLM06 Excessive Agency
• OWASP Top 10 for LLM Applications
• GitHub Docs: About security hardening with OpenID Connect

Last reviewed: 18 October 2026.