How should AI agents manage secrets, credentials, and identity?

An AI agent should have a **separate, identifiable, least-privilege security principal**. It should not silently inherit a developer's or administrator's complete authority.\n\nCredentials should be:\n\n- short-lived;\n- restricted to the intended service and resource;\n- limited to the minimum scopes;\n- stored in a secure keyring, vault, or workload-identity system;\n- delivered only to the tool or process that needs them;\n- rotated and revocable;\n- excluded from prompts, source files, model memory, and ordinary logs;\n- attributable to both the agent and the authorising user or service.\n\nAn inbound token for one service must never be blindly passed to another service. Each downstream service should receive a separate token issued for that audience.

Agent identity has at least two relevant principals:\n\n1. the **agent or workload identity** that performed the action;\n2. the **human, service, or organisation** that authorised or delegated the action.\n\nKeeping both identities allows systems to determine who initiated the task, which agent executed it, what authority was delegated, and which approval or policy permitted the action.\n\nNIST's 2026 agent identity and authorisation work highlights identification, authorisation, auditing, and non-repudiation as central challenges when agents receive access to data, tools, and applications.\n\nA secure credential flow follows several rules.\n\n### Least privilege and scope\n\nIssue only the permissions required for the current operation. Read and write scopes should be separate where practical. High-risk scopes can be acquired through step-up authorisation when a specific operation requires them rather than granted permanently.\n\n### Audience and resource binding\n\nA token must identify the service for which it was issued. The MCP authorisation specification requires Resource Indicators and validation that a token is intended for the receiving MCP server. This prevents a token obtained for one server from being replayed at another.\n\n### No token passthrough\n\nAn MCP server that calls a downstream API acts as a separate OAuth client. It must obtain a separate downstream token rather than forwarding the token it received from the MCP client. Token passthrough breaks audience boundaries and creates confused-deputy risks.\n\n### Secure storage and injection\n\nCredentials belong in a dedicated secret store, OS keyring, hardware-backed identity system, or managed workload-identity service. The runtime should inject a credential into the narrow tool process that needs it. The model should receive a reference or capability handle, not the raw secret value.\n\n### Lifetime and revocation\n\nUse short-lived access tokens, rotate refresh tokens, revoke compromised grants, and end session-scoped permissions when the run ends. Cache only when required and encrypt cached credentials.\n\n### Logging\n\nLog identity, scopes, resource, action, approval reference, and outcome—but redact secret values, bearer tokens, authorisation codes, cookies, and private keys. Model transcripts and tool-error messages must not echo credentials.\n\n### Development environments\n\nCoding agents should not automatically inherit the entire shell environment. Allowlisted variables, protected credential brokers, and sandbox-specific identities are safer than exposing every developer credential to every command.

- [NIST — Software and AI agent identity and authorization](https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization) — frames agent identification, authorisation, auditing, and secure action control as core deployment requirements. - [NIST — Agent identity concept paper](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd) — explains the risks created when agents receive access to diverse tools, data, and applications. - [Model Context Protocol — Authorization](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) — requires resource-bound tokens, audience validation, short-lived credentials, secure OAuth flows, and separate downstream tokens. - [Model Context Protocol — Security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) — explains token passthrough and confused-deputy risks. - [OpenAI — Running Codex safely](https://openai.com/index/running-codex-safely/) — describes storing CLI and MCP OAuth credentials in the OS keyring and binding agent use to an enterprise workspace.