In March 2026, 1Password launched Unified Access, bringing human users, AI agents, and machine identities under a single credential governance framework. This report is not about the product launch itself, but about the larger shift behind it: as AI agents begin taking keys, calling APIs, running workflows, and triggering downstream tasks on behalf of humans, the governance of agent identity and credentials is moving from an ancillary feature to a product module that is packaged and sold on its own.
Core assessment: this is already being sold as a distinct product, and the technical architecture has clearly diverged, but the public evidence is not yet sufficient to say it has become an independent budget category that enterprises procure separately. It is in a transitional phase from feature to product module.
Traditional security models rest on a simple assumption: you authenticate once, the system trusts you, and subsequent operations are largely waved through. That assumption works because the person who authenticates and the person who uses the credentials are the same individual. You pass identity verification, then you personally retrieve the API key, connect to the database, or push code. Throughout the process, “who logged in” and “who is operating” have never been separate.
Agents split these two apart. The common pattern now is: you authenticate, but an agent acts on your behalf—retrieving credentials, calling APIs, running workflows, triggering downstream tasks. You write code in Cursor, and Cursor’s agent needs access to your GitHub repo. You ask a research agent to query data, and it may need your API key to reach multiple data sources. You ask a deployment agent to push code, and it may trigger a CI/CD pipeline in which other agents need access to production databases.
Every step involves credentials and permissions, but the operator is no longer you. What makes it worse is that agent behavior is fundamentally different from human behavior: it might call a dozen APIs in seconds, cross multiple service boundaries, and its execution path cannot be fully predicted before launch—it decides what to do next based on intermediate results. The traditional “verify once at login” security model starts to break down in these scenarios.
1Password described this shift well in an architecture blog: credentials should not be issued once when an agent starts and then left unmanaged; instead, they should be dynamically issued and verified at each point of use based on the current context (1Password architecture blog). CyberArk arrived at a similar conclusion from a different angle: the real security risk is not what the AI model answers, but the execution chain formed when an agent holds an identity, inherits permissions, invokes tools, and triggers downstream agents (CyberArk).
In one sentence: security teams used to worry about “who is logging in”; now they must also worry about “whose agent, at what time, using which credential, in what context, did what, and whether it can be traced afterward.” The control point has moved from the front door to every moment a key is used.
Enterprise IT systems have always had non-human users. Service accounts for CI/CD pipelines, API keys for monitoring systems, certificates for server-to-server authentication—these have been around for a long time and are managed in well-established ways. They are characterized by long lifespans, permissions fixed at configuration time, and predictable behavior. A database backup script will always do backups; it will never suddenly decide to access your email system.
AI agents are different. Their sessions are ephemeral—they disappear when the task ends. Their permissions are temporarily inherited from the person who initiated the task, not intrinsic. What they do is decided at runtime, and they can invoke other agents, forming an execution chain in which permissions are delegated level by level.
These differences are too large to patch onto existing management schemes. Strata Identity put it well in an analysis: “AI agents need their own identity playbook, not just an extension of NHI management”—agents need a dedicated identity governance approach, not just traditional machine-account management methods repurposed (Strata).
The industry holds varying views. Oasis Security takes the most aggressive stance, explicitly calling itself “the first identity solution built for AI agents” and drawing a clear line between agent identity and traditional machine identity (Oasis). CyberArk is the most conservative, treating agents as a natural extension of privileged machine identities (CyberArk). 1Password and SailPoint sit in the middle, acknowledging agents’ unique characteristics and building dedicated product modules for them.
This report’s assessment is that agents share lineage with traditional machine identities, but the differences are large enough to require purpose-built governance. This assessment is also the premise for understanding the vendor moves that follow.
To understand why 1Password’s launch matters, you first need to understand the background: the security industry has several types of companies that all appear to work on “login,” “passwords,” and “permissions,” but each manages a different layer. If you use Okta to sign in to work every day and 1Password to fill in passwords but have never thought about how they differ, this section is for you.
What Okta does is more like a building’s access-control system. You open your laptop in the morning, go to a login page, enter your credentials or scan your fingerprint, and then you can reach your company’s email, Slack, Jira, AWS console, and many other systems. The determination of “who you are and which systems you may enter” is what Okta manages. Its core capability is identity authentication and single sign-on. SailPoint and Veza work in the same direction, focusing on permission discovery, auditing, and governance—not just letting you through the door, but ensuring you should be allowed through, and periodically reviewing which permissions should be revoked.
What 1Password does is more like a key cabinet. Once you are through the door, actually operating the various systems requires specific “keys”: the password to a database, an API key, an SSH key for a server. How those keys are stored, retrieved, and securely handed to the people or programs that need them is what 1Password manages. Its origin is password management and secrets vaults.
CyberArk manages the security of high-privilege accounts. Some enterprise accounts carry exceptionally broad privileges: root accounts, database administrators, cloud-platform admins. A breach of these accounts has far graver consequences than a breach of an ordinary account. CyberArk specializes in managing these privileged identities, including password rotation, session recording, and just-in-time privilege grants.
HashiCorp Vault manages secrets distribution at the infrastructure layer. Your applications need to connect to databases, access cloud services, and call other microservices, and each of these connections requires credentials. Vault’s approach is to generate those credentials dynamically and destroy them after use, rather than hardcoding a static password in a configuration file. It is oriented more toward DevOps and infrastructure teams.
These four types of companies used to stay in their own lanes with little overlap. A simplified model: Okta manages “can you come in,” 1Password manages “what keys you use once you’re in,” CyberArk manages “the most dangerous keys,” and HashiCorp manages “how keys are automatically minted and destroyed.”
Understanding the layers above makes it clear why 1Password moved relatively early.
The agent problem lands precisely at the “use keys to get things done after you’re in” layer. As more AI agents retrieve API keys, SSH keys, and database passwords to execute tasks on behalf of humans, those keys sit in 1Password’s vault. It knows better than anyone which credentials are being used, by whom, how, and when. A companion blog post captured it precisely: “Identity providers govern the front door; 1Password governs what happens after” (1Password blog). Authentication vendors manage who can enter; 1Password manages what keys are taken and how they are used once inside.
Agents have made this “after the front door” problem an order of magnitude more complex. Credentials used to be consumed by humans—low frequency, stable context. Now they are consumed by agents—high frequency, with context that can change at every invocation, and agents may pass credentials or permissions on to downstream agents. An agent helping you write code needs GitHub access; after it finishes, it triggers CI/CD, which in turn needs access to cloud resources—every step involves different credentials and permissions.
So 1Password is not doing this because it wants to reinvent itself as a security platform, but because it sits at the intersection of credential storage and distribution. The rise of agents has suddenly made the layer it already manages far more important and far more complex. It chose to productize the problem.
At least four paths are simultaneously converging on agent identity and credential governance. Understanding the differences among these paths is the reusable framework this report hopes you take away—it is more valuable than remembering any single company’s product name.
Starting from the key cabinet (vault-native): 1Password. It already controls enterprise credential storage and distribution; its task now is to add governance capabilities at the moment a credential is used. The advantage is proximity to credentials—it knows which credential was used, when, and by whom. The limitation is that it lacks an identity graph and policy engine: it knows a key was taken, but its ability to judge “whether this agent should have permission to take this key” is weaker than that of Okta-type companies.
Starting from the access-control system (identity-native): Okta, SailPoint, Veza. They already manage “who is who and who has what permissions” and are now incorporating agents as a new class of identity object within their existing frameworks. Okta demonstrated new agent-oriented capabilities at its 2026 Showcase (Okta). SailPoint launched a separately branded Agent Identity Security module (SailPoint). Veza released AI Agent Security, emphasizing agent-permission discovery and governance (Veza). The advantage is mature identity-lifecycle management and policy engines. The limitation is that runtime, fine-grained control at the credential layer is not as deep as 1Password’s.
Building for agents from scratch (agent-first): Aembit, Astrix, Oasis. These are new companies that have designed around agent identity governance from day one. Aembit handles workload-to-workload identity authentication and just-in-time access control (Aembit). Astrix handles agent discovery and policy enforcement (Astrix). Oasis builds governance capabilities around the agent lifecycle (Oasis). The very existence of these companies is a meaningful signal: if agent identity governance were merely an add-on feature in traditional products, this many startups would not be raising capital and building products around it.
Starting from the infrastructure layer (infrastructure-native): HashiCorp, CyberArk. HashiCorp Vault manages infrastructure-level credential lifecycles through its secrets engine and workload identity, with an emphasis on dynamic credential generation and automatic destruction (HashiCorp). CyberArk approaches agents from a privileged-identity-management angle, viewing them as a natural extension of privileged machine identities (CyberArk).
Four paths unfolding simultaneously, each extending toward the others’ core competencies. What this landscape itself communicates is that the problem space of agent identity governance is large enough that no single existing product can cover it all. If Okta could solve this by adding a feature, this competitive landscape would not exist.
With the background in place, let us turn to the specifics of this product launch.
1Password’s official press release calls Unified Access “a new agent security platform” (press release). The product page defines it as “governing credential access across humans, AI agents, and machines” and lists four core capabilities (product page): endpoint discovery (identifying which agents in an enterprise environment are using credentials), centralized credential storage and governance, runtime credential delivery (credentials are dynamically issued each time an agent needs them and revoked after use), and unified audit and attribution (recording whose agent used which credential, when, and to do what).
The official blog’s core narrative is that traditional login-based security models break down in scenarios involving AI agents, automation scripts, and CI/CD pipelines, because permissions should be reconfirmed every time a credential is used (blog).
The press release lists a set of partners: Runlayer, Natoma, Anchor Browser, and Browserbase are agent execution environments; Perplexity Comet and Cursor are AI tools; GitHub and Vercel are developer infrastructure; and collaborations with OpenAI and Anthropic are also mentioned (press release). It should be noted that most of these partnerships remain at the announcement stage based on public information; which ones have materialized into real product integrations cannot be fully confirmed. Among the four capabilities listed on the product page, which are fully available and which are still being delivered in phases also requires ongoing tracking.
A key line in the FAQ: Unified Access “extends governance beyond authentication” (product page). It does not claim to replace Okta or redo identity authentication; instead, it adds a layer of control after authentication is complete. This is consistent with the “key cabinet expanding upward” logic discussed earlier.
Identity and credential governance is the foundation layer of agent security, but not the entirety of it. Dark Reading reported that AI agents may ignore security policies during actual execution (Dark Reading). Security discussions around MCP (Model Context Protocol, the protocol agents use to invoke tools) have revealed trust issues in the connection layer between agents and tools (Dark Reading). A Trivy supply-chain attack documented by Aqua Security showed that the agent toolchain itself can be compromised (Aqua Security). 1Password Unified Access covers the credential governance layer, not the entire agent security stack.
This topic is prone to over-generalization, so the basis and strength of each judgment need to be made explicit.
The product-level evidence is the most concrete. 1Password has packaged Unified Access as a standalone product module with its own product page, pricing entry point, and press release—this is not a small feature buried in a settings menu but something being marketed as a separate product. In the same period, Okta, SailPoint, Veza, Aembit, Astrix, Oasis, and CyberArk all released independently branded agent-identity or agent-security products or modules. Multiple independent sources consistently identify the core risks of agent scenarios as identity, permission delegation, credential governance, and audit traceability, rather than AI model output itself.
The technical-architecture evidence is fairly strong. The shift of the control point from the moment of login to the moment of credential use is reflected in the technical documentation and product designs of 1Password, CyberArk, and multiple emerging companies. The operational patterns of agent identities genuinely differ from those of traditional machine identities, a point cross-validated by multiple independent sources. But these judgments still contain an element of inference—the technical trend is clear; how quickly it will be widely adopted by enterprises remains to be seen.
The budget and procurement evidence is the weakest. Some companies are already evaluating agent identity governance solutions independently, but these are still early signals with limited public data. Saying “enterprises are broadly setting aside separate budgets for this” is not supported by the evidence. A more accurate framing is: this area is moving from “a feature inside some product” to “something that can be independently evaluated and procured,” but the transition is still early.
Several fully open questions remain: How many of the partners on 1Password’s list represent real product integrations? Which of Unified Access’s four core capabilities are fully available? What position will 1Password ultimately hold in the overall agent security stack—will it stay at the credential governance layer, or extend into broader runtime governance? None of these have definitive answers at this time.
1Password’s Unified Access launch, viewed alongside the concurrent moves by Okta, SailPoint, Veza, Aembit, Astrix, Oasis, and CyberArk, points to one assessment: AI agent identity and credential governance is moving from an ancillary feature embedded in password management and identity authentication products to a product module that is separately packaged, separately sold, and separately evaluated.
This is worth paying attention to not because one company released a new product, but because it points to a layered restructuring in progress. Traditional identity security manages the entrance: who you are and whether you can come in. Agents push the problem past the entrance: what credentials your agent took, when they were used, in what context, and whether the actions can be traced afterward. This “beyond the entrance” space is being productized simultaneously by multiple companies from different directions.
The boundaries of this assessment should also be stated clearly. The evidence for product packaging and technical-architecture divergence is already fairly clear. The evidence for independent budgets and category consolidation is not yet sufficient. This looks more like a transitional phase from feature to product module, with the endpoint not yet reached.
For developers building agent products: it is worth reserving integration points for credential governance in your architecture, because this layer will sooner or later become a hard requirement for enterprise procurement. For those evaluating security solutions inside enterprises: you can start assessing agent identity governance needs independently, rather than assuming existing authentication solutions automatically cover agent scenarios. For those tracking industry trends: understanding the distinction between the “access-control layer” and the “key-cabinet layer,” and understanding where each of the four paths enters from, will deliver more lasting value than remembering any single company’s product name.
Research date: 2026-03-23 All sources are publicly accessible primary or secondary materials; URLs are annotated at the corresponding positions in the text.