Handling the credentials that agents and model integrations use

Four kinds of credential in an agent setup

• Model provider API keys used by the application or a gateway
• Credentials for tools and MCP servers: service accounts, API tokens, database users
• OAuth tokens the platform stores on behalf of users who delegated access
• Pipeline and workload identities that start agents, deploy them or let them push code

Each kind has a different lifecycle, so record every credential in an inventory with its purpose, owner, scope, storage location and rotation method. OWASP's Secrets Management Cheat Sheet recommends keeping exactly this kind of metadata, including who to contact and when to rotate, so a secret can be moved or replaced without detective work.

Where credentials should live, and where never

OWASP recommends a central secrets management system with least-privilege access, automated rotation and, where possible, dynamic secrets with short leases. For pipelines, GitHub documents OpenID Connect as a way for workflows to obtain short-lived cloud tokens that are valid for a single job, instead of storing long-lived cloud credentials as repository secrets. For agents, the credential should be fetched by the tool or MCP server at the moment a call needs it, so the model only ever sees the action and its result. A credential should never sit in:

• Prompts, system instructions or agent instruction files in a repository
• Tool results returned to the model
• Traces and logs, since the MCP authorization specification treats tokens cached or logged on a server as a theft risk
• Environment variables of an agent session that can run shell commands, unless the token is short-lived and narrowly scoped

One identity per agent, environment and purpose

Shared credentials turn every incident into a global one and every log line into a guess. OWASP notes that when services share the same secrets, finding the source of a leak becomes hard. Give each agent its own identity in each environment, and separate read from write credentials where the target system allows it. An MCP server that calls upstream APIs uses its own credential for them, because the specification forbids passing through the token a client sent. For machine-to-machine connections to an MCP server, the official client credentials extension recommends signed JWT assertions over long-lived client secrets.

Rotating without breaking running workflows

The sequence below assumes the target system accepts two valid credentials at the same time. If it allows only one, plan a coordinated cutover with consumers paused, or alternate between two identities if the system supports that.

1. 1

   Create the new credential next to the old one

   Both stay valid for an overlap window, with the same or a narrower scope.

2. 2

   Test the new credential before promoting it

   OWASP's rotation example for AWS Secrets Manager tests the pending credential before it becomes current.

3. 3

   Let consumers pick it up

   Workflows fetch credentials per run or per call, not once at start-up, and a long run retries once on an authentication failure before failing clearly.

4. 4

   Watch for use of the old credential

   Audit logs show which consumers still use it.

5. 5

   Revoke the old credential and confirm it fails

   A test request with the old credential should now be refused.

A hypothetical failure shows why the overlap matters. An agent run lasts up to two hours and reads a database password at start. Rotation revokes the old password thirty minutes after issuing the new one, so runs that started earlier fail halfway. Either fetch credentials per step, or make the overlap longer than the longest run, and write that duration into the rotation policy.

When a credential leaks

OWASP's incident guidance is to revoke the exposed secret immediately, rotate it through a repeatable automated process, remove it from code and logs, and use lifecycle records to see who had access, when it was used and when it was last rotated. Agents add two checks. Find out whether the credential reached a model provider through a prompt or tool result, where it may be retained according to the provider's terms and your configuration. Then review everything the agent did with the credential since the exposure began. OWASP also advises tested break-glass credentials in a separate system, in case the secrets manager itself is unavailable.

A practical next step is to build the inventory for one agent and mark each credential that is long-lived, shared or readable by the model.

Coding agent security for engineering teamsAI engineering and architecture