Credentials for AI agents: managing keys, tokens and identities safely

By Wladimir Neuberger · Updated 27 Oct 2026

Why credentials are especially sensitive with agents

An agent acts with the permissions it is given. Its credentials therefore determine how large the damage of a mistake or attack can become. The OWASP list for agentic applications covers this as “Identity and Privilege Abuse” (ASI03). According to Giskard’s summary, agents often lack a distinct, governed identity, their permissions change dynamically, and it is exactly this attribution gap that can be abused.

A hypothetical example: a scheduling agent uses an employee’s personal account because that was the quickest to set up. If a crafted calendar entry redirects it, it acts with everything that account may do, and the target system’s log shows only the employee’s name. Who did what can then hardly be told apart.

Its own identity instead of shared accounts

The following points are our recommendation. They follow the principle in OWASP’s guidance on excessive agency (LLM06:2025) of limiting permissions to what is necessary and executing actions in the context of the specific user with minimum privileges, for example through OAuth with narrow scopes.

• One agent, one identity: every agent gets its own service account or key, never a person’s account and never a shared administrator account.
• No reuse: the same credentials are not used across several agents, environments or purposes. That keeps it visible who acted, and a revocation affects only one agent.
• On behalf of the user: where an agent works for a person, it should use that person’s narrowly limited authorisation rather than an all-purpose key that can do more than the user.
• Check in the target system: whether an action is allowed is decided by the connected system, not by the language model. OWASP advises implementing authorisation in downstream systems rather than leaving it to the model.

Tightly scoped and short-lived

The OWASP Secrets Management Cheat Sheet requires that secrets carry only the minimum privileges their purpose requires. It also recommends using dynamic secrets where possible to reduce credential reuse, and rotating secrets regularly so that stolen credentials only work for a short time.

• Minimal in scope: read instead of write, one mailbox instead of all, one database table instead of the whole database. The MCP security guidance warns against granting broad permissions up front, because a stolen token then does more damage and is harder to revoke.
• Short lifetime: credentials that expire after minutes or hours are worth less to attackers than permanent ones. Secret managers such as HashiCorp Vault can generate time-limited credentials for a service and revoke them automatically when the lease expires.
• Per task instead of permanently: an agent that needs write access only occasionally gets it for that task and gives it back afterwards.
• Plan for expiry: the agent must handle an expired key cleanly, for example by requesting a new one, rather than crashing or falling back to a spare key with more privileges.

Secrets do not belong in prompts, context or logs

Anything in a model’s context can be output by the model and can be coaxed out by attackers through clever input. On the “System Prompt Leakage” risk (LLM07:2025), OWASP writes that sensitive data such as credentials and connection strings should not be contained in the system prompt. The system prompt should be considered neither a secret nor a security control. Such information should be externalised to systems the model does not access directly.

• The tool holds the secret, not the model: the agent calls a tool, and the tool authenticates itself. The model never sees the key, only the result.
• Not in source code and configuration: the OWASP cheat sheet lists hardcoded secrets in source code and in Docker ENV/ARG instructions as things to avoid, and discourages environment variables because they can show up in logs and system dumps.
• Never log them: secrets should not appear in logs unless encrypted or masked. Also check error messages and tool responses that might echo keys back.
• Filter responses: keys that appear in responses are masked before they reach the context or the log. This is our recommendation and does not replace keeping keys away from the model.

A key in the prompt is a key the agent can reveal. Keep credentials where the model cannot read them.

Vault, rotation and traceability

The OWASP cheat sheet recommends centralising the storage, provisioning, auditing, rotation and management of secrets. For agents that means using a secret manager instead of spreading keys across files and chat histories.

• Central vault: a secret manager stores keys, issues them to services and knows their life cycle. Access is limited per secret; not every employee and not every agent sees everything.
• Rotation: keys are renewed regularly and after any suspicion. Dynamic secrets, which the vault creates and deletes itself, take over that work.
• Audit: the cheat sheet requires recording who requested, used, updated or expired a secret, and protecting the logs against tampering.
• Think about pipelines: the cheat sheet advises treating CI/CD tooling like a production environment. Minimal privileges and rotation apply there too.

When a key has leaked

Plan for the worst case before it happens. GitHub’s guidance on exposed secrets is clear: consider any leaked secret immediately compromised, and the most important step is revoking it with the secret’s provider. The OWASP cheat sheet likewise calls for immediate revocation of exposed keys.

• Revoke before cleaning up: first block the key with the provider. If you fear downtime, GitHub’s guidance allows creating a new secret with the same permissions first, switching the application over and then revoking the old one.
• Replace: issue a new key through an automated process and enter it everywhere the old one was used.
• Do not stop at deleting it from code: according to GitHub, removing it from the code, pushing a new commit or recreating the repository does not prevent the secret from being exploited. It may also remain in the history.
• Check for misuse: after the switch, look in the audit logs of the provider and platform for unauthorised use of the key while it was exposed.
• Practise the kill switch: the way to stop an agent and block its credentials must be known and tried out beforehand. This is our recommendation.

Frequently asked questions

Sources

• OWASP Cheat Sheet Series — Secrets Management Cheat Sheet
• OWASP GenAI Security Project — LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project — LLM06:2025 Excessive Agency
• Giskard — OWASP Top 10 for Agentic Applications 2026: Security Guide (u. a. ASI03 Identity and Privilege Abuse)
• GitHub Docs — Remediating a leaked secret
• HashiCorp — Vault Validated Designs: Dynamic secrets management
• Model Context Protocol — Security Best Practices (Abschnitt „Scope Minimization“)

This assessment rests on the publications listed. Check the original source before making decisions.

Keep reading

• Permissions and approvals for AI agents: avoiding excessive agency
• MCP security: how to protect AI agents and their tool integrations
• Cyber security in the age of agents: what changes when AI acts on its own