Credential brokering for humans, machines and AI agents

At a glance

What this is: 1Password Credential Broker is a private-beta capability that brokers credentials, tokens, and federated access at request time for humans, machines, and AI agents.

Why it matters: It matters because IAM and NHI programmes need to separate where credentials are stored from how access is delivered, or secret sprawl and audit gaps will keep growing across pipelines and agent workflows.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read 1Password's analysis of credential brokering for humans, machines, and AI agents

Context

Credential brokering separates secret storage from secret delivery. Instead of copying long-lived credentials into code, pipelines, configuration files, and agent workflows, the broker verifies a trusted requester and releases only the approved access artifact at the moment work needs to happen.

That shift matters for identity governance because the control problem is no longer only who can see a secret, but which actor type is allowed to request it, under what trust signal, and with what audit trail. The post is fundamentally about NHI governance, with direct implications for machine workloads and AI agents as well as human access.

For teams already dealing with secret sprawl, the issue is not theoretical. The same credential can be exposed in repositories, reused in pipelines, or inherited by service accounts, which means governance must move from static distribution to controlled delivery and traceable use.

Key questions

Q: How should security teams reduce secret sprawl in CI/CD and agent workflows?

A: Security teams should first identify every place a credential is copied, cached, or embedded, then remove the highest-risk duplicates before tuning rotation. The strongest pattern is to keep the secret in one protected source and release it only at request time under a trusted identity signal. That cuts exposure windows and improves auditability.

Q: Why do long-lived credentials create more governance risk than brokered access?

A: Long-lived credentials can be reused across systems, inherited by workflows, and exposed in logs or code, which expands the identity blast radius. Brokered access narrows that window by tying release to a verified requester and a specific moment of use. The result is better control over where the credential travels and who receives it.

Q: What do security teams get wrong about secret management?

A: Teams often treat secret storage as if it were the same as access governance. Storage protects the credential at rest, but it does not answer whether the requester was trusted, whether the release was justified, or whether the downstream privilege was still appropriate. Those are separate controls and should be reviewed separately.

Q: Who should own brokered credential delivery in an identity programme?

A: Ownership should sit with identity and security teams jointly, because brokered delivery affects secret protection, workload identity, and audit evidence at the same time. IAM owns the policy model, security owns the exposure risk, and platform teams usually own the workflow integration. Clear ownership prevents brokered access from becoming another unmanaged integration.

How it works in practice

Credential brokering versus secret storage

Credential brokering is a delivery model, not just a vaulting model. A secret store keeps credentials protected until something requests them, but a broker adds policy, identity verification, and delivery control before the credential is released. That distinction matters because it reduces the number of places where a long-lived secret can be copied, cached, or accidentally logged. In this model, the credential may still exist centrally, but the access decision happens at request time rather than at provisioning time. This is especially relevant for CI/CD systems, service accounts, and agent workflows where the requester is not a human browser session.

Practical implication: map which credentials are still being copied into runtime environments instead of brokered at use time.

Trusted identity signals in GitHub Actions and workload access

In the initial flow described by the vendor, GitHub Actions identity signals are used to verify a specific workflow before release of an approved credential. That means the control plane is not just secret storage, but verification of the workload identity attached to the request. This is a familiar pattern in workload identity governance: the requester proves who it is, the broker checks that proof against an allowed trust relationship, and only then issues the limited access artifact. The security value comes from narrowing both the identity surface and the time window of exposure.

Practical implication: require workload identity checks before release of any pipeline credential, token, or federated access artifact.

Auditability when credentials are delivered at the point of need

Brokering credentials changes the evidence model as much as the access model. Instead of trying to infer which application or workflow used a secret from scattered logs, the broker can record the request, the requester identity context, and the delivery event together. That creates a more defensible access trail for human, machine, and agent use cases. It does not eliminate downstream privilege risk, but it does improve the ability to prove which actor received which credential and under what trust relationship. For governance teams, that is the difference between guessing and tracing.

Practical implication: treat broker logs as part of access review evidence, not just operational telemetry.

NHI Mgmt Group analysis

Credential brokering is the right response to secret sprawl, but it is not the same as access governance. The vendor is addressing the credential foundation, not the upstream entitlement question. That distinction matters because many organisations still confuse secret distribution with privilege control, even though one governs where the secret lives and the other governs what the identity may do. Practitioners should treat brokered delivery as a control on exposure, not as a complete access model.

Static secret distribution is now the structural weakness, not just a hygiene issue. Modern environments copy credentials into repositories, pipelines, configs, and agent workflows because those systems were designed around convenient reuse, not controlled delivery. That pattern creates identity blast radius: one credential can move across multiple execution surfaces before anyone notices. The implication is that secret governance must be designed around constrained release, not simply better storage.

Workflow identity and human identity cannot be governed with the same evidence assumptions. A browser login produces a different audit pattern from a GitHub Actions workflow, and an AI agent may request access in a way that never maps cleanly to a person-centered approval model. This is where NHI governance becomes the baseline for broader identity operations. Teams should use the broker as a forcing function to separate actor type, trust signal, and access evidence.

Common credential source of truth is now a category requirement, not a product feature. The market is converging on systems that can broker access from a protected foundation instead of scattering secrets across execution environments. That shift will accelerate scrutiny of lifecycle controls, delivery logs, and workload identity binding because buyers are no longer looking only for storage. Practitioners should expect credential governance to become more operationally coupled to runtime identity proofing.

Identity blast radius: The useful concept here is the distance a single credential can travel once it leaves its protected source. The farther that secret spreads across code, pipelines, and agents, the harder it becomes to prove provenance, scope, and intended use. Practitioners should measure that spread as a governance risk, not just a secrets-management metric.

From our research:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• That is why the Guide to the Secret Sprawl Challenge is the right next step for teams trying to reduce copy-paste credential risk across pipelines and workflows.

What this signals

Credential brokering is becoming the architectural answer to secret sprawl, but only if organisations treat delivery control as separate from entitlement control. The next phase of identity governance will be built around where credentials are released, not just where they are stored. Teams that already struggle with scattered secrets should expect brokered delivery and workload identity binding to become baseline requirements rather than specialist enhancements.

Identity blast radius: As credentials move from static distribution to point-of-use delivery, the real metric becomes how far a secret can travel before it is revoked or traced. That matters for AI agents and CI/CD workflows because both can consume credentials repeatedly without the friction of a human login. A programme that cannot measure this spread will continue to underestimate exposure.

Our research shows 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as very concerned, according to The 2024 State of Secrets Management Survey. That level of concern reflects a structural problem, not a tooling preference, and it is why brokered delivery plus lifecycle evidence will matter more in future IAM reviews.

For practitioners

• Map secret sprawl by execution surface Inventory where credentials are copied into repositories, pipelines, configuration files, service accounts, and agent workflows. Prioritise the paths that combine broad reuse with weak audit evidence, then remove duplication before changing rotation policy.
• Bind credential release to workload identity signals Require a verifiable identity assertion from the requester before any token or federated access artifact is delivered. Start with CI/CD workflows that can present trustworthy runtime signals and then extend the model to other machine identities.
• Separate brokered delivery from downstream privilege approval Use the broker to decide whether a credential may be released, and use target-system governance to decide what that credential can do once issued. Keep those decisions distinct so exposure control does not get mistaken for entitlement control.
• Make credential delivery logs part of access review evidence Capture requester identity, release time, and approved scope in a form your IAM and audit teams can review. That evidence is most useful when it is tied to actual runtime delivery rather than retrospective reconstruction from scattered logs.
• Reduce the number of long-lived secrets in agent workflows Replace embedded credentials with brokered or federated access where possible, especially in workflows that can be triggered repeatedly by code or automation. The goal is to remove secrets that persist longer than the task that needs them.

Key takeaways

• Credential brokering reduces secret exposure by shifting delivery to the moment of need, but it does not replace downstream privilege governance.
• Secrets copied into repositories, pipelines, and agent workflows create a larger identity blast radius than most review processes are designed to handle.
• Teams should pair brokered access with workload identity verification and auditable delivery logs if they want meaningful control over NHI and AI agent credential use.

Key terms

• Credential Broker: A credential broker is a control layer that releases credentials, tokens, or federated access only after verifying the requester and the request context. It reduces secret copying by shifting access from static distribution to point-of-use delivery, which improves auditability and narrows exposure windows.
• Identity Blast Radius: Identity blast radius is the amount of access exposure created when a single credential, token, or account is reused across multiple environments. It grows when secrets are copied into code, pipelines, and agent workflows, making it harder to trace usage, revoke safely, or contain misuse quickly.
• Workload Identity: Workload identity is the runtime identity used by software, pipelines, and services to request access without relying on shared human credentials. In governance terms, it ties a non-human actor to verifiable signals that can be checked before issuing a token or secret.
• Point-Of-Use Access: Point-of-use access means a credential is delivered only when a trusted actor needs it, rather than stored broadly in the environment. This reduces persistence, limits accidental disclosure, and creates a clearer link between the request, the requester, and the delivered artifact.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Password: 1Password Credential Broker and secure credentialing for humans, machines, and AI agents. Read the original.