Question

Feature request: per-item authorization with item names in the prompt

5 replies
16 views

Our workflow

We run local TypeScript maintenance scripts against production. By policy our engineers have no access to our cloud provider's secret manager, so 1Password is the store of record for production secrets. A script declares which secrets it needs, and the engineer approves the read at runtime via the desktop app. Increasingly these scripts are written and executed by AI coding agents (Claude Code, Codex) running in the engineer's terminal.

The problem

The authorization prompt shows the account name and the requesting process — for us that renders as "Allow Code to get CLI access", i.e. VS Code, the app hosting the terminal. It does not say which item is being read. Combined with two documented behaviours:

authorization is per-account, not per-item, and
it "extends to sub-shell processes in that window"

…approving one read grants every subprocess in that terminal access to every item in the account until lock, timeout, or op signout.

So the engineer clicking Approve cannot tell what they are approving. We worked around it with our own dialog that lists the item titles before calling op — but that dialog is TypeScript in the same repo the agent is editing. An agent can change the displayed name while requesting a different item, or skip our code and call op directly. The consent UI is inside the blast radius, so it cannot be trusted. Only 1Password's own prompt is outside it.

The ask

Extend what the SSH agent already does to op item get / op read and the SDKs:

Per-item authorization — the SSH agent's default is already "per key, per application".
Item titles in the prompt — the SSH agent has a "Display key names when authorizing connections" setting. We want the equivalent for secret reads.

That would let us delete our custom dialog and rely on a prompt an agent cannot forge.

Overlaps with the existing request for remote/mobile approval for agentic workflows (ref CFP-19201): https://www.1password.community/discussions/developers/feature-request-remote-approval-for-op-cli--desktop-prompts-to-support-agentic-w/167877

Or: https://www.1password.community/1password-at-work-58/add-some-more-context-to-the-touch-id-modal-25134

1P_Gem

1Password Alum

Hi @nils, thanks for taking the time to share such a detailed feature request!

I can definitely understand how this would be a significant security improvement over the workaround you’re currently using. I've filed a feature request with the team, with all of the details you've provided here.

R

rogierslag

I need this for Codex too. The approval popup should explicitly show the requested account, vault, item, field and operation, and approval should grant access only to what is requested. An AI agent could optionally supply a reason, shown separately from the access details verified by 1Password.

This becomes exceptionally unclear when multiple Codex chats are running simultaneously. The popup only identifies Codex and the account, so I cannot tell which chat is requesting access or which secret it needs.

Approving access to my read-only Google Search Console API key is a very different decision from approving access to the 2FA codes for my AWS account. The popup should make that distinction clear before I approve. Showing an item name while still granting account-wide access would leave the underlying permission problem unresolved.

Trevor_1P

1Password Employee

Hi @rogierslag,

Thank you for sharing your use case! I’ve added it to the feature request as well.

G

gfsfdsjga

Please also show the `op` invocation and the requesting process's name and command line, including the parent process chain where needed to identify it, so users can distinguish agents sharing one terminal application.

I run several AI coding agents in one terminal application (Agterm on macOS), each in its own session, and they read secrets through the CLI. The authorization dialog shows only the terminal name and the account, so when a prompt appears I cannot tell which agent triggered it, let alone which item it wants.

Please label any optional caller-supplied reason, as rogierslag proposed, as such and display it separately from the process information.

Environment: 1Password for Mac 8.12.42, 1Password CLI 2.41.1, macOS 27.0.1.

T

TEC-Germany

+1 from a Business customer (IT service provider, AI coding agents and automation on a shared Windows management VM). We built a workaround on top of service accounts plus an SSH-agent signature as the human approval step, precisely because the CLI prompt cannot name what it releases. A few points that would make this complete for us: (1) The authorization must be scoped, not only displayed: one approval = one item UUID (optionally named fields), not reusable by other processes in the tree, with a short TTL. Showing a name while granting account-wide access leaves the problem open. (2) Show vault, item title, fields, requesting executable with parent chain, user/session, and a clearly separated caller-supplied reason string. (3) An admin policy (allow-list of vaults/items for CLI access, option to forbid account-wide CLI approval) and an audit entry per scoped approval in the events/usage reports. (4) Multi-user Windows hosts (RDS): the SSH agent pipe \\.\pipe\openssh-ssh-agent is machine-global, so only one session can serve it; a per-session pipe would help there as well. Please add our account to the existing feature request.

Our workflow

The problem

The ask

Related

Sign up

1Password employees: Sign in with SSO

Login to the community

1Password employees: Sign in with SSO