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

Excerpt shown under the publisher's RSS terms · 116 words · full text and figures are on the publisher's site