1Password Credential Broker is now in public preview

Every security team has tried to trace a credential access event back to a specific workload, and received nothing but a "service account." That service account probably had access to an entire vault, and its audit trail doesn’t tell you which repo triggered the request, which specific credential was accessed, or whether the workflow still has access. When an auditor asks, or an incident occurs, that's not a good place to be.

The credentials feeding those workloads are usually created for convenience: scoped broadly to avoid last-minute permission errors, stored in plaintext .env files, placed directly in CI/CD pipelines, and rarely rotated because doing it manually is slow and error-prone.

1Password Credential Broker was built to close that gap: give every workload or agent its own identity and scope its access. Every issuance event gets logged with attribution clear enough to hold up in an incident review. Today, we're moving Credential Broker from closed beta to public preview, available for all Enterprise Password Manager Business customers to start using right now.

How 1Password Credential Broker works

The foundation of our Credential Broker is Workload Identity Federation, a standards-based approach that GitHub, Google Cloud, AWS, and Azure have all adopted. When a GitHub Actions workflow runs, GitHub automatically generates a signed token that identifies exactly which repo, branch, and workflow is executing. Think of it like a digital badge: here's what this job is and where it came from.

Our Credential Broker validates that badge against a trust policy you configure, then delivers only the specific credentials that job is approved to retrieve. The workload can retrieve only the approved credential during the authorized job, without receiving standing access to the vault. We log every issuance with full attribution: the repo, branch, workflow, environment, and commit that triggered the request. Your audit log no longer reads "a service account accessed this item." It tells you exactly which workload accessed it, from where, and under which policy. Additionally, unlike a service account token that carries standing access, the organization-wide integration key is an encryption key, meaning if it were ever leaked, an attacker still couldn't access your secrets. They'd also need a valid OIDC token from GitHub, tied to a specific repo, branch, and workflow, that expires when the job ends. A leaked service account token is a breach. A leaked integration key, on its own, is a dead end.

GitHub Actions handles more than 6 billion workflow runs per month and is used by more than 90% of Fortune 100 companies. That's where most enterprise CI/CD already lives, which is why it made sense as the first official integration with our Credential Broker.

What’s available in public preview

Today's release gives admins a clean way to define policy: create GitHub organization integrations from the admin console, set the trust boundaries, and manage them over time with full context on date created, identity issuer, and claims. Developers can register and manage their own workflows, scoping connections to a specific repository, GitHub Environment, and 1Password workload without opening a ticket or waiting on IT. 1Password Credential Broker changes how credentials get to workloads, keeping them out of plaintext .env files, CI/CD pipeline configs, and anywhere else they've been sitting exposed, without adding friction to developer workflows. GitHub's Director of Product Management, Ben De St Paer-Gotch, shared why this matters for engineering and security teams:

Developers are under constant pressure to move faster, but increasingly sophisticated software supply chain attacks have made securing CI/CD pipelines more challenging than ever. With 1Password Credential Broker for GitHub Actions, engineering teams can eliminate secrets from their pipeline configurations, reducing the risk of credential theft while securely providing GitHub Actions with the credentials needed to build and ship software." -Ben De St Paer-Gotch, Director of Product, GitHub

New in this release: Custom OIDC workflows

Alongside GitHub Actions support in public preview, we're slowly rolling out a new capability in beta: custom OIDC workflows. This extends the same trust model to any workload or platform that issues its own OIDC tokens: a Kubernetes service account, other CI/CD pipelines, an AI agent framework, or workloads running in the cloud.

If you're ready to experiment with Credential Broker beyond GitHub Actions: connect any OIDC-capable platform, configure a trust policy, and 1Password handles the delivery. Credentials are delivered on-demand based on identity, not embedded everywhere. Your workload requests what it needs, proves who it is with an OIDC token, and holds the secret only for the duration of the job. No standing credentials in environments, configs, or context windows.

Credential Broker is part of the 1Password Unified Access Platform

Our Credential Broker and 1Password Privileged Access (formerly known as Apono) are both part of the Unified Access Platform, and address adjacent layers of access. Credential Broker authenticates the requester before securely delivering an approved credential. 1Password Privileged Access governs privileged access that an identity receives in a destination system, providing just-in-time and just-enough access. Together, they secure both credential delivery and Privileged Access use cases.

More than 200,000 businesses already rely on 1Password to protect their most sensitive credentials and secrets. Our Credential Broker extends that same vault, governance policies, and audit trail to the pipelines and automated workflows running alongside those teams, with no separate secrets management infrastructure to bolt on, all from the same 1Password interface they already use.

For security leaders, having machine access in the same audit trail as human access means you can prove governance wherever you're asked: to a board, a regulator, or in the middle of a live incident. You're not pulling from two systems trying to reconcile them. That full view is now in 1Password.

What's next

GitHub Actions is our first integration, but it's just the beginning.

We're working on more integrations, with additional controls for AI agents. The concerns on the mind of every security leader navigating AI adoption are usually the same three questions: who authorized this agent to access this system, what did it touch, and can you revoke it without breaking the workflow? Today, agents typically get handed long-lived OAuth tokens with no expiration and accumulate permissions over time. Our Credential Broker is being built to change that: short-lived, scoped access that expires when the task is done, with every issuance logged against both the agent and the human who authorized it.

We're building fast, and we want to hear how you're using it. Try it today and tell us what you'd tackle next.

Try 1Password Credential Broker today

1Password Credential Broker is in public preview, and available now for all 1Password EPM Business customers.

Interested in learning more about how 1Password can help you secure access for humans, AI agents, and machine workloads? Talk to us today.