Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Forum Discussion
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 ...
1P_Blake
Community Manager
Community ManagerHey 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.
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
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.
