Feature Request: Per-application authorization policy for the SSH Agent

Context

I use the 1Password SSH Agent for three things with different trust levels: pulling/pushing git over SSH, signing git commits with an SSH key, and opening interactive SSH sessions to production servers.

I also run an AI coding agent (Claude Code) as one of the applications with access to my SSH key. It only ever needs to git pull. It should never sign a commit on my behalf, and it should never open an SSH connection to a server.

Problem

The only control over prompt frequency (Settings → Developer → Advanced → "Ask approval for each new") is one global setting shared by every application. I currently keep it on "application and terminal session" – the strictest option short of "request", per the docs – specifically so that no single app gets standing access. In practice this means opening or resuming a coding session in the desktop app triggers a manual approval click – there's no terminal in the app's own UI; that label is just how 1Password categorizes the shell process running underneath – and this gets tiring fast. I can't loosen the setting for my normal daily tools without also loosening it for the agent.

There's a second, more serious issue than the clicking, and I've now confirmed it by testing rather than just reading the docs.

What I tested and confirmed (2026-09-09)

Round 1 – "application and terminal session"

I approved a single SSH agent prompt at the start of a Claude Code session (triggered by an automatic git fetch). For the rest of that Claude Code session – I'm using "session" here for the terminal session I could observe, not making any claim about how 1Password itself scopes what counts as one internally, since that's exactly what I couldn't pin down – there were no further prompts at all: the agent signed a git commit with the same key (op-ssh-sign), and separately authenticated to two remote hosts over SSH in a row (a ProxyJump hop plus the target host). One click covered three operations of very different sensitivity.

Per your own docs, a grant covers "a specific application, including all of its subprocesses" – that's a documented design decision, and it alone explains why op-ssh-sign and two chained SSH host authentications, all descendants of the approved process tree, inherited the grant without a further prompt. The prompt itself also names only the application("Claude") and the key ("MacBook"), not the operation or destination.

The same dialog also offers "Approve for all applications" – a one-click escalation with the same limited information, and that one is unambiguously a UI choice rather than a protocol constraint.

Round 2 – "request"

Switched to "request" – a recently added option, and the strictest one documented (no session is meant to be established; every request is asked for individually) – and repeated similar operations in the same repo.

Every cryptographic operation on the key got its own prompt, with no exceptions in what I measured: one for git commit -S, one each for two separate git ls-remote calls against the same remote about a minute apart – including a literal repeat of the identical command, which still re-prompted – and two for a single SSH connection through a host reached via ProxyJump (one prompt per hop). Prompt count matched operation count exactly; nothing was silently covered this time, unlike round 1. This one-prompt-per-hop count held up consistently across applications: a plain ssh connection through a second, unrelated terminal app also produced two prompts, and so did an SFTP connection through an IDE.

One finding mattered more than the round-2 result itself, though: there's a recurring background operation that also uses the key. By checking the app's own log file, I found the desktop app itself refreshes the current git ref of every open coding session roughly every 10 minutes, and each refresh authenticates through the SSH agent – covered silently under a looser setting once the initial grant is approved, but generating its own prompt every ~10 minutes per open session under "request" (8 succeeded and 37 failed over one day, across sessions, independent of anything I or an agent explicitly did). This operation is invisible from the repository itself – it's run with a flag that skips writing any local fetch record – so nothing about it shows up by inspecting .git.

Request

1. Let the authorization policy ("ask approval for each new …") be set per application or per key, not only globally. This would let me pin an AI agent or any other automated/CLI tool to "per request" – or even a standing deny – while keeping a looser mode for my own interactive terminal and IDE.
2. Distinguish signing from authenticating in the prompt and in how a grant is scoped, at least where that's already determinable – a commit-signing request uses the SSHSIG format, with its own magic preamble and namespace field, specifically designed to be unmistakable from an SSH authentication signature. So approving a pull doesn't have to also mean approving a commit signature under the same key.

The underlying need: a way to let an AI coding agent pull from git without ever being able to sign commits or SSH into a server under my key, without having to babysit every one of its key uses.