Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Show the requested credential
I'm heavily using 1password now for agentic usage. All of my business is set up on it now, and all of my credentials are locally using op://, or service accounts. I've put in a lot of effort to try and isolate systems using least privilege, but one problem is that when agents (or applications) request a credential from the system, it doesn't say WHAT credential is being requested. Half the time it doesn't even say the correct name for the application making the request, either. This is a big problem, because I'm starting to get into the habit of just spamming "Accept" blindly. But the whole reason I have set up this whole pipeline is so I can catch malicious programs trying to gain access - for example, supply chain attack infections. Without seeing what credential is being requested, and the process information that is requesting it, I'm finding it's not actually adding much protection at all, because it's putting me into a false sense of security and promoting bad habits. If I'm running multiple agents in parallel, which is often the case, it might just say "Terminal requests access to your vault" or something similar. Which terminal is that? What is the underlying entity being requested? What credential? What is the process ID or terminal title, so I can isolate it to a terminal/agent? Etc. I think this is something that urgently needs to be added. Otherwise, as it stands, it's not really offering much protection because users will just go "oh, it's probably just that agent running - I'm sure it's fine" and accept everything. If that agent happened to have installed a malicious npm package, you'd probably catch it too late.
Can't share a vault with a Guest
Hi everyone, I'm hoping someone in the community has run into this before, because I've exhausted what I can try on my side and I'm still waiting on a reply from Support and Success. The situation: I invited a client to my Business account as a Guest. He accepted the invitation, created his account, and I confirmed his access. His status is now Active and he is not assigned to any vault. However, every time I try to add him to a vault, I get this error: Failed to add person to vault. An unexpected error occurred. Error Code: 400 What I've already checked / tried: I'm the only team member on the account and I hold owner/administrator permissions, so I have full rights to manage vaults and people. The guest is not assigned to any other vault. Tried adding him from the vault side (Manage Access) and from the person side (People → user profile → Vaults). Both fail with the same error. Deleted the user entirely and re-invited him from scratch. He accepted again, I confirmed him again, and the error persists. Tried a different browser and an incognito window — same result. Has anyone seen this before? Is there something I might be missing, or a workaround that's worked for you? Thanks in advance for any pointers.
How to customize the suggested item name in the auto-save prompt?
Hello. When a user saves a new login on our site (e.g. app.acme.io), the "Save in 1Password" prompt defaults to a name derived from the domain so we get "Acme" instead of "acme.io". It doesn't match our brand. We've already done what compatible-website-design recommends: brand-name <title>, application-name, apple-mobile-web-app-title, og:site_name, manifest.webmanifest (name / short_name), correct autocomplete attributes. None of these influence the suggested name. Questions: Is there a client-side mechanism (meta tag, well-known endpoint, JSON-LD…) we're missing to declare our brand name for the auto-save prompt? If not, what's the official process to submit a domain + brand name + logo to 1password Rich Icons / website database? Thanks.1Password Passkeys not usable in Chromium-based browsers
I’m running into an issue with 1Password Browser Extension and passkeys on Linux and MacOs. Its just not useable anymore. The option “Save and sign in with passkeys” is greyed out. 1Password never appears in passkey login flows. I have the issue on MacOS and Linux with Vivaldi and Chrome. Different machines and different browser but chrome based. With Firefox it works. What I’ve already tried Reinstalling the extension Reconnecting the desktop app Used nigthly builds Installed older chrome versions No change. Can someone help please. Thanks!
1password crazy high cpu usage on blank Chrome page.
Hello! Recently I have noticed my macbook air has been running crazy hot when Chrome was open. The battery was going blank craz fast. After taking a look at chrome task manager i noticed that one of my extensions is using crazy cpu power. 1 empty chrome tab open nothing else. I started uninstalling my addons and after uninstalling 1password my cpu usage plumeted to almost none. Has anyone else noticed this behaviour? I have removed the addon now and my temps are back to normal.
Chrome Extension - Blank
A quick one ... Running Chrome 147.0.7727.56 (Official Build) and this is what happened after the upgrade to this Chrome version. The Chrome extension no longer show anything and removing and re downloading the extension has not resolved the issue. Firefox and Safari (the later which I dislike as a browser and don't use at all) works. Thanksop item get --format json returns CONCEALED field values without --reveal flag
Hi, We are using the 1Password CLI heavily in scripted and AI-agent workflows where command output is captured into logs. Today we discovered a behavior in op item get that surprised us, and we'd like to confirm whether it is intentional or a candidate for change. What we observed We ran the same item retrieval six different ways against a CONCEALED field on a test API Credential item we created specifically for this verification: | # | Command | Returned the secret value? | |---|---|---| | 1 | op read "op://<vault>/<test-item>/credential" | YES (as designed) | | 2 | op item get "<test-item>"` (default text format, no --reveal) | NO — output: credential: [use op item get ID --reveal to reveal]` | | 3 | op item get "<test-item>" --format json (no --reveal) | YES — JSON output included "value": "<plaintext>" for the CONCEALED field | | 4 | op item get "<test-item>" --fields credential (no --reveal) | NO — output: [use op item get ID --reveal to reveal] | | 5 | op item get "<test-item>" --fields credential --reveal | YES (as expected — --reveal was passed) | | 6 | op item get "<test-item>" --reveal | YES (as expected --reveal was passed) | The surprise is #3: --format json silently returned the plaintext value even though no --reveal flag was passed. The text format (#2 and #4) clearly conceals the value with the message [use op item get ID --reveal to reveal], which strongly implies that --reveal is required to see the value. JSON output behaves differently. Why this matters to us Many agent and scripting workflows use --format json for parseability. A developer or AI agent might reasonably: Read the documentation, see that --reveal is needed to expose secrets Write op item get <id> --format json expecting metadata only Pipe the output to a JSON parser Inadvertently leak the secret value into logs, conversation context, or downstream tools We discovered this in the context of investigating a credential-exposure incident where an AI agent was capturing tool output into conversation logs. We ran the test against a throwaway test credential to verify the behavior before drawing any conclusions. The text-format default was safe; the JSON format was not. Our questions Is --format json returning plaintext for CONCEALED fields without --reveal an intentional design choice? If yes, what is the rationale? The asymmetry between text and JSON output is what surprised us. If intentional, would you consider documenting it more prominently? The current op item get documentation does not (as far as we can tell) warn that JSON format bypasses the --reveal requirement that the text format implies. If unintentional, would you consider concealing values in JSON output too (e.g., omitting the value field for CONCEALED fields, or replacing it with a sentinel like `"value": "<concealed>") unless --reveal is explicitly passed? Secondary feedback (lower priority) op read always returns the value to stdout. This is documented and we understand it is the command's purpose. But for AI-agent contexts, it would be useful to have a --check or --exists mode that verifies a path resolves without fetching the value. (Workaround: `op item get` with the vault/item portion of the path resolves the existence question without exposing the value, as long as we don't use --format json — see issue above.) op item list` is correctly metadata-only. We tested this exhaustively and confirmed it does not return values. However, the metadata it returns (item names, IDs, vault names, edit timestamps) is sensitive reconnaissance data in agent contexts. Could you consider adding a --minimal or --counts-only mode that returns just count: N for the matched query without surfacing item names? This would let workflows verify that a credential exists in a given vault without enumerating the inventory. op run masking is excellent and we love it. The automatic <concealed by 1Password> replacement on stdout/stderr from wrapped subprocesses is the gold standard. We've made op run the canonical pattern for any subprocess that needs credentials in our workspace. The --no-masking flag is correctly an opt-in rather than the default. Thank you for the careful design here. What we are doing in the meantime We have updated our workspace policy and AI-agent rule files to: Treat op item get --format json as a value-leaking command, on par with --reveal Use op run --env-file=<file> as the default credential injection pattern Use op read --out-file <path> whenever a credential needs to land on disk, never piping op read to stdout Never use op item list or any enumeration command in tool-output-capturing contexts We would still very much like your guidance on item #3 specifically, JSON format silently returning concealed values is the behavior that most worries us, because it is the easiest one to get wrong by accident. Thanks
