1Password sent out their August developer roundup this week. Environments is GA. Credential Broker is in public preview. There's a Cursor integration in the marketplace now. And their own survey says 71% of developers don't know which agents are using credentials, while 47% have watched an agent do something they didn't intend after reading untrusted content.
They're naming real problems. We agree with the diagnosis. We just don't think a password manager, even one that's adding agent features fast, is the right place to fix them.
We built 1Claw because agents need a different contract than humans. Not "here's the secret, good luck." More like: you get permission to do a specific thing, the credential stays on our side, and we log every attempt.
What 1Password actually shipped
Worth being fair here. 1Password is moving quickly.
- Environments gives you a proper home for developer secrets instead of a forgotten
.envon your laptop. Developer Watchtower will even scan for local env files and offer to move them. - Credential Broker (preview) issues scoped creds for GitHub Actions: specific repo, branch, workflow run. Not a shared service account that lives forever.
- Cursor integrationinjects secrets at runtime so you don't hardcode keys in the project.
All of that helps if your threat model is "humans and CI jobs shouldn't leave secrets on disk." Environments fixes the classic "I meant to delete that .env" problem. Credential Broker tightens up GitHub Actions. The Cursor plugin keeps keys out of git.
Autonomous agents are a different consumer though. They don't grab a secret once and run a script. They loop. They call tools. They sit inside LLM context windows. Anything they touch can end up in chat history, tool output, or a poisoned README that tricks them into exfiltrating it.
Where password managers hit a wall
1Password was built for people typing passwords into browsers. The developer tools extend that: central storage, inject when a trusted tool asks. That works fine when the consumer is predictable. A GitHub Action runs, uses the cred, exits. A CLI command reads a value and moves on.
Agents aren't predictable. Three things break:
- The secret can leak into the model.Runtime injection still puts the value in the agent's world. It can show up in context, get echoed in a response, or get pulled out by prompt injection. Injecting your Stripe key into Cursor doesn't help much if the model repeats it back or follows instructions buried in a README.
- There's no real agent identity.Credential Broker scopes to a GitHub workflow. That's CI. An agent running in a Cloud Runtime, an OpenClaw deployment, or a LangChain pipeline needs its own ID, its own policies, and its own audit trail. Not a shared vault item borrowed from a human.
- Storing the string isn't the hard part.Agents sign transactions, run GraphQL mutations, hit databases, call cloud APIs. You need to control what they're allowed to do with a credential: which addresses, which chains, how much per day, simulate before sign, get a human to approve the big ones. A password manager gives you the string. It doesn't govern the action.
What we built instead
1Claw isn't a password manager with an AI toggle. It's a vault and agent governance layer. The question we keep asking in design reviews is: what happens when an LLM has programmatic access?
Agents are principals, not vault readers
Register an agent and it gets its own identity: API key, SSH keypair, optional signing keys per chain, short-lived JWT. Scopes come from policies you write, not a blanket unlock. No policies means no access. Agents can't widen their own guardrails or create policies for themselves.
Compare that to handing an agent a 1Password item from a human vault. It inherits whatever that item allows. No per-path restrictions, no tx guardrails, no token revocation when you change a policy.
Execution Intents: access without copies
Our Execution Intents let agents call HTTP, GraphQL, Postgres, Redis, gRPC, cloud SDKs through bindings you configure. The agent sends an intent ("call Stripe with these params"). We inject the credential server-side, check host and path allowlists, return the response. The agent never sees the API key. The secret never enters its process or context window.
Intents API: signing without the key
For on-chain stuff, the Intents API signs server-side (or inside Shroud's TEE) with guardrails you set: allowed chains, destination allowlists, per-tx caps, daily limits, token restrictions, optional Tenderly simulation first. With intents_api_enabled, direct reads of private keys and SSH keys are blocked. The agent has to go through the signing proxy.
Shroud for LLM traffic
1Password's Cursor plugin injects secrets into your workflow. Shroud sits between the agent and the LLM inside a confidential VM. It redacts secrets from prompts and responses, flags injection attempts, enforces model and budget limits, and can sign inside the enclave. If something tries to exfiltrate a vault path or echo a credential, it gets blocked before the model or the user sees it.
MCP with exfil blocking
Both 1Password and 1Claw plug into Cursor via MCP. The difference is what happens on the way back. Our MCP server defaults to blocking responses that would leak a secret path or credential into model context. Scoped JWTs, auto vault discovery, token refresh. Setup guides: Cursor, MCP.
Side by side
| Capability | 1Claw | 1Password |
|---|---|---|
| Built for | AI agents + dev teams | Human password management |
| Agent identity | First-class principals, scoped JWTs | Human vault items injected into tools |
| Default posture | Deny all, explicit policies per path | Human grants access to items |
| How secrets reach the consumer | Proxy execution (agent never sees cred) | Runtime injection |
| LLM context protection | Shroud redaction + MCP exfil block | Depends on integration |
| Transaction signing | Intents API, 6 chains, guardrails, simulation | Not available |
| HTTP / GraphQL / DB execution | Execution Intents + binding guardrails | Not available |
| CI scoped credentials | Agent policies + OIDC federation | Credential Broker (GitHub preview) |
| Developer .env management | Vault env vars + CLI pull/push/run | Environments + Watchtower |
| Cursor | MCP (exfil block default) | Marketplace plugin |
| Policy engine | Glob + Cedar + OPA + tx conditions | Vault permissions |
| Audit | Hash-chained, tamper-evident | Activity log |
| Risk detection | Risk engine, honeytokens, DPoP | Watchtower (human accounts) |
| Human approval on risky actions | Consensus policies, HITL on tx/sign/execute | Not agent-specific |
| Encryption | HSM (GCP KMS) + optional MPC/CMEK | AES-256-GCM |
| Free tier for agents | Yes (2 agents, 3 vaults, Intents API) | Individual plan |
When to use which
Most teams will end up with both. Different tools for different consumers.
| Use case | Better fit |
|---|---|
| Team password vault for humans | 1Password |
| Browser autofill, family sharing | 1Password |
| Move .env off disk for human devs | 1Password Environments or 1Claw env vars |
| Scoped creds for GitHub Actions | 1Password Credential Broker |
| Autonomous agent calling APIs | 1Claw (Execution Intents) |
| Agent signing on-chain txs | 1Claw (Intents API) |
| LLM proxy with redaction | 1Claw (Shroud) |
| Cursor / Claude Desktop / MCP | 1Claw MCP |
| Provisioning agents for end users | 1Claw Platform API |
| Human approval before big agent actions | 1Claw |
That 71% visibility gap
1Password's survey said most developers can't tell which agents are using credentials. Runtime injection doesn't fix that by itself. You hand over the secret and hope the consumer behaves. We tried to close the gap in the infrastructure:
- Every secret read, execution, and signature goes into a hash-chained audit log. Verify it with
GET /v1/audit/verify. - Change a policy and active JWTs for that agent die immediately.
- Execution events log every binding call: success, error, guardrail denial.
- Shroud activity shows flagged requests and blocked exfil attempts as they happen.
- Honeytokens flag when someone reads a canary path. Next auth attempt gets a critical risk verdict.
Getting started
If you're looking at 1Password's developer tools for AI work, consider starting agent-native instead of retrofitting a password manager:
- Create a vault. Store secrets at paths like
api-keys/stripe. - Register an agent. Attach policies for only what it needs.
- Connect via MCP for Cursor/Claude, or Execution Intents if it should call APIs without seeing keys.
- Turn on Shroud if the agent talks to LLMs.
- Set guardrails on signing and execution before production.
FAQ
Is 1Claw a 1Password replacement?
For human passwords? No. Keep 1Password for that. 1Claw is for when the thing using your secrets is an autonomous agent: scoped access, proxy execution, signing, LLM inspection. Lots of teams run both.
Does 1Claw replace Environments?
For human devs moving .env off disk, either works. We also do production/preview/dev scoping, org shared vars, runtime injection for Cloud Runtimes. For agents specifically, Execution Intents are the better fit because the agent never gets the value.
What about Credential Broker?
Credential Broker is CI-native: scoped creds for GitHub Actions. Our agent model is broader. Any autonomous agent gets its own identity, policies, guardrails, audit trail. For CI we also do OIDC federation so relying parties validate JWTs against our JWKS without static API keys.
Can I use 1Claw with Cursor?
Yes. MCP server, works with Cursor, Claude Desktop, VS Code, anything MCP-compatible. Per-agent JWT with path-level permissions, exfil blocking, audit on every tool call. Setup guide here.
What about their AI security research?
Off-by-1 Labs showing LLMs fail at patching is useful. It confirms you can't trust the model to self-police. Our bet is infrastructure: don't give the agent the secret, enforce guardrails server-side, simulate before signing, inspect LLM traffic in a TEE. The model will mess up. Make the mess harmless.
Wrapping up
1Password is fixing real problems: .env files on disk, overprivileged CI creds, friction in AI-assisted coding. Their own numbers show the harder part though. Agents do unintended things. Visibility is bad. Injecting a secret at runtime doesn't keep it out of the model.
If you're building agents that need programmatic access to secrets, signing keys, and external services, you want agent governance, not a password manager with a Cursor plugin. That's what we built 1Claw for.
Get started for free · 1Password alternative · Cursor setup · MCP server · Agent docs