RFC: Securely using Claude Code CLI with 1Password secrets

[lyind]

Summary

This RFC documents a secure approach for using Claude Code CLI and IDE plugins with secrets stored in 1Password on Linux.

Accompanying Claude skill: https://github.com/giantswarm/claude-code/pull/20

Key components:

• Dedicated 1Password vault with minimal-privilege service account
• Bubblewrap (bwrap) sandboxing for filesystem isolation
• op:// secret references with op run -- for just-in-time secret injection

Test plan

• Review security properties and sandboxing configuration
• Validate instructions work on a fresh Linux setup
• Consider team-wide vault vs individual vaults

🤖 Generated with Claude Code <-- already sandboxed at the time

[stone-z]

This is really two RFCs:

1. sandboxing claude (in this case, with bubblewrap)
2. using 1password in claude

I still challenge whether (2) is truly necessary. What is the actual impact currently? When are folks limited and how are they managing it?

[stone-z]

As far as the sandboxing, I think it's worth doing a review of the available tooling that might meet other goals as well. For example, it would be even better if we had a sandbox that also provided company visibility, like an audit log, tool inventory, perhaps a context filter, etc. I'm sure there's plenty of vaporware out there right now, but immediately bringing our agent presence under standardized compliance would be a great early win. A quick search turned up toolhive and nono, but there are bound to be others.

An alternative would be to shift development away from workstations altogether, with something like codespaces/devpod, and then instrument that environment.

On the secrets specifically, my preference would be a fine-grained token service to issue scoped, on-demand credentials specifically for use by the agent, but that is a big ask, and probably just some more vaporware at this point. I'd like to believe people will do the manual work of copying secrets into an AI vault, but I suspect that won't happen in practice. It might be enough of a start to first restrict the shared secrets, so each employee vault only contains their own credentials. This at least limits the blast radius to what a user would do as themselves.

Have you seen any others in the ecosystem? Would a SIG Security discussion help?

[lyind]

An additional point: I have not succeeded in getting op (1Password CLI) to run inside the sandbox without the service account token, i.e. connected to the signed-in 1Password desktop app.

So using a service account token is useful in itself, to enable op use in a sandbox.

This is really two RFCs:

I was using 1Password for all my secrets, where possible, and expect Claude to do the same. Why lower security measures?

At the same time, we found in the first related SKILL.md integration PR, that Claude can't be trusted with full 1Password CLI capabilities (blast radius). AI agents as a class of software can't be trusted with full access to a workstation, just like one wouldn't log an intern into one's own account unsupervised, on the first day of work. Thus the sandbox/container/VM.

So, following @stone-z's "blast radius" requirement, using 1Password with Claude Code depends on sandboxing and the two (1Password SKILL/service account and sandboxing script/settings) have to play well with each other/be integrated.

[lyind]

NOTE: It might make sense for 1Password to roll their own "AI sandbox with perfected secret injection" product.

It could even be just what the script does, but rolled into op itself.

[puja108]

1. /sandbox feature of Claude Code automatically uses whatever sandboxing feature is available (native on Mac, bubblewrap on Linux,...). I wouldn't reinvent the wheel here. The CC teams iterates fast on these things and is on top of latest developments at least for local setups.
2. I do think creating a 1password vault/user for your sandboxed claude code can make sense in some cases, just to be able to give it e.g. github token or other auth it might need in a controlled way.

also re:

I have not succeeded in getting op (1Password CLI) to run inside the sandbox without the service account token, i.e. connected to the signed-in 1Password desktop app.

That should be exactly the expectation, or not? When sandboxed it should NOT be able to connect to the host 1password, cause that is your personal login. It should only access its own vault. The most secure automation/claw setups I've seen recently all create special users for the AI that they then use to share passwords with, like I would share a password with my kid.

[lyind]

That should be exactly the expectation, or not? When sandboxed it should NOT be able to connect to the host 1password

Yes, it is the expectation. I still tried it out to maybe offer a fallback for users who don't setup a 1Password service account/special vault. However, it's not feasible.

[puja108]

for users who don't setup a 1Password service account/special vault

but that but be quite insecure then, or am I missing something?

[lyind]

Still more secure than using Claude Code without the password manager skill. Less secure than "sandboxed + 1Password service account". Without the 1Password service account, Claude could, if manipulated to do so, read all your secrets as it would on the filesystem.

[stone-z]

I still think it's highly unlikely that the humans are consistent enough about keeping secrets organized into meaningfully separate contexts for this to ultimately be a significant security benefit. We really would need something more dynamic and auditable

[lyind]

Is there a way to automate creation of those vaults?

A simple script run by the user or even in the sandbox script (see RFC) could perform the necessary setup, provided 1Password CLI is installed.

[TheoBrigitte]

Using op run seems the most secure option IMO, but I would rather have it configured via a PreToolUse hook, which would then rewrite the invoked command to prefix it with op run.

I am also a bit concerned about performances when running every tool call through op run which is calling 1Password over network for each command execution.

[lyind]

The linked 1Password skill PR (giantswarm/claude-code) addresses this, by educating Claude about when exactly to prefix with op run --.

[TheoBrigitte]

I don't think this belongs in a skill, it's rather specific setup/environment definition which Claude should ideally not need to know about. Claude should just be able to run commands without any overhead. I would like to avoid Claude having to additionally "think" about how it should run a command, this bring some additional complexity for the agent itself, which we could avoid IMO.

[lyind]

It could be put into a hook, as you suggested.

The hook would have to detect if the command to be run is one that requires authentication (e.g. gh).

However, for some uses of secrets (e.g. in curl commands), it's not enough to just check the command and one needs the context and some brains to decide if secrets should be provided, or not. Only the agent itself can meaningfully make that decision: thus the Skill.

[stone-z]

Is there a way to automate creation of those vaults?

My thinking was something more dynamic from the identity provider side. 1Password's XAM might also nicely support what you're trying to do

[lyind]

We haven't had a chance to evaluate 1Password's XAM and it doesn't look like we will deprecate "good old authentication schemes", for personal workstation use, anytime soon.