Notifications
Clear all
Topic starter
22/06/2026 10:08 am
TL;DR: Long-lived secrets copied into apps, pipelines, repositories, and agent workflows create governance and audit problems that credential brokering is meant to reduce, according to 1Password. The deeper issue is that access review and secret governance assume credentials persist long enough to be reviewed, but brokered access shifts control to the moment of use.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map secret sprawl by execution surface Inventory where credentials are copied into repositories, pipelines, configuration files, service accounts, and agent workflows.
- Bind credential release to workload identity signals Require a verifiable identity assertion from the requester before any token or federated access artifact is delivered.
- 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.
What's in the full announcement
1Password's full article covers the operational detail this post intentionally leaves for the source:
- Private-beta scope and the initial GitHub Actions trust flow used to verify workload identity before release
- The brokered delivery model for credentials, tokens, and federated access across human, machine, and agent requesters
- 1Password's description of how credential requests and delivery events are logged with identity context
- The product framing that distinguishes credential brokering from upstream privilege governance in target systems
👉 Read 1Password's analysis of credential brokering for humans, machines, and AI agents →
Credential brokering for AI agents and workloads: what changes?
Explore further
22/06/2026 10:54 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Credential brokering for humans, machines and AI agents
