Support for granular Personal Access Tokens (scoped permissions)

What feature do you want to see added?

Currently, Jenkins Personal Access Tokens (PATs) inherit all permissions from the associated user account. This behavior limits their usefulness in environments with strict security requirements.

Feature Request:

Introduce support for granular or scoped permissions when creating Personal Access Tokens. This would allow administrators or users to define the exact capabilities of a token, for example: limiting a token to “read-only,” “build trigger,” or “job configuration” access.

Use Cases:

• Using a read-only PAT for the Jenkins MCP (https://plugins.jenkins.io/mcp-server/).
• Secure automation scripts that only need read access to job metadata or build results.
• Integrations that trigger builds or access APIs without requiring full administrative privileges.
• Reducing the security risk of token leaks by applying the principle of least privilege.

Desired Behavior:

When creating or managing a PAT, Jenkins should provide an option to select specific permission scopes (e.g., “Read Jenkins data,” “Trigger builds,” “Manage jobs,” “Administer system”). Tokens would then operate within those defined scopes, enforced through Jenkins’ security and authorization matrix.

This feature would align Jenkins with modern security best practices adopted by other DevOps platforms (e.g., GitHub, GitLab) and simplify secure integration management.

Upstream changes

No response

Are you interested in contributing this feature?

No response