JumpCloud Agent Delegated Access: What IT Teams Need to Govern AI Actions

JumpCloud’s 4 November 2026 release notes put Agent Delegated Access into Private Preview. The feature extends JumpCloud Agent Identities so an AI agent can authenticate with its own JumpCloud-managed identity while carrying out work on behalf of an end user. For Hong Kong IT teams experimenting with internal AI assistants, the idea addresses a practical governance problem: an API request should identify both the person who initiated the task and the software agent that actually performed it.

This is more specific than giving an AI tool a shared service account or long-lived API key. It creates a distinct agent identity and uses a delegated token to preserve the relationship between the user, the agent and the resource being accessed. The feature is still a preview, however, and it requires customer-side application and API work.

JumpCloud’s documentation describes a flow built around OAuth 2.0 Token Exchange (RFC 8693). A user signs in through a trusted OpenID Connect (OIDC) single sign-on application. The agent authenticates as itself, then exchanges the user’s identity token for a signed JSON Web Token representing that agent acting on behalf of the user. The downstream API can inspect the token claims to identify the acting agent, the delegating user, the intended audience and the delegation type.

The distinction matters for audit and authorisation. A log entry that only records a generic integration account may show which credential was used, but not which employee requested the work. A delegated token is designed to carry both identities to the API, allowing the application to apply its own rules to the requested action.

JumpCloud’s example uses an employee-facing HR assistant and an internal HR API. The employee signs in, asks the agent to submit a leave request, and the agent presents a delegated token to the HR API. The API validates the token and then applies the organisation’s application permissions. JumpCloud explicitly notes that configuring delegation does not automatically give the agent all of the employee’s permissions.

That boundary is important. The identity platform can establish who is acting and which resource the token is intended for, but the customer-controlled API still needs to validate the token and enforce the right business authorisation. A token exchange is not a replacement for object-level checks, approval rules or data-access controls inside the application.

As of 7 November 2026, Agent Delegated Access is marked Private Preview. JumpCloud says it may be enabled only for selected organisations, and that functionality and pricing may change before general availability. Buyers should therefore treat it as an evaluation capability, not as a generally available production feature.

The documented prerequisites include:

• Private Preview access enabled for the organisation.
• At least one agent registered under Identity Management > Agents.
• An active OIDC SSO application that issues the user identity tokens the agent will exchange.
• An administrator or manager role with permission to manage agents.

For user-to-agent delegation, the administrator enables delegation on the agent and selects a trusted OIDC application. The documentation currently describes one trusted application per agent. Only users assigned to that application are eligible to be represented by the agent.

Two configuration decisions deserve particular attention. First, decide which users the agent may act for. Delegation is off until an administrator enables it, and the trusted OIDC application determines the eligible user population. Avoid connecting a broad workforce application to an agent whose job only requires access for a small operational team.

Second, constrain the intended API audience. JumpCloud checks requested audiences against the allowed-audiences list configured for the agent. The current documentation allows up to five HTTPS audience values and notes that case and a trailing slash are significant. Keep the list narrow, use identifiers controlled by the organisation, and test that the API rejects tokens presented to an unapproved resource.

Do not stop at the identity configuration. The API should validate the signature and relevant claims, map the delegated user and acting agent to an approved action, and deny requests outside the user’s authority. Test negative cases such as an agent attempting to access another employee’s record, an unapproved API audience, a disabled delegation setting and a user who is no longer assigned to the trusted application.