Why should AI agents not hold long-lived API keys?

A long-lived API key gives an AI agent standing access that never expires, cannot be tied to one task and usually gets copied into places nobody tracks. Give each agent its own identity, issue short-lived tokens, scope them to the job, and make revoking one a routine action rather than an emergency.

What goes wrong with a pasted key?

The pattern is familiar. Someone needs an agent to call a service, so they create a key, paste it into a config file, and move on. Six months later the key is in a repository, a chat thread and a CI variable.

OWASP's Non-Human Identities Top 10 names the failure modes. Secret leakage means credentials end up in source code, plaintext config or chat tools. Long-lived secrets means credentials with distant or no expiry give an attacker lasting access once stolen. Overprivileged identities magnify the damage. Identity reuse means one key serving many components opens all of them if it leaks.

Agents make each of these easier. They run unattended, call many tools, and sometimes print their own environment into logs.

Mistake 1: one shared key for every agent

When three agents share a key, your audit log cannot say which one acted. Separate identities per agent, and ideally per environment, make the log readable and let you revoke one without breaking the others. OWASP lists environment isolation and identity reuse as separate risks for this reason.

Mistake 2: acting as a generic super user

OWASP's excessive agency guidance recommends running actions in the context of the specific user, with per-user authentication at the narrowest scope, rather than a generic high-privilege identity. If an agent summarizes mail, it should not carry a token that can delete mail.

Mistake 3: static keys where short-lived ones exist

Cloud providers have moved away from static keys. AWS guidance says to require workloads to use temporary credentials with IAM roles, and to rely on long-term access keys only where nothing else works. GitHub documents OpenID Connect so workflows can reach a cloud account without storing long-lived cloud credentials as secrets, using tokens valid for a single job.

The same idea applies to agents. Exchange the agent's identity for a token that lasts minutes, not months.

Mistake 4: no offboarding

OWASP puts improper offboarding at the top of its list: unused service accounts and keys that are never disabled. Agents are created for experiments and forgotten. Give every agent identity an owner and an expiry date.

Mistake 5: trusting the agent to enforce its own limits

OWASP recommends complete mediation, meaning authorization is enforced in the downstream system and not left to the model to decide. An instruction in a prompt is not an access control.

Where Safeguard fits

Safeguard's MCP server at mcp.safeguard.sh lets assistants and your own agents work with the platform, and tenant admins can switch off any client type. The guardrail demo below shows how a policy decides which tool calls an agent may make.

Open the full MCP guardrail demo

What to do

1. Inventory every key an agent holds. Search repositories, CI variables and chat for the ones you forgot.
2. Create one identity per agent per environment, with a named human owner.
3. Replace static keys with short-lived tokens wherever the target service supports roles or OIDC.
4. Scope each identity to the smallest set of actions the job needs, and run actions as the requesting user where possible.
5. Set an expiry and a review date. Remove identities that have not been used.
6. Log which identity called what, and alert on use from a new place or at a new hour.
7. Practise rotation: revoke one agent's access in a test and see what breaks.

Quick check

Sources

• OWASP Non-Human Identities Top 10
• OWASP LLM06 Excessive Agency
• AWS IAM security best practices
• GitHub Docs, OpenID Connect

Last reviewed: 18 October 2026.