Jira Ops Service accounts - Is there a way to limit the team access of Service Accounts?

[Tomi Sofowora]

Hi all,

Service accounts have just been enabled for Jira Operations API. Is there a way to limit the team access for each service account? Currently it has access to every teams alerts.

Thanks,

Tomi

[Sami Shaik]

Hello @Tomi Sofowora ,

@joris raffin conclusion is right (there is no team scope on a token), so let me add the mechanism, because once you see it the fix is a role change rather than a workaround.

Alert visibility in Operations follows team membership plus role, not a permission scheme. Atlassian's API reference states it directly: a Team Member can only access the configurations of the teams they belong to and the alerts they have permission for, while a product or ops admin can access everything (Operations REST API permissions). So if your service account currently sees every team's alerts, it is not because tokens are global; it is because the account itself holds an admin-level role (JSM product admin, or team admin across the teams). The token inherits the account, nothing more.

The fix, in order:

1. Strip the admin role from the account. Give it plain JSM agent access and no product-admin or Jira-admin grant.
2. Add it only to the Atlassian teams it should serve, as a member (not team admin, unless it must change schedules or integrations for that team). Per the rule above, its alert visibility collapses to exactly those teams.
3. If you need finer control than member versus admin, Operations has custom user roles (Team settings, Roles), so you can define a role that reads alerts but cannot acknowledge or close, and give the account that role per team.
4. One account per integration where the audiences differ, as Joris suggests, because the account is the boundary. The real cost of that pattern is ownership: token rotation, who is alerted when it breaks, and who inherits it when its creator leaves. Put those three in the account's description field so they survive staff changes.

One boundary to know before you reach for the newer feature. If by "service account" you mean Atlassian's org-level Service Accounts (Atlassian Administration, introduced last year), they cannot call the Operations APIs at all yet, globally or per team; that is an open suggestion, JSDCLOUD-17685, and Atlassian's interim advice is a regular account with agent access, which is the pattern above. Worth a vote if you would rather the scoped identity come from the org admin console than from team membership.

[joris raffin]

Hi Tomi,

From what I've seen so far, service accounts inherit permissions through their Atlassian app access and group memberships, similar to regular users. Atlassian recommends applying the principle of least privilege and managing access through dedicated groups rather than relying on the service account itself to provide additional scoping.
https://support.atlassian.com/user-management/docs/understand-service-accounts/ 
https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/A-Guide-to-Service-Accounts-in-Atlassian-Cloud-Part-2-Setting-up/ba-p/3185888 

I haven't found any documented way to restrict a Jira Operations service account to a subset of Operations teams or alerts. If the account has access to Jira Operations, it appears to be able to see all teams/alerts that its underlying permissions allow.

As a workaround, you could:

• Create separate service accounts for different integrations/use cases.
• Use dedicated groups with the minimum required permissions.
• Review which default access groups the service account is being added to, as service accounts can inherit access through those groups. https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/A-Guide-to-Service-Accounts-in-Atlassian-Cloud-Part-2-Setting-up/ba-p/3185888 

If anyone from Atlassian can confirm whether team-scoped access for Jira Operations service accounts is on the roadmap, I'd be interested as well.