Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Moltbot Agent Secrets & Access Management
So the 1Password blog has a new post https://1password.com/blog/its-moltbot by Jason Meller about the new AI Agent hotness, Moltbot. In it he discusses how AI Agent access management should work, and the dangers of keeping keys in plaintext. It reads mostly as a theoretical treatise of how things should work in an ideal world. But it's unclear how much of what he talks about is actually possible currently. I know 1Password has some sort of Enterprise Agent access management features they're working on, but I'm not familiar with that side of things, and am uncertain if or how those would apply to a local personal project like Moltbot. How can we best use 1Password for managing Moltbot's access to secrets? Is it something possible with current features, and you just need to improve documentation to make it clear for this use case? Do you need to add additional functionality to 1Password to make it work? Do you need to contribute to the Moltbot project itself to add the integration? Is that something you're planning on doing?Service 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.
op run fails with "deleted or archived" error when resolving item by name, but op item get works
1Password CLI Version: 2.32.0 OS: macOS (Darwin 25.1.0) Shell: zsh Problem: When using op run with an env file that references items by name, it fails with: [ERROR] could not find item GitLab in vault Employee, because it has been deleted or archived However, the item exists and can be accessed by name with other commands: # This works fine: op item get "GitLab" --vault Employee --fields token # This also confirms the item exists: op item list --vault Employee | grep GitLab # Returns: qf...bq GitLab Employee 3 weeks ago Reproduction: 1. Create secrets.env: GITLAB_TOKEN=op://Employee/GitLab/token 2. Run: op run --env-file=secrets.env -- env | grep GITLAB 3. Error occurs despite the item being accessible via op item get. Workaround: Using the item ID instead of the name works: GITLAB_TOKEN=op://Employee/qf...hq/token Expected: op run should resolve items by name the same way op item get does.CLI Slow Performance
I have the 1Password desktop app installed and up to date on my macBook Pro, the `op` CLI is also installed, up to date, and working properly. All expected CLI queries work but they are surprisingly slow. After a bunch of trial and error, it seems that it is making a round-trip online as part of every single CLI query. I added the --debug flag and I can see cache hits, but the round trip online is still occurring. Disabling the network interface causes all queries to fail. Is it possible to get the 1Password CLI working fully offline to avoid all of this unnecessary round-trip business? Surely with the desktop app installed and CLI integration turned on, there has to be a way to make efficient (and offline) use of my 1Password vaults. Otherwise automation tasks that require secrets are simply too cumbersome to handle with 1Password, and I will require a secondary solution. And in that case, I may as well give up on 1Password.Environments in Production via 1Password Connect Servers
I love Environments in my local development, it makes things an absolute breeze! Now for the inevitable stretch goal: I'd love to have something similar for my production setup using 1Password Connect Servers. Perhaps a thin client that can be part of a Docker stack, which can reach out to the Connect Server and provision an ephemeral environment file on the production server. Preferably in multiple formats (.env, YAML, TOML, JSON etc.)🔊 Securing Cursor agentic development with 1Password Environments
Today we announced a new integration between 1Password and Cursor that helps reduce credential exposure during AI-assisted development. With the new 1Password Environments Hook Script for Cursor, teams can use 1Password Environments to make required secrets securely available to Cursor workflows, only when authorized and only when needed during development. The Hook Script validates that the correct environment setup is in place, while 1Password remains the secure source of truth for secrets, tokens, and credentials referenced by your project’s .env configuration. Secrets are made available at runtime via 1Password, governed by the same vaults, policies, and permissions your team already relies on. How it works (high level) When a Cursor agent needs to run a command or perform an action that requires access to API keys, tokens or credentials: Before Cursor runs any shell commands, the 1Password Environments Hook Script is invoked. The script verifies that required locally mounted .env files from 1Password Environments are present and available. If everything checks out, the script allows the command to run. If not, it returns context specific instructions for how to fix the setup. When a process requests access, 1Password prompts you to authorize and then makes the required secret available in memory for the runtime session. Get started If you’re experimenting with Cursor or rolling out AI-assisted development workflows across your team or organization, this integration gives you a safer way to enable agents to assist your developers. Read the full announcement: “Bringing secure, just-in-time secrets to Cursor with 1Password” Explore the 1Password Environments documentation for Cursor Hooks Learn more about Cursor Hooks for security and platforms teams Questions, feedback, or early learnings? Reply here, we’d love to hear what you build.
Environments with custom text file
So nice, I discovered the feature as I was about to develop a custom solution around 1Password CLI! Mounting a file is definitely the best path forward to get people to migrate to proper secrets management for local dev. Got some issues when used for the `.dev.vars` of a Cloudflare Worker project, but I'd bet that's a bug in `@cloudflare/vite-plugin`. What would be really awesome is to be able to have arbitrary text file stored securely in 1P and mounted at their destination. While the `.env` format covers most of our uses cases, we do have secrets in other formats like json files and a few other. this could be helpful for secrets in code source as well this would also help with people wanting to preserve their original .env formatting
