Every MCP setup guide tells you to "keep your token out of the config" — 1Password is how you actually do it. This covers the two ways 1Password and MCP fit together: using 1Password to inject secrets into your MCP configs (the recommended pattern), and the 1Password MCP server that lets an AI read your vault (powerful, but handle with care).
Why this matters
MCP servers authenticate with API tokens you put in mcpServers config — GitHub PATs, database DSNs, Stripe keys. Hardcoding those in claude_desktop_config.json or .cursor/mcp.json means plaintext secrets sitting on disk, easy to leak into git or screenshots. 1Password fixes that by resolving secrets at launch instead of storing them.
Recommended: inject secrets with 1Password (no vault access for the AI)
This keeps secrets out of your config without giving any AI access to your vault.
Option A — op:// secret references
Store the token in 1Password, then reference it in your config's env with an op://vault/item/field path. Tools that support 1Password references resolve them at startup:
{
"mcpServers": {
"github": {
"command": "docker",
"args": ["run","-i","--rm","-e","GITHUB_PERSONAL_ACCESS_TOKEN","ghcr.io/github/github-mcp-server"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "op://Private/GitHub PAT/token" }
}
}
}
No real token ever touches the file — just a reference.
Option B — op run wrapper
Wrap the server launch with the 1Password CLI so op injects env vars at runtime:
op run -- npx -y @modelcontextprotocol/server-filesystem ~/projects
This works for any MCP server that reads secrets from environment variables. Install the 1Password CLI (op) and sign in first.
This is the pattern we recommend in every server guide — see MCP security best practices. Your secrets stay in 1Password; the AI never sees the vault.
The 1Password MCP server (AI reads your vault)
Separately, community 1Password MCP servers let an AI client list vaults, look up items, create passwords and generate passphrases — via a Service Account Token:
{
"mcpServers": {
"1password": {
"command": "npx",
"args": ["-y", "onepassword-mcp-server"],
"env": { "OP_SERVICE_ACCOUNT_TOKEN": "ops_your_service_account_token" }
}
}
}
Create the service account in 1Password and scope it to a single, dedicated vault. Package names vary by implementation — vet the repo first (how to vet an MCP server).
Read this before connecting your vault
Giving an AI read access to a password manager is high-stakes. Two hard truths:
- The Service Account Token is a master key. If it leaks, rotate it immediately. Never put it in plaintext config — inject it with Option A/B above.
- Any secret the AI reads is sent to your LLM provider in plaintext, and lives in the conversation. That defeats much of the point of a vault for truly sensitive credentials.
So: prefer the injection pattern for normal use. Only use the vault-reading server for a dedicated, low-sensitivity vault, scoped read-only, and never point it at your primary vault. See MCP security best practices.
Verify
For injection (Option A/B): start a server that needs the token and confirm it authenticates — without the token appearing in your config. For the MCP server: ask "List the items in my 'AI-Sandbox' vault" and confirm only that dedicated vault is reachable.
Going further
Use 1Password to secure the tokens for every other server in your stack — GitHub, Stripe, Slack and the rest. Browse the security category, the 1Password entry in our directory, or curated loadouts.