s it possible to create an API token with truly restricted permissions (not inheriting user permissi

[sagi karach]

Hello Jira Support,

We are working with Jira Cloud and API tokens with scopes, and we would like to clarify whether it is possible to create an API token whose permissions are strictly limited to what is explicitly defined on the token itself, rather than inheriting the full set of permissions of the user who created it.

More specifically, we are looking for a way to create an API token that:

• Can perform a very limited set of actions (for example: browse issues and add comments only)

• Is not allowed to delete comments, delete issues, or perform other destructive actions

• Does not inherit additional permissions from the user’s project roles, groups, or permission schemes

From our understanding and testing so far:

• API token scopes appear to only limit which APIs can be called

• Actual permissions (e.g. deleting comments or issues) are still governed by the project’s Permission Scheme and the user’s roles/groups

• As a result, even a scoped token can perform actions that the underlying user is allowed to perform

Can you please confirm:

1. Whether Jira Cloud currently supports API tokens with independent, enforceable permissions that override or do not inherit the creating user’s permissions?

2. If not, is the recommended approach to create a dedicated “integration user” with a minimal project role and manage permissions exclusively via the project’s Permission Scheme?

3. Are there any plans or recommended patterns (e.g. OAuth apps, Forge, Connect) for achieving true least-privilege access for integrations?

Thank you for your clarification.

Best regards,
Sagi Karach

---

[Hari Krishna · Accepted solution]

Hi @sagi karach ,

No, Jira Cloud does not currently support API tokens with independent permissions that override or bypass the permissions of the user who created them.

API token scopes only control which REST APIs can be accessed, not what actions are allowed. The actual authorization (for example, browsing issues, adding or deleting comments, or deleting issues) is still fully governed by the underlying user’s project roles, groups, and permission schemes. So if the user can perform an action in Jira, a scoped API token created by that user can also perform it.

Because of this, the recommended and widely used approach is to create a dedicated integration user and grant that user only the minimum required permissions through project roles and permission schemes. This is currently the only reliable way to achieve least-privilege access with API tokens.

For stricter control and modern patterns, Atlassian recommends using:

OAuth 2.0 (3LO) for user-consented, scoped access

Forge apps, which enforce permissions at the app level

Connect apps (where applicable), which also use explicitly declared scopes

These approaches provide better isolation and control than API tokens. At this time, there is no announced support for API tokens with standalone, non-inherited permissions in Jira Cloud.