A join token is the policy object that governs how a machine or workload is allowed to exchange its runtime identity for downstream access. For CI/CD, it acts as the gatekeeper between attested job claims and the ability to receive a certificate or session credential.
Expanded Definition
A join token is not a general-purpose API key. In NHI and workload identity systems, it is a narrow policy object that authorizes one specific exchange: an attested runtime claim for a downstream credential such as a certificate, session token, or federated assertion. The control value is in the policy attached to the join step, not in the token itself.
Definitions vary across vendors, especially in CI/CD, service mesh, and workload federation products, but the security intent is consistent: bind a short-lived runtime identity to a trusted onboarding path. That makes the join token concept closely related to attestation, trust bootstrapping, and ephemeral credential issuance. NIST Cybersecurity Framework 2.0 is useful here because it frames identity assurance as part of governance and access control rather than as a standalone secret-handling exercise, which matches how join tokens should be managed in production. Treat the join token as a policy gate for machine admission, not as a reusable secret embedded in code or tickets.
The most common misapplication is treating a join token like a durable credential, which occurs when teams store it in pipelines, reuse it across workloads, or let it bypass attestation checks.
Examples and Use Cases
Implementing join tokens rigorously often introduces onboarding friction, requiring organisations to weigh faster automation against tighter trust validation and shorter token lifetimes.
- A CI runner presents an attested job claim to exchange a join token for a short-lived certificate before deploying to production.
- A service mesh uses a join token once, during workload enrollment, to bind a node to a trust domain and then invalidates the token immediately.
- A platform team gates cluster registration so that only attested build agents can redeem a token for access to a secrets broker.
- An engineering org reviews a leaked token in light of the Guide to the Secret Sprawl Challenge, because the exposure happened during pipeline bootstrap rather than steady-state runtime.
- A cloud security team uses the NIST Cybersecurity Framework 2.0 to map join-token issuance to access control and event logging requirements.
Join-token use is especially relevant in systems where machines must prove origin before receiving downstream access, such as ephemeral build workers, federated clusters, and agentic applications that launch with limited initial trust. A related lesson appears in the Salesloft OAuth token breach, where access power was far greater than intended because the credential path was not constrained tightly enough.
Why It Matters in NHI Security
Join tokens sit at the boundary between identity proof and access issuance, which makes them high leverage and high risk. If the join path is weak, attackers do not need to steal the final credential; they only need to intercept or replay the bootstrap object that mints it. That is why join-token governance must cover issuance, transport, expiry, one-time use, and revocation.
NHIMG research shows how quickly exposed bootstrap credentials become systemic risk: 44% of NHI tokens are exposed in the wild, being sent or stored across collaboration tools, tickets, pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity by Entro Security. The same report also found that 91% of former employee tokens remain active after offboarding, a reminder that token lifecycle failure is often a governance failure, not a purely technical one. In practice, join tokens should be constrained with least privilege, narrow validity windows, and strong attestation checks, then monitored as part of broader secret hygiene. Their importance becomes obvious after a compromised runner, leaked pipeline variable, or unauthorized workload enrollment forces incident responders to trace how a machine was allowed to join at all.
For exposure patterns that mirror join-token misuse, JetBrains GitHub plugin token exposure and Vercel Context.ai OAuth Supply Chain Breach show how bootstrap credentials can become the first step in wider compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Join tokens are bootstrap secrets that must be tightly scoped and short-lived. |
| NIST CSF 2.0 | PR.AC-1 | Identity proof and access authorization both apply to workload onboarding. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit verification before any workload earns downstream access. | |
| NIST SP 800-63 | Digital identity assurance concepts inform how machine identity is bound at onboarding. | |
| CSA MAESTRO | Agentic and workload trust establishment depends on controlled credential exchange. |
Issue join tokens only for one-time, least-privilege exchanges and revoke them immediately after enrollment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
