Here's a moment that comes up in nearly every compliance review: a security engineer pulls a list of IAM roles in the AWS environment. The list is long. Some roles were created for a migration project that closed two quarters ago, a few belong to contractors who haven't worked there in over a year, and others are attached to agentic identities without any way to see which human they were acting on behalf of. There's no ticket to clean them up, no alert when the access outlived its purpose, and no record of who approved it in the first place.
That's standing access in practice; that long list of overprovisioned IAM roles is simply the product of how access has always been provisioned. Admins create it when the work starts, then rely on someone else to clean it up when it's done. But the cleanup rarely happens. The gap between the access granted and the access that's actually needed becomes the gap that shows up in audit findings, and that attackers learn to exploit.
That problem has grown harder to manage as AI agents have joined human engineers in operating on production infrastructure. Agents don't request access through a ticket queue. They act continuously, respond to changing inputs, and can be steered in ways that static standing permissions were never designed to contain. Governing agents with the same legacy PAM tools built for human logins carries the risk forward instead of containing it.
That’s why we're introducing 1Password Privileged Access. It brings Cloud infrastructure can change by the hour. New services get spun up, roles get reshuffled, and permissions get layered on top of permissions that admins might not even remember granting. The access control systems built for that environment were mostly static: provision once, review occasionally, and hope nothing drifted too far in the time between.
That mismatch created a familiar set of problems. Engineers waited on tickets to get access they needed immediately, while security teams struggled to answer basic questions such as: who has access to what, why they have it, and whether it’s still needed. Standing privileges began to pile up, and with them, the blast radius of any single compromised credential increased.
At any meaningful scale, the overhead of managing those privileges becomes a full-time operational burden: running reviews, tracking down access that outlived its purpose, and coordinating cleanup across AWS, Kubernetes, and databases with no shared policy layer between them.
The stakes are even higher when that standing access sits next to sensitive data. Caris Life Sciences, a precision medicine and AI TechBio company operating under HIPAA, had to confront this as their data footprint expanded across hybrid on-prem and AWS environments. Researchers needed access to specific S3 buckets (or sometimes individual folders within those buckets) but the controls available to them were blunt.
"Due to the sensitive nature of Caris data, our team required a solution that enabled secure access to the S3 buckets in AWS, as well as access to the folder level for more granular segmentation," said Ronen Niv, Sr. Director of Engineering at Caris. With just-in-time, precisely scoped access replacing standing permissions, Caris reduced the time researchers spent waiting for access by 99%. "Knowing that access will be provided in minutes keeps workflows on track," Niv said. "The efficiencies gained have been remarkable."
1Password Privileged Access governs access across three areas where standing privilege tends to accumulate and can do the most damage if left unmanaged:
**Access Discovery **maps every identity and existing permission across cloud and hybrid environments: AWS, Azure, GCP, Kubernetes, hybrid infrastructure, and databases. It surfaces dormant accounts and permissions that are broader than the work actually requires, giving security teams a clear starting point for eliminating standing access.
**Runtime Privilege Orchestration and Dynamic Guardrails **replace standing permissions with access created at the moment it's needed. When an engineer requests access to an AWS IAM role, a database, or a Kubernetes namespace, 1Password Privileged Access creates that access directly in the native policy language of the target system, not through a session proxy or a bastion host. The access exists for the duration of the session and is deprovisioned automatically when the work is done. No standing role is left behind.
The approval model is built around context, not just identity. Every request factors in who is asking, what environment they are touching, and how sensitive the resource is. Low-risk requests clear automatically by policy. Higher-risk requests route to a human reviewer. Engineers submit from wherever they already work – Slack, the CLI, Teams, Jira, or an MCP server – without adding a new tool to the flow. The access model changes, but the way engineers work doesn't have to.
AI Agent Privilege Control extends the same model to AI agents. Agents typically inherit the standing access of whoever deployed them. These are permissions sized for a human workflow, not scoped to a specific automated task. An agent running a data pipeline doesn't need access to your entire secrets vault, and a copilot handling customer queries doesn't need write access to production infrastructure. However, without explicit governance at the agent level, that's often what they get, because the tools that govern human access weren't built with agents in mind.
Our AI Agent Privilege Control capability gives every agent a distinct identity and a role scoped for its specific task, provisioned at request time and deprovisioned when a task is complete. It also validates declared intent against actual actions in real time so that if an agent deviates from its stated purpose, access is restricted or revoked before the action executes. Agents can take on more operational work without the access surface expanding alongside them.
Together, these capabilities operationalize a principle that's easy to phrase but has historically been hard to enforce: access should be temporary, specific, and tied to the work being done.
Identity security has always been fragmented. The tool that stores your credentials doesn't govern what those credentials are allowed to do in the systems they connect to. The tool that provisions access doesn't know what secrets were issued to complete the work. Each layer is managed separately, audited separately, and governed by teams who can't see what the other is doing.
We've been building toward a different model. Enterprise Password Manager is the credential store, serving as the vault that manages the secrets authenticating human identities across the organization.
Put more simply, Credential Broker governs what secret an identity receives to connect to a system. Privileged Access governs what that identity can do once it's connected, and for how long, including in systems that don't use traditional credentials at all. They solve different problems, but together, they close the full access stack.
The result is one trusted vendor governing every dimension of access across humans, AI agents, and machine workloads, without requiring organizations to rip and replace the IAM infrastructure they already have. That's the direction identity security needs to go. With 1Password Privileged Access, we now have the complete set of pieces to get there.
Want to see 1Password Privileged Access in action? Book a demo to learn how Infrastructure Guard, Privileged Cloud, and Agent Privilege Guard can bring zero standing privileges to your organization.