14 How workload and agent credentials are secured

Automated workloads like CI/CD pipelines, cloud services, and AI agents authenticate to third-party systems using secrets. These are commonly stored as long-lived service account tokens that both prove identity and unlock data. But that token is a single credential that works from anywhere (and for anyone). And revoking it won’t undo exposure. As described in “Revoking access,” once a secret is shared, the recipient can’t be forced to forget it.

1Password Credential Broker separates identity from authorization. Each workload proves its identity at runtime using workload identity federation. 1Password then enforces the policy you define and delivers only the secrets that workload is authorized to use, when it needs them, without giving it standing access to your vaults. The process builds on the same key hierarchy that already protects your vaults.

14.1 Workload identity

Rather than issue its own token, 1Password relies on OpenID Connect (OIDC) to use the identity your platform already provides. Most places you run code can hand a workload a short-lived, digitally signed token whose claims (identity attributes like repository, branch, environment, or cloud role) describe what the workload is and where it’s running.

Trust is set up in two tiers. First, an administrator creates an integration: a trust configuration with a workload identity provider, verified against the provider’s published OIDC signing keys, that sets the identity constraints everyone works within. Within those bounds, developers define the specific claims a workload must present. At runtime, the workload presents its token, 1Password checks its claims against both the integration’s minimum requirements and the developer’s conditions, and access is granted only if there’s a full match. Because the identity comes from the platform and expires quickly, no long-lived credential attests to any individual workload’s identity. There’s no durable identity credential that can be accidentally exposed in a config file or log, and every workload that authenticates leaves an audit trail.

When an administrator sets up an integration, 1Password generates an integration key. The administrator stores that key in the platform’s secrets management system, like a GitHub organization secret (which can be restricted to select repositories). Every workload in that integration uses the integration key, together with a key held by 1Password, to decrypt the secrets it’s authorized to receive. Neither key works on its own.

Dangerous bend

The 1Password Credential Broker is only as trustworthy as the provider issuing the tokens. Access scoped too broadly (to a whole account rather than a specific repository, branch, or role) widens what a compromised or misconfigured workload can reach. Scope access to the narrowest set of claims that still lets you get your work done.

While Credential Broker removes the long-lived token a workload would otherwise use to prove its identity, it doesn’t remove every long-lived secret. One remains: that integration key, created when an administrator sets up the integration and stored in the platform’s secrets management system (e.g., a GitHub organization or repository secret). Every workload in that integration can read it, and needs to read it because it’s required to decrypt the secrets they retrieve. On its own, a workload can’t decrypt anything because both it and the broker must coordinate and use their respective keys for successful decryption. A workload also needs a valid, correctly scoped identity token to authenticate to the broker before decryption occurs. The integration key still warrants protection as a high-value credential.

14.2 How brokered secrets are protected

Your brokered secrets and Environments are protected by the same vault key that protects them everywhere else in 1Password. The broker doesn’t own that key, and never stores it in a way your workload or 1Password can decrypt alone.

When you connect an item to a workload, 1Password creates a brokered configuration and two symmetric keys:

The vault key is encrypted with the client key, and that result is encrypted again with the broker key.

At runtime:

  1. The workload gets its encrypted client key from 1Password and decrypts it locally, using key material unlocked by its integration key.
  2. It verifies the enclave’s attestation, then opens an encrypted channel using the Noise Protocol Framework (specification).
  3. Over that channel, the workload sends the configuration’s identifier and the client key, which is additionally encrypted with the client authentication key (a key the broker can only access when a brokered configuration exists).
  4. The enclave checks the configuration, derives the broker key, decrypts the outer encryption, then uses the client key to decrypt the vault key.
  5. The enclave uses the vault key to decrypt only the item the configuration covers, records an audit event, and returns the secrets to the workload over the same secure channel.

Because every decryption requires a key that only exists inside the enclave and a key only your workload can supply, every access has to pass through the broker. That’s what makes runtime policy and audit logging possible. The broker is designed not to hold any key that grants persistent access to your secrets — the client key reaches the enclave for the length of a request only. The supporting services around the enclave that handle storage and routing hold no decryption keys in a form that can be used. To learn more about attestation and encrypted channels into enclaves, see About the security of 1Password confidential computing.

14.3 Revoking a workload’s access

Removing a workload’s access or deleting its integration stops the broker from serving that workload anything new. It also can’t make a workload forget secrets it already received. If you think a workload may have been compromised, rotate the secrets it could reach in the services they belong to. If the integration key may have been exposed, delete the integration and create a new one.

14.4 Cryptographic design

Access is enforced cryptographically, not only by policy. The secrets a workload retrieves can’t be decrypted without key material unlocked by its integration key. The cryptographic boundary is the integration, not the individual workload. An integration key can only be used to decrypt secrets you’ve connected to workloads in its integration. Connecting a secret is what creates the keys needed to decrypt it. For any other secret, those keys don’t exist. That boundary isn’t a permission flipped on a server.

The Credential Broker’s cryptography is designed to keep three properties intact if something goes wrong:

  • No persistent access. 1Password’s infrastructure, including the Credential Broker, is designed so it can’t decrypt your secrets on its own. Decryption always requires client-side key material supplied at runtime.
  • Containment. If a workload is compromised, you can respond yourself: remove its access and rotate the secrets it could reach. Stored brokering ciphertexts don’t become a newly valuable target, even if an integration key were to be compromised, because they can’t be decrypted outside the broker.
  • Least privilege. A workload can only reach the secrets its access conditions allow. The integration key is shared across the integration, so what distinguishes one workload from another is the identity it presents at runtime. Every time a workload requests its secrets, it needs a current OIDC token from its provider. 1Password checks that token’s claims against the integration’s requirements and the brokered configuration before releasing anything.