How agents hold credentials
Authorization protocols and secrets managers that keep raw keys away from the model. Grouped by credential category: OAuth/OIDC, session token, secrets vault, cloud KMS and platform/CI secrets.
| Name | Type | Mechanism | Conf. | src |
|---|---|---|---|---|
| MCP OAuth (RFC-9728) | Authorization | Protected-resource metadata (prm.json) advertises the auth server; agent obtains scoped token before tool calls. | confirmed | ↗ |
| A2A TASK_STATE_AUTH_REQUIRED | Authorization | Agent-to-Agent task pauses in an auth-required state until the caller supplies credentials. | confirmed | ↗ |
| OIDC Federation (GitHub → cloud) | Authorization | Short-lived OIDC tokens issued by the CI provider (GitHub, GitLab) let workflows assume a cloud IAM role without any long-lived secret. The gold standard for agent-deploy pipelines that touch production. | confirmed | ↗ |
| Smithery delegated OAuth | Authorization | Write-only delegated vault, the MCP host holds the token, the agent never reads it. | research | ↗ |
| Name | Type | Mechanism | Conf. | src |
|---|---|---|---|---|
| Anthropic per-session scoped token | Session secret | Claude Cowork issues a short-lived, scoped token per session rather than exposing long-lived keys to the model. | confirmed | ↗ |
| Name | Type | Mechanism | Conf. | src |
|---|---|---|---|---|
| 1Password Secrets Automation | Secrets manager | Vault injects secrets into the runtime; the agent never sees raw values. | confirmed | ↗ |
| HashiCorp Vault | Secrets manager | Dynamic, short-lived secrets brokered to workloads with leasing + revocation. | confirmed | ↗ |
| Doppler | Secrets manager | Centralised secret store synced into agent runtimes per environment. | confirmed | ↗ |
| Infisical | Secrets manager | Open-source secret management with per-agent scoped access. | confirmed | ↗ |
| Name | Type | Mechanism | Conf. | src |
|---|---|---|---|---|
| AWS Secrets Manager | Secrets manager | Managed rotation + IAM-scoped retrieval for agents on AWS. | confirmed | ↗ |
| Cloudflare Workers Secrets | Secrets manager | Env-var-style secrets bound to a Worker at deploy via `wrangler secret put`; never returned via API. Agents on Workers read `env.SECRET_NAME` at runtime; values are encrypted at rest and injected into the isolate. | confirmed | ↗ |
| Google Cloud Secret Manager | Secrets manager | Managed secret storage with IAM-scoped access, automatic versioning, audit logs. Vertex AI Agent Builder + Cloud Run agents pull secrets via IAM without embedding keys. | confirmed | ↗ |
| Azure Key Vault | Secrets manager | Managed HSM-backed secret + key + cert store with RBAC. Azure OpenAI, Copilot Studio and Foundry Agents pull credentials via managed identity: the agent never touches the raw secret. | confirmed | ↗ |
| Name | Type | Mechanism | Conf. | src |
|---|---|---|---|---|
| GitHub Actions Encrypted Secrets | Secrets manager | Repo / org / environment-scoped encrypted secrets, decrypted only within a running workflow. Widely used by agent CI + deploy pipelines; supports scoping to protected branches / environments. | confirmed | ↗ |
| Vercel Environment Variables | Secrets manager | Encrypted env vars scoped per environment (production / preview / development). Consumed by Edge + Serverless functions running agent frameworks (LangChain, AI SDK). | confirmed | ↗ |
| Netlify Environment Variables | Secrets manager | Encrypted env vars scoped per branch / deploy context. Consumed by Netlify Functions and Edge Functions hosting agent workloads. | confirmed | ↗ |
| Kubernetes Secrets | Secrets manager | Native cluster object holding base64-encoded credentials; mounted into pods as files or env vars. The default option for self-hosted agent fleets (LangGraph on GKE / EKS / AKS). | confirmed | ↗ |
OAuth, session tokens, vaults, KMS, CI secrets: keeping the key away from the model
Engineering foundations continue to ring true with agents. Keep raw keys away from the model, hand out the narrowest scope that works, and make credentials short-lived so a leak expires on its own. This is the boring, load-bearing half of agent security. It is the layer that decides whether a single prompt injection becomes a full credential compromise or a contained, logged, revocable event.
Where should an AI agent store its API keys?
Not in the prompt. Keys belong in a secrets manager or vault, and the agent gets a short-lived token scoped to one job. Better still, broker the call so the secret is used on the agent's behalf and never enters the context window at all.
Is it safe to put an API key in an AI agent's prompt?
No. Anything in the context window can be leaked back out, and prompt injection is designed to do exactly that. Hidden instructions in a web page or email can make the agent repeat or misuse a key it can see. OWASP lists prompt injection and sensitive information disclosure among the top risks for LLM applications (OWASP).
How does OAuth work for AI agents?
OAuth lets the agent act with delegated permission instead of holding a shared master credential. It receives a token scoped to specific actions, and that token can be revoked on its own without rotating anything else. In the Model Context Protocol, the server advertises its authorization server and the agent fetches a scoped token before making tool calls (Model Context Protocol).
What is the difference between a secrets vault and a KMS?
A vault stores and hands out secrets: API keys, database passwords, certificates, usually as short-lived credentials issued on demand. A KMS manages the encryption keys that protect data, and often sits underneath the vault. For agents, the vault issues the scoped access and the KMS protects the keys behind it.
How do agents get credentials in a CI/CD pipeline?
The platform's own secret store injects them into the running job as environment values, so nothing is committed to the repository. GitHub Actions, GitLab and the cloud providers all work this way. For an agent that builds, tests or deploys, that is how a credential reaches the workload without ever sitting in code or in a prompt.