# 1Password $500M ARR: AI Agents Drive 500% Growth in Non-Human Identities > Source: > Published: 2026-10-25 00:19:46+00:00 1Password crossed $500 million in annual recurring revenue on October 22. The number is notable. What’s more notable is why: monthly active non-human identity users — AI agents, CI pipelines, automation bots — grew 500% year over year. Human developer tool users grew 200%. The company now secures 1.3 billion credentials, human and machine combined. That 500% figure is the story. It’s a direct readout of how many developers are shipping agents into production — and how many of those agents need credentials to do their jobs. ## Non-Human Identities Already Outnumber You The Cloud Security Alliance puts the average non-human-to-human identity ratio in enterprise environments at 45:1. CyberArk’s research puts it at 80:1. In cloud-native organizations, those ratios go higher. AI agents — each with their own access needs, each spawning sub-tasks that may themselves need credentials — are pushing those numbers fast. [GitGuardian’s 2026 State of Secrets Sprawl report](https://nhimg.org/nhi-news/non-human-identity-sprawl-security-risks-2026) measured 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% year-over-year increase. AI-assisted commits leak secrets at roughly twice the rate of human-written ones. The developer reflex — paste the API key into the system prompt, check it into .env, ship it — doesn’t scale to agentic systems. Ninety-two percent of organizations say their existing IAM tools can’t manage AI agent identities. That number explains the 500% NHI growth better than any market report. ## 1Password for Agents: The Architecture Is the Point Alongside the ARR announcement, 1Password launched [1Password for Agents](https://1password.com/press/2026/october/1password-for-agents-trust-layer-personal-ai-agents) — a credential layer for personal AI assistants. The key design decision: the agent never receives the credential. When an agent needs to sign in somewhere, it reaches 1Password, which surfaces a request to the user. The user reviews it on their own device, sees exactly which credential is being requested and why, and chooses whether to approve. 1Password then fills the login form directly. The password never appears in the agent’s context window. It never shows up in a log. The underlying model never sees it. That’s a materially different architecture from “inject the secret as an environment variable and hope nobody looks.” It matters because agents log things. Agents cache context. Multi-agent systems where agent A spawns agent B create credential chains that long-lived secrets don’t handle cleanly. Launch partners include Muse (Meta), Claude Duet (Anthropic), ChatGPT Work and Dots (OpenAI), Grok Bot (xAI), and Town Townie. Microsoft Scout and Google Gemini Spark aren’t on the list — which is worth watching, since both companies have their own identity infrastructure and are likely to build competing approaches rather than defer to 1Password. ## For Teams Building Agent Infrastructure: Credential Broker 1Password for Agents solves the personal-agent-on-behalf-of-user problem. The adjacent problem — production agent pipelines authenticating to internal services — is covered by [1Password Credential Broker](https://1password.com/blog/introducing-1password-credential-broker). The Credential Broker is built on Workload Identity Federation, the same standards-based approach GitHub, Google Cloud, AWS, and Azure use. Workloads prove their identity with a signed, platform-issued credential instead of a long-lived service account password. Access is scoped per job. Credentials auto-revoke when the task ends. Every credential request gets a full audit log entry. GitHub Actions integration is available now. If you’re already using GitHub for CI and 1Password for secrets, this is the migration path off of long-lived tokens. ## What Developers Should Do Now Three things worth doing before your agents get to production scale: First, audit what your agents can currently see. If your agent’s system prompt contains an API key, or your agent runtime has access to a .env file, that credential is effectively in the clear. Most developers haven’t thought through what happens when the agent logs its context for debugging. Second, scope agent permissions to tasks, not sessions. A credential that’s valid for the lifetime of an agent process is too broad. Use dynamic secrets with short TTLs — [HashiCorp Vault, AWS Secrets Manager, or 1Password Credential Broker](https://thehackernews.com/2026/09/secrets-sprawl-is-identity-problem-that.html) all support this. An agent that can only read the database it needs, for the time it needs, is a manageable risk. An agent with a 90-day admin token is not. Third, establish an audit trail now, before you need it. When an agent acts on a credential — retrieves a record, sends an email, modifies a document — that action should be attributable to a specific agent identity, not “the service account.” Retrofitting attribution into a production system is significantly harder than building it in from the start. The 500% NHI growth number tells you how many developers are already past the proof-of-concept stage. The 92% figure about organizations whose IAM can’t handle agents tells you most of them haven’t solved the credentials problem yet. That gap is where incidents happen. [1Password’s $500M ARR](https://1password.com/press/2026/october/1password-surpasses-500-million-arr) is the market confirming the problem is real — and the solutions are starting to ship.