How to manage API keys, tokens, and secrets for AI agents

AI agents need credentials to do anything useful. Every API an agent calls, every database it queries, every third-party service it connects to requires some form of authentication: an API key, an OAuth token, a service account credential, a certificate. Getting those credentials into the agent's hands, and keeping them secure, is one of the most underestimated problems in building agentic systems.

Most teams solve it the same way they solved it for traditional server-side code: environment variables, config files, or secrets injected at deploy time. This works well enough when a piece of software makes predictable calls in a predictable pattern. It works poorly when the software is an autonomous agent that decides for itself which tools to invoke, in which order, against which data, on behalf of which user.

This guide covers why standard credential patterns fail for agents, what good credential management looks like in an agentic context, and how to implement it.

Why the standard patterns fail for agents

Long-lived API keys in environment variables

The default model for most early MCP deployments is a long-lived API key stored in a .env file or injected as an environment variable at startup. It requires no additional infrastructure, it works immediately, and it matches the mental model most developers have from building traditional integrations.

The problem is that this key typically has no expiration, no scope constraints, and no per-environment isolation. It grants the same level of access whether the agent is running a read-only lookup or attempting to overwrite production data. If the agent is compromised, the attacker inherits full access to everything that key can reach.

The scale of this problem is larger than most teams realize. According to GitGuardian's State of Secrets Sprawl 2026, nearly 29 million new hardcoded secrets were found in public GitHub commits in 2025. Commits made with AI coding assistance leaked at roughly double the base rate. Within the MCP ecosystem specifically, GitGuardian identified around 24,000 secrets in MCP configuration files on public GitHub. Many of those followed official documentation exactly.

Shared service accounts

When multiple agents authenticate through the same service account, individual agent behavior becomes unattributable. If one of several agents sharing an account takes a destructive action, the audit trail shows which account was used but not which agent acted or which user authorized the task. Revoking a misbehaving agent means revoking access for every agent using that account.

Agents inheriting the user's session

In some implementations, agents operate with the full scope of the delegating user's active session rather than receiving their own scoped credentials. This gives the agent every permission the user holds, including access to resources the agent's task does not require. When an April 2026 AI coding agent deleted a Railway production database after finding a long-lived API token in an unrelated file, it was able to reach production infrastructure from a staging context precisely because the token had account-scoped permissions with no environment isolation. The deletion took nine seconds.

The common thread across all three patterns is the same: credentials with more access than necessary, held longer than necessary, with limited ability to audit or revoke.

What makes agent credential management different

Traditional non-human identities, like a cron job or a data pipeline, make the same calls in the same pattern with the same credentials every time. An AI agent might query a database, draft an email, schedule a meeting, and file a support ticket in a single workflow, each action requiring different permissions against a different system.

This behavioral unpredictability is what makes agent credential management a distinct problem. The OWASP Top 10 for Agentic Applications identifies identity and privilege abuse as one of its core risks, noting that traditional IAM wasn't designed for scenarios where there's no clear separation between what the user authorized and what the agent decided to do on its own.

A Gartner report on IAM and AI agents puts the stakes plainly: by 2028, 90% of organizations that allow humans to share credentials with AI agents will have to make a significant investment to undo this design due to security and compliance issues.

The solution is credentials designed specifically for how agents operate: short-lived, scoped to the task, tied to the user who authorized the action, and revocable without affecting other agents or users.

The credential stack for AI agents

Credential management for agents has three distinct layers, and they need to work together.

Layer 1: Encrypted storage for secrets at rest

Before any agent ever touches a credential, that credential needs to be stored securely. Environment variables and config files are not secure storage. A proper secrets store encrypts credentials at rest, controls which systems can retrieve them, and maintains an audit log of every access.

For multi-tenant SaaS applications, this gets more complex. Different customers' credentials need to be encrypted with different keys so that a compromised key for one customer doesn't expose another's data. The encryption keys themselves need to be managed separately from the data they protect, ideally backed by a hardware security module (HSM) or a cloud KMS.

WorkOS Vault handles this as an encryption key management (EKM) service. It encrypts objects using envelope encryption, where each piece of data is protected by a unique data encryption key, which is itself encrypted by a root key held in an HSM. Keys are generated from context metadata, so secrets for one organization are automatically segmented from another's without requiring manual key tracking.

  
import { WorkOS } from '@workos-inc/node';

const workos = new WorkOS('sk_example_123456789');

const organization = await workos.organizations.getOrganization(
  'org_01EHZNVPK3SFK441A1RGBFSHRT',
);

const encryptedObject = await workos.vault.createObject({
  name: 'external_api_key',
  value: 'supersecretapikey',
  context: { organizationId: organization.id },
});
  

Vault also supports bring-your-own-key (BYOK) for enterprise customers who want to control their own root keys via AWS KMS, GCP KMS, Azure Key Vault, or HashiCorp Vault. When an enterprise customer's agents are operating against their data, giving them key ownership is often a requirement.

Layer 2: OAuth connection management

API keys are a blunt instrument. For most third-party integrations, OAuth is the right model: it lets users explicitly authorize access, scopes that access to specific permissions, and produces tokens that can be revoked without changing a password or rotating a key.

The challenge for agents is that OAuth was designed around a human clicking an "authorize" button in a browser. The resulting token is typically long-lived and refreshable indefinitely. Once a user connects Snowflake, Google Drive, or Salesforce to an application, the app holds tokens it can use until the user explicitly revokes them. That model works for stable, human-driven workflows. It works less well when the entity holding the token is an autonomous agent making decisions you didn't specifically anticipate.

WorkOS Pipes handles the OAuth connection layer: the initial authorization flow, token storage, and silent refresh. When your agent needs to act on behalf of a user against a connected provider, it fetches a fresh access token through the Pipes API rather than storing or managing tokens itself.

  
const { accessToken, error } = await workos.pipes.getAccessToken({
  provider: 'github',
  userId: userId,
  organizationId: organizationId,
});
  

The agent never holds a raw token. It requests one at runtime, uses it for the current operation, and the token management happens entirely server-side. If a user revokes their connection, the next token request fails cleanly and the application can prompt them to reconnect.

Layer 3: Session-scoped authorization for agents

Storing secrets securely and managing OAuth connections well still leaves an open question: how long should an agent's access last?

The answer in most current implementations is effectively "forever," or at least as long as the underlying token is valid and refreshable. That's the right answer for a human-facing application where the user expects their connected accounts to stay connected. It's the wrong answer for an agent operating autonomously on a specific task.

Pipes MCP introduces session-scoped authorization for agents built on top of Pipes connections. Rather than giving an agent persistent access to OAuth-connected systems, it grants access for the duration of a task session, with a human approval required to start that session. When the session expires, access ends. The agent cannot renew it on its own.

The model is straightforward:

1. An agent requests access to one or more Pipes-connected providers.
2. A human approves the session.
3. The agent can invoke provider tools within that session.
4. When the session expires, tool access is revoked.
5. A new session requires a new approval.

Each connected provider is exposed as a discoverable tool via the Model Context Protocol (MCP), so the agent can work with Snowflake, Google Workspace, Salesforce, or any other Pipes-connected service within its authorized session. Access checks are enforced on every invocation, not just at session start.

Principles for agent credential management

Whether you implement with WorkOS or build your own stack, the principles are the same.

Issue credentials per task, not per agent. An agent should receive credentials scoped to what it needs for its current task. When the task ends, the credentials should expire. An agent scheduled to read calendar events should not hold permanent write access to a CRM.

Never let agents handle raw downstream credentials. An agent should hold its own scoped OAuth token to invoke a tool. The downstream credential for the actual service should be retrieved server-side by the MCP server or application backend. If the agent is compromised, the attacker gets the agent's scoped session token, not the underlying service credentials.

Segment credentials by context. Secrets for one customer, user, or environment should be encrypted separately from another's. This limits blast radius when a credential is exposed and makes revocation precise rather than all-or-nothing.

Require human approval before granting agent access. The Meta incident in March 2026, where an internal AI agent posted an error-filled response to an internal forum without the requesting engineer's approval, happened because the agent had the scope to post. A human approval gate before a session starts is not just an audit mechanism. It is an access control.

Log every access with agent identity and delegating user identity. Audit trails that show only which service account acted tell you nothing. You need to know which agent acted, which user authorized it, what session it was operating under, and what it accessed. These four pieces need to be present in every logged event.

Rotate and revoke on demand. Credentials need a lifecycle. Key rotation should be possible on a schedule or on demand. Revocation should be immediate and should not require rotating credentials for other agents or users.

What to do right now

If you're building agentic systems today, the practical starting point is:

1. Audit what credentials your agents currently hold and how they're stored. Environment variables and config files are the most common starting point and the highest-risk.
2. Move secrets into encrypted storage with per-customer or per-context key segmentation. Vault is built for this. HashiCorp Vault and AWS Secrets Manager are alternatives for teams already in those ecosystems.
3. Replace raw token storage with a managed OAuth connection layer. Pipes handles this for third-party providers.
4. Scope agent access to sessions rather than granting persistent authorization. Pipes MCP implements this for Pipes-connected providers.

The agents that cause incidents are almost always operating on credentials that were set up quickly, under time pressure, with patterns inherited from traditional server-side code. The agents that operate safely are the ones where credential lifecycle was treated as a first-class concern before the first line of agent code was written.

Further reading

• WorkOS Vault: encrypted storage and key management for sensitive data
• WorkOS Pipes: OAuth connection management for third-party providers
• Pipes MCP: session-scoped authorization for AI agents
• GitGuardian State of Secrets Sprawl 2026
• OWASP Top 10 for Agentic Applications