Skip to main content
AI tools and agents are increasingly being used for tasks that require credentials like passwords, API tokens, and one-time password codes to complete. When you supply these credentials in plaintext, like by pasting a secret directly into an agentic browser when prompted to sign in, your secrets can leak into the LLM context. Storing API tokens for AI services in plaintext creates another risk. Hardcoded tokens in .env files, mcp.json files, and config files can be committed to source control or accidentally shared, allowing anyone who finds them to access your accounts. 1Password gives you secure ways to provide secrets to AI tools and agents. Store your credentials in 1Password, then load them into your AI workflows without exposing them in plaintext or allowing agents to directly handle your secrets.

The security principles guiding 1Password's approach to AI

How 1Password applies ideas like secrets staying secret, deterministic authorization, auditability, and least privilege when building and integrating AI.

​
Secure AI API keys

If you use AI services like OpenAI, Anthropic, or Google in your applications or scripts, you may have plaintext API keys stored in environment variables, .env files, or shell profiles. 1Password Environments allow you to manage your API keys and other project secrets together in 1Password, then securely load them into your code when you need them. To get started:
  1. Create an Environment in 1Password and add the API keys and other secrets your AI workflow needs as variables. If you have an existing .env file for your project, you can import it.
  2. Create a locally mounted .env file for the Environment. The contents of this file aren’t tracked by Git or stored on disk, and are only available at the moment you access it.
  3. Verify you can access your variables and make sure they work with your tools.
After you set up the Environment, remove any plaintext API keys stored in your local .env files or shell profiles (~/.zshrc, ~/.bashrc).
Local .env files are currently only supported in 1Password for Mac and Linux. You can also programmatically read project secrets from Environments on any platform using the latest beta version of the CLI or SDKs.

​
Add validation for AI-assisted coding

If you use AI coding agents in tools like Cursor, GitHub Copilot, Claude Code, or Windsurf, you can use 1Password hooks to validate that your locally mounted .env files are properly configured before the agent executes shell commands. If any required .env files are missing or invalid, the hook prevents the agent from executing and the agent provides instructions for how to fix the issue. In Claude Code and Cursor, the hook is bundled in a plugin that installs the validation hook, an Environments agent skill, and MCP server configuration together.

Create and manage Environments

Store your AI API keys in an Environment.

Access secrets through local .env files

Sync an Environment to a local .env file.

Install the validation hook

Validate locally mounted .env files before your agent runs shell commands.

​
Secure MCP server config files

MCP server configurations (like mcp.json) often include API tokens and other credentials as environment variables. Yours might look something like this:
Instead of exposing your secrets in plaintext, you can store them in 1Password, then use an Environment to securely load the secrets as environment variables at runtime. To get started:
  1. In 1Password, create an Environment and add the secrets your MCP server needs as variables.
  2. Open the Environment you just created and select Manage environment > Copy environment ID.
  3. Update your MCP config file to use op as the command, with run --environment in args wrapping your original MCP server command. Remove any hardcoded secrets from the env block:
When your MCP host starts the server, it runs 1Password CLI, which authenticates with 1Password, resolves the variables from your Environment, and injects them into the process before handing off to npx. The MCP server receives the real secret values without your secrets ever being stored in your config file. With this approach, there’s no need to re-declare your secrets in the env block. Because op run injects the variables directly into the process environment, they’re already available to the MCP server. If you need to pass additional non-secret configuration values alongside your command, you can still use the env block for those.
Some MCP hosts (like Claude Desktop on Mac) launch as GUI apps and may not inherit your shell’s $PATH. If op can’t be found, use its full path as the command value instead. For example, /usr/local/bin/op or /opt/homebrew/bin/op. You can find the path by running which op in your terminal.
You can also load your API tokens from 1Password at runtime using op run and secret references.

​
Use the 1Password Environments MCP Server

The 1Password Environments MCP Server lets MCP clients like Codex, Cursor, and Kiro create and manage your 1Password Environments directly, with a secure 1Password authorization prompt required for every action. The MCP server doesn’t read or return secrets to the AI agent. Your secrets stay in 1Password and are only accessed by authorized processes, so your MCP client can act on your secrets without ever seeing them. You can use the MCP server from your client to create Environments, list environment variable names, handle local .env files within authenticated workflows, and manage secrets within your Environments.

Set up the 1Password Environments MCP Server

Connect your MCP client to 1Password to securely create and manage Environments.

Install the 1Password plugin for Claude Code

Add MCP configuration, .env file validation, and the Environments agent skill to Claude Code.

Install the 1Password plugin for Cursor

Add MCP configuration, .env file validation, and the Environments agent skill to Cursor.

​
Keep secrets out of agent context with 1Password and NVIDIA OpenShell (beta)

1Password for NVIDIA OpenShell (beta) lets a coding agent use the credentials it needs without those credentials entering the agent’s context. You connect a 1Password Environment to an OpenShell gateway, then attach it to the sandbox where the agent runs. Inside the sandbox, the agent only ever works with placeholders. When it sends a request to a host you’ve approved, the gateway replaces the placeholders with the real secrets outside the sandbox and forwards the request. Requests to any other host don’t receive the credential. You choose how long OpenShell keeps custody of the secrets. After that window expires, the sandbox keeps running but the agent no longer gets access.

Set up 1Password for NVIDIA OpenShell

Connect an Environment to an OpenShell gateway and give sandboxed agents scoped, time-limited access to your secrets.

​
Authenticate AI command-line tools with biometrics

You can set up 1Password Shell Plugins to authenticate AI command-line tools like OpenAI CLI or Claude Code CLI using the 1Password desktop app, eliminating the need to store plaintext API keys in your shell profile or environment. When you use a shell plugin, you authenticate the underlying CLI in the same way you unlock the 1Password desktop app, like with Touch ID, Apple Watch, or a Linux system authentication option, which enables convenient human-in-the-loop approval.
Shell plugins let you configure different default credentials in different directories, so you can automatically switch between secrets for different projects without needing to take any manual action.

​
Next steps

Choose what you want to do next:

Secure local development

Access credentials in your terminal, IDE, and local projects without exposing your secrets in plaintext.

Secure your deployments

Securely load secrets into CI/CD, containers, and production apps at runtime with least-privilege access.

​
Get help

To get help, join the discussion in our Developer community or join our Developer Slack workspace.