Privacy by Editorial Team

How 1Password and NVIDIA Keep Secrets From Agents

1Password brokers agent logins so the agent never holds the password. NVIDIA's OpenShell does the same for self-hosted agents. Where both still fall short.

There is one piece of information an AI agent should never have: your password. Not a redacted sample, the real one sitting in a vault right now. The safe answer has always been to block agents from logging in at all, which works until the agent is the thing you want doing the work.

Two companies are now attacking that problem from opposite ends of the stack. 1Password sells a broker that sits between an agent and the credential. NVIDIA open-sources a runtime that never places the credential inside the agent’s sandbox in the first place. Same underlying idea, different delivery: one is a hosted service you connect consumer agents to, the other is infrastructure you run yourself.

The Broker: 1Password for Agents

1Password announced the product on October 22, describing it as a way to delegate tasks to personal agents while keeping control.

The mechanism is short. When an agent reaches a sign-in page, it authenticates to 1Password using what the company’s product page calls a “unique digital key to verify its identity to 1Password”. You see which credential is being asked for and why, and you approve or deny it on your own device. If several saved logins match, you pick which one. Then 1Password fills the credential “directly into the sign-in form instead of sending it to the agent,” as the product page puts it, so the agent never receives a reusable copy. The same page is blunt about the result: “Your agent only sees that access is granted and doesn’t see your password.” The feature is included in all Individual and Family plans.

9to5Google adds a detail worth knowing: once the site accepts the login, the credential is removed so the agent cannot read or reuse it, and the rest of the vault stays inaccessible.

Which agents this covers today is where the accounts disagree. The product page names Muse from Meta, Claude from Anthropic, ChatGPT Work and dots from OpenAI, and Grok Bot, adding that Muse and Grok Bot are “Rolling out over the coming days across all platforms.” 9to5Google reported only Muse and Grok Bot as actually working, with dots and Claude Duet still to come. TechCrunch’s write-up lists Claude Duet, dots, ChatGPT Work, Grok Bot and Muse, and adds a fifth, Town. The list is still moving.

The Sandbox: NVIDIA OpenShell

The other approach skips the broker entirely. OpenShell is described in its own repository as “the safe, private runtime for fleets of autonomous AI agents,” released under the Apache License 2.0. NVIDIA’s developer blog announced it at version 0.1.0 on September 28, 2026.

Its credential claim is blunt: “Agents never see real credentials; OpenShell adds them only to requests bound for approved endpoints.”

The substitution happens outside the agent. NVIDIA’s developer blog describes three pieces. The Sandbox executes the workload under kernel controls over files and processes, and has “no network path except through the supervisor.” The Supervisor sits outside the workload and evaluates every outbound request against policy. The Gateway manages the lifecycles and policies of many sandboxes.

When the workload needs a secret, it submits a placeholder. OpenShell checks network policy and credential binding outside the workload, swaps in the real key, and forwards the authenticated request. NVIDIA’s wording: “real credentials remain outside the agent workload and are bound to authorized requests.”

Underneath, the documentation says filesystem confinement uses Landlock, with unprivileged process identity and seccomp restrictions blocking escalation paths, both locked when the sandbox is created. Policies are written as YAML, compiled to OPA/Rego, and evaluated on each outbound request, and network policies are hot-reloadable at runtime.

For self-hosters the deployment details matter. Linux and Apple Silicon macOS are supported, Windows with WSL 2 is experimental, and Docker, Podman or host virtualization are the listed prerequisites. Kubernetes deployment requires a CNI that enforces NetworkPolicy.

The structural difference from the broker is who is in charge. 1Password decides which credential an agent may use and asks you to approve it. OpenShell lets an operator write the rules in advance and applies them whether or not the agent agrees.

Where the Argument Gets Weak

Both designs have open edges, and the sources are candid about them.

VentureBeat’s reporting on the launch notes that OpenShell’s policy prover “does not yet cover every policy feature,” that combined-permission analysis across multiple agents is still in development, and that the prover evaluates permissions before deployment rather than confirming the live sandbox enforces them. The same piece describes Sentry, a hardware component on NVIDIA’s BlueField-4 DPU in a security domain separate from the host, positioned for high-risk evaluations and red-team runs rather than ordinary deployments.

VentureBeat quotes Justin Boitano: “An agent cannot be expected to fully police its own behavior.” The same piece also quotes Ali Golshan on the verification claim: “It is deterministic. It is mathematical reasoning, so this is not LLM-as-a-judge.”

On the broker side, 9to5Google notes that some level of trust is still required. That is the honest core of the whole problem: neither product removes the need to decide which agent deserves which credential, or when.

An agent already shipping with payment access shows why scoping matters. TechCrunch reports that Anthropic’s Claude Duet runs on Claude Opus 5.5, “won’t trade securities or move money between accounts,” requires approval for purchases, can buy through Stripe Link or Shopify Shop Pay, and ships a classifier that defaults to rejecting requests for credit-card numbers or government identification. Those are vendor guardrails layered on an agent that already holds payment rails. Credential brokering narrows what the agent can reach; it does not decide what it should be allowed to do once it gets there.

What This Means

The two products answer a question that used to have no good answer: how do you give an agent real access without giving it the secret. The broker model assumes you will delegate to a consumer agent you do not control, and puts a human approval step between the agent and the vault. The runtime model assumes you control the infrastructure, and puts the secret on the wrong side of a kernel-enforced boundary from the agent entirely.

For anyone running their own agents, the runtime model is the relevant one. The mechanism is not exotic: the secret stays outside the sandbox, the workload never holds it, and a policy layer decides which endpoint a credential may reach. The instinct is older than the product: we covered IronCurtain, an open-source agent sandbox built by former Google and Stripe security head Niels Provos that assumes the agent will misbehave in February, which puts a policy engine between the agent and every tool call it tries to make. What is new is that this ships as an Apache 2.0 project with policy written in a form you can review.

The limits deserve equal weight. A static policy not yet proven to cover every feature is a boundary with gaps. A broker with no outside testing is a promise, not a measurement. Neither is a reason to skip credential isolation, or to treat it as finished.

The Bottom Line

Not letting an agent see your password is now a shipped feature at 1Password, and an Apache 2.0 runtime you can run yourself with NVIDIA’s OpenShell. Both move the secret away from the agent rather than trusting the agent to behave. Read the policy files before you trust the boundary, and treat any vendor claim you cannot test as unproven.