Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Unbuckle My 1Password Rate Limit Seatbelt!!!
1Password rate‑limiting is the kind of "enterprise security feature" that makes you want to take your laptop, walk into the sea, and let the tide solve your problems You buy the secrets management control plane (the thing that's supposed to be the adult supervision for autonomous agents) and it turns into a bouncer at your own front door going: "Whoa, whoa, mate, too many requests… come back later." Congratulations -- your "secure mediation layer" just turned into a chaos generator that makes your agent look incompetent and your infrastructure tool The one job is: **be boring under pressure**.Not "be a surprise traffic cop when the user is already dealing with rate limits somewhere else." When you rate-limit the credential plane, you're not protecting me -- you're stranding me mid‑operation with a half‑built robot and a pile of broken glass. Rate limits are fine. But if you're going to throttle, at least give a real retry-after make failures explicit and atomic don't turn normal automation into an improv comedy about authorization headers. Right now it's less "security" and more "a seatbelt that randomly punches you in the throat. Look at what Doppler offers Action Doppler 1Password Read Requests 240 to 480 per minute 1,000 per hour Write Requests 60 to 120 per minute 100 per hour Daily Hard Cap None (Usage-based) 1,000 requests per 24 hoursScopePer Project/EnvironmentPer 1Password Account I hate to say it but I might have to unlearn all my op command line knowledge and move to DopplerService Account Rate Limits: 15+ Minutes Block, No Backoff Duration Shown
Environment: - 1Password CLI (latest) - Service Account (not personal account) - Linux systemd service using LoadCredentialEncrypted - op inject to load 2 secrets at startup --- The Problem My systemd service uses a 1Password service account to inject 2 secrets at startup via op inject. While debugging an unrelated configuration issue, I restarted the service approximately 15 times over 10 minutes. This triggered a rate limit that has now persisted for over 15 minutes with no sign of clearing. The Error Message [ERROR] 2026/01/31 22:35:22 Too many requests. Your client has been rate-limited. Try again in seconds Note the blank where the number should be — there's no indication of how long to wait. Observed Behavior ┌──────────────────┬────────────────────────────────────┐ │ Operation │ Result │ ├──────────────────┼────────────────────────────────────┤ │ op whoami │ ✅ Works (authentication succeeds) │ ├──────────────────┼────────────────────────────────────┤ │ op vault list │ ❌ Rate limited │ ├──────────────────┼────────────────────────────────────┤ │ op inject │ ❌ Rate limited │ ├──────────────────┼────────────────────────────────────┤ │ op read op://... │ ❌ Rate limited │ └──────────────────┴────────────────────────────────────┘ This indicates the rate limit is applied per-operation-type — authentication endpoints work fine, but any vault/item access is blocked. Issues 1. Rate limit is extremely aggressive — ~15 requests over 10 minutes triggered a 15+ minute block. This is a typical debugging session, not abuse. 2. No backoff duration shown — The error says "Try again in seconds" but the actual number is missing. I have no idea if I should wait 1 minute or 1 hour. 3. No way to check status — There's no op rate-limit-status command or API to check current quota/reset time. 4. Service accounts should have higher limits — These are designed for automation and CI/CD where rapid retries during debugging are expected behavior. 5. Disproportionate impact — A brief debugging session can take down production services for an extended period with no recourse. Expected Behavior - Show the actual backoff duration in the error message - Faster reset — 1-2 minutes, not 15+ - Higher thresholds for service accounts — differentiate from potential abuse patterns - Rate limit status endpoint — let us query current quota and reset time - Graduated response — warn before hard blocking, or use exponential backoff instead of a cliff Workaround Wait and hope. There's no way to know when access will be restored. --- Request: Can someone from the 1Password team clarify the rate limit policy for service accounts and whether the blank duration in the error message is a known bug?
Environment Feature Request
In addition to sorting which I believe has been mentioned elsewhere, can you add the ability for either custom tags (with filter by tag) or otherwise add the ability to be able mark each variable with a place where it is needed. e.g Vercel, Convex etc. At the minute my services have access to environment variables they don't need and I want to reduce it down so they only have the essentials. It would be nice to be able to view at a glance what service has access to what. It would be particularly handy in the event any service is compromised you would know exactly which variables would need updating and across which services.
Provide disk access to SSH public keys?
Would there be interest by the 1P developers to provide easy access to any stored SSH public keys at a simple path (rather than users having to export and save them if they need them outside of the 1P environment)? I use another tool that manages SSH keys (https://github.com/maxgoedjen/secretive, a fantastic macOS app that creates and stores SSH keys in the Secure Enclave), and it provides you with the ability to access the public keys of any stored keys at a simple path, e.g.: /Users/username/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/d0aa1a9b19b0d0f9ab0c9fcc5de80fa6.pub If 1P had the same ability, then when users needed to provide their public key somewhere (e.g., https://developer.1password.com/docs/ssh/agent/advanced/#match-key-with-host), they wouldn't have to go through the cumbersome process of exporting the public key from 1P, saving it to a file, and then providing the path to that new file. Instead, I'd imagine there would be an option alongside the "Download" option in the 1P entry named something like "Copy Public Key File Path", and it would put the path on the clipboard; then the user just uses that for the IdentityFile, or whatever they needed the path to the public key for. And then the ideal would be if accessing the file at this path didn't require any 1P authentication at all, since it's a known-public-non-secret file... but in the end, at least in my example above, the public file is being accessed as part of a private key read, so there'll ultimately be authentication.
SCIM bridge deployment on Azure with private endpoint
Hi, I have setup a 1Password SCIM bridge successfully on Azure using the json template aca-op-scim-bridge-template.json. What I noticed is that the SCIM bridge is using a public URL which is also used with the Entra integration. Azure SCIM service is using the public URL and a bearer token to make connection to the 1Password SCIM bridge. I do see that it is possible to setup IP restriction on the URL but the problem is that the Azure SCIM service is using changing IP's. My first thought is using a private endpoint on the SCIM bridge and disallow public access. Does anyone already realized that? Is there a template for? Or am I thinking to difficult? Thanks in advance, WimConnect server sharing with multiple teams
I'm planning a new system architecture that will use 1Password Connect and I have a question about the security risks. Is it fair to say that anyone with root access to the Connect server can access all vaults that server has access to, even if they do not have an access token? So far I have not see any vulnerabilities without having an access token, but since the REST API is not encrypted, one could easily intercept the tokens using tcpdump. This question is relevant as we're considering how widely to share the Connect server. For example, one option is to run a single Connect server for the whole company which has access to all vaults. Each team would have their own access tokens, limited to specific vaults. This way, the server can be centrally managed by one team, which might be a more efficient use of time and resources. But some sensitive users might not accept that risk of their secrets being accessible by the system admin. So I just wanted to confirm. I'm curious how other folks run it. Do you deploy separate servers for each team or business unit? I'm also considering running it locally on each app instance that needs access, so each Connect server would have access to only the specific vault it needs.
Bug? CLI reveals SSH private keys _without_ --reveal
% op item get "$id" --format json | jq .ssh_formats {"openssh":{"reference":"op://Private/tsvm.plambert.net SSH Key/private key?ssh-format=openssh","value":"-----BEGIN OPENSSH PRIVATE KEY-----\nb3B..."}} Without the --reveal option, should it be showing me the actual private key?Cannot find "Destinations" tab for mounting secrets to local .env files
I am trying to use the feature "Access secrets from 1Password through local .env files" but I cannot find the "Destinations" tab. What I have done: Enabled "Show 1Password Developer experience" in Settings > Developer Enabled "Record and display activity" I can see and use the AWS Secrets Manager integration What I expected: According to the documentation, there should be a "Destinations" tab that allows me to mount secrets to a local .env file. What I see: The "Destinations" tab does not appear anywhere in the interface. I only see the AWS Secrets Manager integration option. Environment: 1Password version: Latest OS: Windows Account type: Individual Could you please help me understand how to access the Destinations feature, or let me know if this feature has been moved or deprecated? Thank you.
