Question

Remove MCP support

Forum|Forum|2 months ago
May 21, 2026
9 replies
295 views

The presence of code whose only purpose is to leak secrets to AIs is a vulnerability magnet and has no utility.

Even if you are using AI for production workloads, everything should be going through a proxy that holds secrets, where a user can review every action it takes; as every single product in this category says, "AI can make mistakes" and it should not be allowed to make mistakes with sensitive data.

Any secret exposed to a model, at the very least, goes through the model provider and leaks your secrets into their logs.

I currently have the MCP server disabled in the "labs" section of the app, but its presence there is a constant source of anxiety and makes me think of migrating to Apple's passwords app every time I see it.

1P_Blake

Community Manager

Hey @glyph! It's great to see you again! 👋

The Labs toggle on its own doesn't expose anything to any AI. Turning it on doesn't connect 1Password to a model, doesn't give a model access to your vault, and doesn't surface your secrets anywhere. It just makes it possible for you to set up a connection if you choose to. Any actual access still requires you to wire up the connection on your end.

The way our MCP server is built is actually pretty close to what you described as the correct approach. Credentials stay in 1Password, the user reviews and approves every action, and the model never gets custody of the secret. 1Password injects the values directly into the authorized process at runtime, only for as long as that process needs them, so that way the secret never reaches the model, and the model provider's logs never see the secret.

Take our Environments MCP Server for Codex as an example. The model can create environments and reference variable names, but secret values aren't returned through the MCP channel, aren't surfaced in the model's context window, and aren't written to disk, all while still requiring direct authorization from you throughout the entire process.

There's more on the thinking behind this in our broader AI security principles, especially the parts about keeping raw credentials out of LLM context and using deterministic authorization rather than letting the model decide: The security principles guiding 1Password’s approach to AI

If MCP isn't part of your workflow, leaving it off is a totally fine call, and that's exactly why the toggle exists. We don't have plans to remove the feature though, because for folks who are using agentic tools this is the path designed to keep secrets out of prompts, .env files, terminals, and repos, not the path that puts them there.

G

glyphAuthor

I am a bit vague on step 8 there. How is the website "built/served" if no secrets are exposed to the LLM? The "security principles" document describes how bad it would be to grant an AWS API key to the agent, then turns around and says "If an AI agent accesses a credential to run a scheduled task, that access should be logged". Presumably if it "accesses" a credential, it gets access to the credential?

1P_Blake

Community Manager

On step 8, "built/served" is the application process running, not the model itself. When Codex kicks off something like a build/dev server, the runtime that actually executes is what consumes the secret. 1Password injects the required variables directly into that process at runtime, the runtime uses them to do its thing, and the model never holds the value.

On the "accesses" wording, I think it makes a bit more sense when you put it next to the deterministic authorization principle a couple of sections earlier.

"the LLM itself will not have direct access to credentials in a 1Password vault via the data channel of a protocol like MCP. Instead, credential exchange must follow a separate, well-defined deterministic permissioned flow."

So when the audit principle talks about an agent "accessing" a credential, it's the agent invoking that separate auth flow, not the agent holding the raw value itself. The audit principle is layered on top of that to make sure the invocation gets logged.

M

mainnine

Fed up of companies racing to implement AI features into apps, none of us want this and I'd rather have development resources spent on something worthwhile.

I

Incrementalist

@mainnine @monkBanana I completely understand the fatigue surrounding companies bolting conversational LLMs into every possible interface. However, it is important to distinguish between a tacked-on chatbot and a backend integration standard like MCP.

MCP is not an "AI feature" in the generative sense; it is a standardized deterministic protocol. Engineers and developers are already using local agentic tools to write code, manage infrastructure, and automate systems. If a password manager does not provide a secure, standardized way to handle credentials for these workflows, the default behavior will be developers leaving plain-text API keys in their local configurations, repositories, or prompt files.

By spending development resources to build this MCP server, 1Password is proactively mitigating a critical failure mode. They are ensuring that when these automated processes execute, the secrets are injected at runtime and are strictly kept out of the model's custody and logging mechanisms. From a systems and security perspective, building a secure bridge to prevent credential sprawl is exactly where development resources should be spent.

M

monkBanana

AI inclusion only detracts value from a password manager.

I

Incrementalist

@monkBanana categorizing an MCP server as "AI inclusion" misrepresents the architectural boundary. 1Password is not integrating a generative LLM into its core application or vault logic. Instead, it is exposing a standardized protocol boundary to external developer environments.

The primary value proposition of an enterprise or personal credential manager is eliminating plaintext secret sprawl. With the rapid adoption of local agentic workflows, the immediate operational failure mode is developers reverting to .env files or hardcoded tokens to bypass access friction. By providing a deterministic, runtime-injection mechanism via MCP, 1Password maintains its position as the single source of truth and tightly controls the blast radius of those external tools. Securing the perimeter of modern development workflows reinforces a password manager's core value; ignoring them diminishes it.

I

Incrementalist

I am actively planning to leverage this capability. When building local automation or defining instructions for tools like Claude Code, the most significant operational risk is secret sprawl—specifically, ending up with plain-text credentials scattered across agent configurations, .env files, or individual Skills files.

The operational reality is that agentic workflows are being adopted rapidly. Without a secure, native integration path, developers will inevitably take the path of least resistance and hardcode API keys or tokens into their local workspace just to get things working.

1Password’s MCP implementation acts as a necessary security control rather than a generative AI gimmick. By allowing the agent to reference the environment and injecting the secret at runtime—without ever pulling the raw string into the model's context window or writing it to the filesystem—it effectively neutralizes the risk of credential leakage. It keeps the blast radius contained and enforces strict epistemic hygiene for local development. For anyone managing infrastructure automation or secure pipelines, this is a highly practical feature.

Sign up

1Password employees: Sign in with SSO

Login to the community

1Password employees: Sign in with SSO