Forum Discussion

glyph's avatar
glyph
New Contributor
1 hour ago

Remove MCP support

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.

feature request
macos

2 Replies

  • glyph's avatar
    glyph
    New Contributor
    6 minutes ago

    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's avatar
    1P_Blake
    Icon for Community Manager rankCommunity Manager
    24 minutes ago

    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.