Runtime credential brokering for AI agents and machine workloads

At a glance

What this is: This is 1Password's analysis of runtime credential brokering for machine workloads and AI agents, with the key finding that standing credentials and broad service-account access remain the main governance problem.

Why it matters: It matters because IAM teams need controls that limit access at execution time across NHI, agentic AI, and human delegation chains, not just better secret storage.

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.

👉 Read 1Password's analysis of runtime credential brokering for machine workloads and AI agents

Context

Machine identity governance breaks down when credentials outlive the job that requested them. In practice, teams often park service account tokens in CI/CD variables or config files, then assume they will be revoked later, which leaves access open far longer than intended.

AI agents extend the same problem into runtime decision-making. Once an agent can request actions on demand, governance has to follow the execution path, the delegated authority, and the revocation point, not just the vault or secret store.

Key questions

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. The broker should issue only the credential needed for that run, with trust policy tied to repo, branch, environment, and workflow. That reduces standing access and limits blast radius if a pipeline is compromised.

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. If a token sits in a CI/CD variable or config file, anyone who reaches that environment can inherit access long after the original work is finished. That turns ordinary build automation into durable cloud exposure.

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. Long-lived tokens also blur accountability, because the same credential can be reused across actions that were never explicitly re-authorised. Short-lived, task-scoped tokens are the minimum control for agent governance.

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.

How it works in practice

Workload identity federation for GitHub Actions

Workload Identity Federation replaces shared, long-lived secrets with signed, platform-issued assertions about the workload itself. In GitHub Actions, the runner presents a token that identifies the repo, branch, workflow, and environment, then the trust policy decides whether to issue a credential. The important shift is that access is no longer anchored to a static secret copied into the pipeline. Instead, authorization becomes a runtime exchange tied to a specific execution context and a specific policy boundary.

Practical implication: map each CI/CD path to a trust policy that issues only the minimum credential needed for that job.

Job-scoped access and blast radius reduction

Job-scoped access changes the credential lifecycle from persistent entitlement to ephemeral delegation. The workload receives only the item or token required for the task, and the standing vault permission disappears after the job ends. This does not automatically rotate downstream systems, so the upstream secret may still be long-lived in the target application. The control value is narrower but important: if a pipeline is compromised, the attacker should inherit only the job's approved access, not a reusable path into the whole vault.

Practical implication: treat job scope as blast-radius control, then separately verify downstream secret lifetime in the target system.

AI agent identity and delegated authorization

AI agents are governed differently from batch workloads because they can initiate tool use during runtime. If an agent receives a long-lived OAuth token, that token can accumulate permissions, survive task completion, and obscure accountability. Runtime brokering shifts the model to short-lived, task-scoped access with attribution back to both the agent and the human who delegated the task. That makes identity, delegation, and revocation observable in a way static secret distribution never could.

Practical implication: require agent-specific authorization and logging before allowing any tool-calling path to use production credentials.

NHI Mgmt Group analysis

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.

Runtime credential brokering defines a sharper identity blast radius than secret storage alone. A vault can store credentials securely and still leave the programme with persistent access risk if the workload keeps a standing token. Brokering at the moment of use changes the control point from possession to authorization. That aligns with OWASP-NHI and NIST CSF thinking on access control, but the deeper point is that the security boundary now sits at execution time. Practitioners should treat runtime issuance as the control plane, not the vault.

AI agent governance breaks when accountability is attached only to the secret, not the actor. The article's model attributes each request to the agent and the delegating human, which is the correct direction for autonomous and semi-autonomous access. Without that attribution chain, access reviews cannot answer who initiated the action or whether revocation is safe. The governance gap is not simply excess privilege. It is the absence of auditable delegation across the human, workload, and agent layers.

Ephemeral credential trust debt is now the right named concept for this problem. The more teams rely on short-lived access promises while leaving downstream systems long-lived, the more they accumulate hidden dependence on revocation, audit, and downstream state they do not directly control. That is classic trust debt: the programme believes the credential model is safer than the operational reality proves. Practitioners should audit where runtime access ends in one system but persists in another.

Workload identity federation is becoming the baseline control, not an advanced pattern. GitHub, cloud providers, and identity teams have already standardised the mechanism. The differentiator now is whether organisations use it to eliminate standing vault access or merely layer it onto old secret-handling habits. For security teams, the next question is not whether federation exists, but whether governance can express task scope, delegation, and revocation consistently across humans, machine identities, and AI agents.

From our research:

• 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.
• That is why our Guide to the Secret Sprawl Challenge is a useful next step for teams trying to reduce exposure across pipelines and machine identities.

What this signals

Ephemeral credential trust debt: organisations that only modernise secret storage but keep downstream systems on durable credentials are shifting risk, not removing it. The practical test is whether revocation is enforced at the point of use, not just at the vault boundary.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the gap is no longer about awareness. It is about whether CI/CD and machine identity programmes can stop treating secret exposure as a one-time event instead of a lifecycle problem.

The next control conversation will move from secret management to delegation governance. As AI agents take on more runtime actions, IAM teams will need attribution, scope, and revocation models that work across human, machine, and agent identities in the same programme.

For practitioners

• 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. The goal is to remove persistent vault access from jobs that do not need it after completion.
• 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. If the destination still uses durable secrets, treat that as a second control gap, not a solved problem.
• Build attribution for delegated AI actions Require logs that identify the agent, the delegating human, the requested resource, and the policy decision before any production token is issued. That gives security teams a revocation path that matches the actual delegation chain.

Key takeaways

• Standing credentials are the core governance failure here because they outlive the task and widen blast radius.
• The scale of the problem is already structural, with millions of exposed secrets and long remediation delays showing why detection alone is not enough.
• Runtime brokering, task scoping, and attribution are the controls that matter when machines and agents need access only for the moment they execute.

Key terms

• Workload Identity Federation: A method for authenticating a workload without a shared secret by using a signed assertion from the platform that is running it. In practice, it lets a job prove its identity at runtime and receive only the access approved by policy, rather than carrying a reusable credential.
• Runtime Credential Brokering: The practice of issuing credentials only when a workload or agent actually needs them, then letting them expire or become unusable after the task is complete. This reduces standing access and creates a clearer audit trail than storing long-lived secrets in pipelines or agents.
• Standing Access: Access that remains valid beyond the moment it is needed and can be reused without a fresh authorization event. For non-human identities, standing access is a major governance weakness because it increases blast radius, hides stale entitlements, and makes revocation harder to prove.
• Delegation Chain: The sequence of identities involved when one actor authorises another to act, such as a human delegating to a workload or an AI agent. The chain matters because accountability depends on knowing who initiated the action, which identity executed it, and what policy allowed it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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: Credential Broker for machine workloads and AI agents. Read the original.