Credential brokering for humans, machines and AI agents

At a glance

What this is: This is an announcement about a credential broker that releases approved credentials at the time of need, with the key finding that static secrets are harder to govern than brokered access.

Why it matters: It matters because IAM, PAM and NHI teams have to govern credential delivery, auditability and trust signals across humans, workloads and AI agents, not just store secrets centrally.

Context

Credential brokering is a way to keep a credential in a protected system until a trusted requester needs it, instead of copying the secret into code, files or runtime environments. In this announcement, 1Password positions that model as a response to secrets sprawl across applications, CI/CD pipelines, cloud workloads and AI agents.

The governance problem is not just where a credential is stored. It is where access is granted, how trust is verified, and whether the delivery event is auditable when the requester may be a person, machine workload or AI agent.

Key questions

Q: What breaks when credentials are copied into apps and pipelines instead of brokered at use time?

A: Copied credentials create persistence, leakage and audit problems because the secret exists in too many places for governance to follow. Brokered delivery narrows the exposure window and makes the request event the control point, but only if the organisation can verify requester identity and retain delivery logs.

Q: Why does brokered credential delivery change IAM and PAM accountability?

A: Because the decision to release a credential becomes a distinct control event from the decision to allow privileged action in the target system. IAM teams need to own requester validation and auditability, while PAM teams still govern what the identity may do after the credential is issued.

Q: How do organisations know brokered access is actually under control?

A: Organisations know brokered access is under control when every connected provider account has an owner, a defined scope, an auditable reauthorization path, and a documented revoke process. If security cannot answer who owns the connection or how it is retired, the control surface is incomplete and the risk is still active.

Q: What is the difference between credential brokering and downstream privileged access control?

A: Credential brokering governs whether a trusted requester receives a credential or token. Downstream privileged access control governs what that identity can do inside the target system after the credential is presented. They are complementary controls, but they solve different governance problems.

How it works in practice

How credential brokering changes the secret lifecycle

Credential brokering changes the operational model from distribution to controlled delivery. Rather than placing long-lived secrets into applications, repositories or environment variables, the broker holds the secret and releases an approved credential, token or federated access artifact only when a trusted requester is validated. That shifts the control point from storage hygiene to issuance-time authorization and logging. It also narrows the number of places where a secret can leak or persist beyond its intended use. In identity terms, the broker becomes an access mediation layer between the source of truth and the requesting actor.

Practical implication: treat brokered access as a lifecycle control and define which actors are allowed to request credentials at runtime.

Why workload identity matters for GitHub Actions and pipelines

The private beta flow described here uses GitHub Actions identity signals to verify a specific workflow before issuing an approved credential. That matters because CI/CD systems often need privileged access without a human present, and static secrets in pipelines are difficult to govern once copied into job definitions, variables or logs. Workload identity lets the broker check that the requesting workflow matches the configured trust relationship before delivery. The mechanism is not just authentication. It is conditional release based on identity context and policy.

Practical implication: bind pipeline credential release to workload identity signals instead of embedding reusable secrets in build definitions.

How brokered access differs from access governance in target systems

Brokered credential delivery answers a different question from privileged access governance in the target system. The broker decides whether to issue the credential, while downstream access controls decide what the identity can do once it arrives. 1Password explicitly separates its broker from Apono, which handles privileged access in upstream systems. That distinction matters because many organisations conflate secret delivery with authorization, but they are not the same control. One governs possession of the credential, the other governs permitted action after use.

Practical implication: separate credential issuance controls from target-system privilege controls in your architecture and operating model.

NHI Mgmt Group analysis

Credential brokering exposes the limits of secret-centric governance. The central shift is from managing where credentials sit to managing when and to whom they are released. That matters because copied secrets create audit blind spots across apps, pipelines and agent workflows, while brokered access creates an issuance record that is easier to govern. Practitioners should read this as a control-model change, not just a new distribution method.

Time-of-use access is the more defensible control boundary for non-human identities. When a service account, workflow or AI agent can request credentials at runtime, the meaningful governance event becomes the brokered release, not the static storage location. This aligns closer to just-in-time access thinking for NHI, but only if request context, trust signals and delivery logs are preserved. The practitioner conclusion is that credential lifecycle and access lifecycle can no longer be treated as separate problems.

Human, machine and AI agent access are converging on the same credential fabric. 1Password is describing a unified delivery model for people, workloads and agents, which means lifecycle governance has to become actor-aware without becoming tool-specific. The same governance questions now apply across all three: who can request, what trust evidence is accepted, and what gets logged. Teams need one operating model for issuance, not three disconnected secret stores.

Brokered access sharpens the boundary between authentication and authorization. The broker verifies identity signals before delivery, but that does not replace downstream privilege governance in the target system. In practice, this means organisations should stop treating secret storage as equivalent to access control. The implication is a cleaner security architecture, but only if teams preserve the separation between credential custody, issuance policy and post-issuance privilege.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Credential brokering becomes a governance layer when secrets no longer belong in the environment that uses them. For NHI programmes, that means access review has to move upstream to issuance policy, trust signals and delivery logs, not just downstream to the systems where a secret was consumed.

Time-of-use control is the named concept this article sharpens: access should be brokered at the moment of need, not sprayed across apps, repositories and agent workflows. That changes how teams think about audit, revocation and least privilege for workloads and agents.

Brokered delivery only works if identity context is strong enough to justify release, which is why workload identity for CI/CD and AI agents matters more than secret custody alone. The programme signal is clear: keep the credential source of truth separate from the systems that need temporary access.

For practitioners

• Define brokered credential issuance policies Specify which humans, workloads and AI agents may request credentials, which identity signals are required, and which artifact types can be released for each trust relationship.
• Remove copied secrets from pipelines and repositories Inventory where credentials currently live in apps, build systems, configuration files and environment variables, then replace those copies with brokered delivery where runtime access is needed.
• Separate issuance from downstream privilege Keep the credential broker focused on trusted delivery while downstream systems enforce least privilege, session scope and privileged task boundaries.
• Log credential request and delivery events Capture requester identity, trust context, credential type and delivery outcome so access decisions can be audited across human and non-human actors.

Key takeaways

• Credential sprawl remains the underlying risk when secrets are copied into runtime environments, pipelines and agent workflows.
• The practical shift is to govern credential release as a logged event, not only to secure vault storage.
• Teams that still treat secret storage and access authorization as the same control will miss the governance gap brokered access is meant to close.

Key terms

• Credential Brokering: Credential brokering is the process of using a trusted identity proof to issue a separate credential for a target system that cannot accept the original identity natively. It is useful for compatibility, but it also becomes a control point for scope, duration, logging, and revocation.
• Time-of-Use Access: Time-of-use access is an access model in which the credential is released only when a requester presents valid identity context and an actual work demand. For NHIs and AI agents, the control boundary moves from storing the secret to governing the delivery event.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Identity Trust Signal: Any signal that helps a platform judge whether a user, account, or action is genuine enough to proceed safely. These signals can include behavioural history, device context, transaction patterns, and verification status. Strong programmes use them together, not as single-point proof.

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 building or maturing an IAM programme, it is worth exploring.