1Password Credential Broker Moves Agent Access to Runtime

The vault is moving closer to the work.

Many people will read 1Password Credential Broker as a secrets-management feature. That is too small. The launch moves 1Password from storing credentials to deciding when a workflow or agent should receive them.

That is the important product move. The old credential model assumed a human requested access, a system checked the policy, and the credential stayed somewhere predictable. The new model has CI/CD jobs, service accounts, cloud workloads, SaaS automations, and AI agents asking for access at machine speed. The vault still matters. It is no longer enough by itself.

The buyer problem is not only secret sprawl anymore. It is runtime access.

The launch is credential delivery, not another vault

1Password introduced 1Password Credential Broker on June 15, 2026, with private beta access starting that day and general availability targeted for late 2026. The product starts with GitHub Actions and is meant to extend later to AI agents. 1Password says the broker uses its existing vault, policy, and audit controls, then delivers approved credentials to trusted workloads when work happens.

That sounds incremental until you follow the access path.

A conventional secrets product helps teams store credentials in a safer place. A credential broker decides whether a specific requester should receive a specific credential for a specific job. The difference is where the control happens. Storage is static. Delivery is runtime.

The initial beta is narrow by design. 1Password says it covers GitHub Actions, with job-scoped access windows, item-level vault scoping, and attribution logs for credential requests. The company also notes that GitHub Actions handles more than six billion workflow runs per month. That matters because CI/CD is where secret sprawl becomes operational: tokens get copied into repositories, pipelines, environment variables, scripts, and service accounts because the work has to run.

Credential Broker changes the default from copy the secret to prove the workload.

That is a cleaner architecture. It also gives 1Password a stronger product claim than password management for humans. The company says more than 180,000 businesses use 1Password for credentials and secrets. Credential Broker tries to extend that same source of truth to machine workloads and agents, not by replacing the vault, but by making the vault active at the moment of access.

The user is the workflow first and the agent next

The most important buyer in this launch is not the human user. It is the workflow.

1Password's first supported flow is GitHub Actions. A workflow presents identity context, the broker checks the configured trust relationship, and the approved credential is released for the job. That is a concrete product primitive: workload identity, credential delivery, scoped access, and request logging.

AI agents make the same primitive more valuable. 1Password says Credential Broker will extend to AI agents later this year. The use case is straightforward: an agent needs to query a database, call an API, create a ticket, write code, or operate inside a business system. The dangerous version gives the agent a standing credential or lets the team stuff an API key somewhere the agent can reach forever. The better version gives the agent a short-lived token for a specific task and leaves an audit trail.

This is where agent access starts to look less like password management and more like privileged access management for software.

A human can be trained, challenged, offboarded, and questioned. A workflow cannot explain why a credential was copied six months ago. An agent can act faster than a ticket queue can review it. The control has to move closer to the request, or the organization ends up with a pile of orphaned permissions and a detective story after something breaks.

Runtime access is the answer 1Password is trying to sell.

Apono makes this an access-governance move

The same day, 1Password also announced the acquisition of Apono, a just-in-time privileged access governance company. Deal terms were not disclosed. The timing matters because Credential Broker and Apono solve adjacent problems.

Credential Broker answers: where does the credential live, and how does it reach a trusted requester? Apono answers: what is that identity allowed to do once access is granted, under what conditions, and for how long?

That combination matters more than the acquisition headline. A secrets vault without access governance can still become a distribution system for overprivileged actors. Privileged access governance without clean credential delivery can still inherit copied secrets, standing permissions, and unclear ownership. Together, the product shape is more coherent: one layer protects and delivers the credential; the other governs the action after access starts.

This is also why the launch belongs in the same conversation as non-human identity. The earlier CyberBiz analysis of Cisco's Astrix deal argued that discovery alone is not enough. The hard questions are ownership, access, behavior, and remediation. 1Password is attacking the same control problem from a different starting point. Cisco came from platform identity and security operations. 1Password is coming from the credential vault.

Both are trying to own the path between identity and action.

The same week filled in the rest of the stack

The 1Password launch did not arrive alone. June 15 produced a useful cluster of product announcements around AI agents, non-human identities, data access, and governance.

Delinea and Cyera announced a product integration that connects privileged access to sensitive data exposure. Cyera classifies and monitors data; Delinea correlates identities with the data they can reach. The product read is simple: not every overprivileged account deserves the same priority. The account that reaches mission-critical or regulated data should move up the queue.

Omada announced Agent Governance, a product aimed at AI agents and non-human identities. The questions are basic and powerful: what agents exist, who owns them, what can they reach, and what risk do they create? That is not glamorous. It is exactly what IGA buyers ask before they accept a new identity class.

Trust3 AI announced AgentDOS, a control plane for AI agent activity, data access, and token consumption across platforms including Databricks Agent Bricks and Microsoft Copilot Studio. That is a different part of the problem: once agents are running, teams need to see what they did, what data they touched, and what they cost.

The pattern is not subtle. Buyers are moving from agent discovery to agent control.

We now have products aimed at credential delivery, privileged access governance, identity ownership, data-aware prioritization, activity replay, token spend, and compliance evidence. Each product comes from a different vendor category. IAM, PAM, secrets management, DSPM, AI governance, and compliance automation are all reaching for the same buyer anxiety.

The anxiety is control.

Buyers should test the runtime claim

New product categories often sound larger than they are. The right buyer response is not cynicism. It is a sharper checklist.

For Credential Broker, the first question is supported requesters. GitHub Actions is a meaningful starting point, but enterprises will ask how quickly support expands across GitLab, Jenkins, CircleCI, Buildkite, cloud workloads, SaaS automations, internal tools, and agent frameworks. A broker becomes strategic when it covers the places work actually runs.

The second question is credential type. Buyers should ask whether the broker handles passwords, API keys, cloud credentials, database credentials, OAuth tokens, federated access, certificates, and service-account material with the same policy model. A product that only delivers one credential type may still be useful, but it will not become the access system of record.

The third question is blast radius. The useful outcome is not that a credential moved from one screen to another. The useful outcome is reduced standing access, shorter credential lifetime, narrower scope, and a log that connects requester, owner, task, credential, target system, and approval context.

The fourth question is revocation. AI-agent security will fail if revocation breaks production or requires manual detective work. Buyers should test whether access can be removed at the broker, the target system, the token, and the workflow level without leaving silent exceptions behind.

The fifth question is ownership. Every requester needs an owner. Every agent needs an owner. Every workflow needs an owner. If the product cannot assign and report ownership, the audit trail becomes a technical log instead of governance evidence.

That is the buyer bar.

The open question is whether brokers become platforms

The bull case for 1Password is clear: credentials are the natural starting point for unified access across humans, machines, and agents. Every action starts with trust. Every trust decision eventually touches a credential, token, session, or permission. If 1Password can broker access at runtime, govern privileged action through Apono, and keep the user experience simple, it can expand from vault to access layer.

The bear case is also real. Enterprises already have IAM, PAM, secrets management, CI/CD security, cloud IAM, DSPM, SIEM, and compliance tooling. Nobody wants a new access layer that only works in one or two workflows. The product has to integrate deeply enough to reduce operational burden, not become another place where security teams reconcile policy.

There is also an incumbent problem. CyberArk, HashiCorp, GitHub, cloud providers, IAM platforms, and PAM vendors all have reasons to protect parts of this workflow. 1Password has brand trust and human credential depth. It still has to prove it can govern high-volume machine access without becoming brittle.

That is what remains unproven.

Still, the launch is directionally important. It shows the next phase of agent security will not be solved by agent inventory alone. The market needs runtime checks: who is asking, what job is running, which credential is needed, what data is reachable, who owns the actor, how long access lasts, and what evidence remains afterward.

The vault is moving closer to the work because the work is moving away from humans.

Secret sprawl was the symptom. Runtime agent access is the control problem.