Notifications
Clear all
Topic starter
22/06/2026 10:09 am
TL;DR: GitHub Actions handles more than 6 billion workflow runs per month and is used by over 90% of Fortune 100 companies, framing runtime credential brokering as a way to remove standing access from machine workloads and AI agents, according to 1Password. The deeper issue is not secret storage alone, but the governance assumption that credentials can safely outlive the job that requested them.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
- GitHub Actions handles more than 6 billion workflow runs per month and is used by more than 90% of Fortune 100 companies.
Questions worth separating out
Q: How should security teams implement runtime credential brokering for CI/CD workloads?
A: Start by identifying jobs that still rely on long-lived secrets, then move those paths to workload identity federation with task-scoped issuance.
Q: Why do service account tokens in pipelines create so much residual risk?
A: Because they often outlive the job that created them and are broader than the task needs.
Q: What breaks when AI agents are given long-lived OAuth tokens?
A: The agent can keep acting after the original task is done, and security teams lose a clean revocation point.
Practitioner guidance
- Map every CI/CD credential to a task boundary Inventory where service account tokens, API keys, and OAuth tokens are still stored in pipeline variables or config files, then classify whether each one is tied to a single job, a reusable workflow, or a permanent entitlement.
- Replace standing vault access with runtime issuance Use workload identity federation where possible so the workflow proves who it is and receives only the credential needed for that execution.
- Separate upstream brokering from downstream rotation Confirm that reducing standing access in the broker does not leave long-lived credentials alive in the target system.
What's in the full announcement
1Password's full article covers the operational detail this post intentionally leaves for the source:
- How the private beta scopes GitHub Actions access by job, item, and environment.
- How the broker's audit trail attributes each request back to repo, branch, workflow, and commit.
- What remains unresolved in upstream systems where the destination secret is still long-lived.
- How the planned AI agent extension will log delegation chains and short-lived task tokens.
👉 Read 1Password's analysis of runtime credential brokering for machine workloads and AI agents →
Runtime credential brokering for machine workloads and agents?
Explore further
22/06/2026 10:55 am
Standing access is the governance assumption that fails first. The article describes a common pattern where a token is created for a job, then left behind because someone assumes it will be revoked later. That assumption was designed for slower, human-paced operations. It fails when machine identities and agents are provisioned and reused at software speed. The implication is that lifecycle governance must stop treating non-human credentials as if they naturally expire when the work ends.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who should be accountable when a workload or agent uses production credentials?
A: Accountability should include both the workload identity and the human or system that delegated the task. Security teams need logs that show what was requested, which policy allowed it, and which identity initiated the action. Without that chain, access review and incident response both lose the context they need.
👉 Read our full editorial: Runtime credential brokering for AI agents and machine workloads
