Is there a way to prevent Jira (and Confluence) admins from using the Atlassian MCP server?

[Matt Deimler]

There is a concern that a Jira user with elevated permissions, like a Jira admin, having access to and using the Atlassian MCP server, creates a risk. In short, we'd like a standard Jira user to be able to use the MCP server, but in some instances, block or prevent a user with elevated Jira permissions from using it. Is that possible?

[Marc -Devoteam- · Accepted solution]

Hi @Matt Deimler 

Welcome to the community.

Going over the documentation, I think not.

https://support.atlassian.com/rovo/docs/getting-started-with-the-atlassian-remote-mcp-server/ 

Within the article, there is a feedback suggestion option, provide your concern there.

But the same applies to the API and elevated user has more permissions than a normal user, this can't be denied to Jria admins as well.

In my opinion people with elevated rights should no the risks based on the elevated permissions they have.

And if it could be limited admins can't use the option, thant wold be strange, not?

[Matt Deimler]

Thank you for the reply.

[Marc -Devoteam-]

Hi @Matt Deimler 

Please accept my answer as a solution, if my answer helped to solve your request.

This will help other community member trying to solve the same.

P.S. If the answer is very valuable to you, please share some kudos.

[Vitalii Rybka · Accepted solution]

Hi @Matt Deimler,

I understand the security concern, but as @Marc -Devoteam- mentioned, this would be quite unusual from an access control perspective. Here's why this restriction isn't typically possible:

Technical Reality:

• MCP server access is tied to API permissions, which admins inherently need for their role
• Blocking admins from tools that regular users can access breaks the standard permission hierarchy
• Most enterprise security models assume admins are trusted with elevated access

Alternative Approaches:

1. Audit & Monitoring - Track MCP server usage through Atlassian Access logs
2. Role Segregation - Create specialized admin roles with limited API access for day-to-day tasks
3. Conditional Access - Use IP restrictions or device policies to limit where MCP can be accessed
4. Approval Workflows - Implement organizational policies requiring approval for MCP usage

Recommendation: Focus on governance rather than technical restrictions. Establish clear policies about when/how admins should use MCP, with regular access reviews and monitoring.

The feedback option Marc mentioned is definitely worth using - Atlassian might consider adding granular MCP access controls in future releases.

What specific risk scenario are you trying to prevent? That might help identify better mitigation strategies.

Feel free to DM me if you want to discuss specific security architectures!

[Matt Deimler]

Thank you!

[David Scovetta]

Yes, administrative IAM typically conveys a higher level of trust to the end-user. However, this extends that same layer of trust to an AI system to interpret user prompts and MCP to execute implementation, both of which can make mistakes; as applied to an organization administrator, that's terrifying.

In this sense, technical restrictions are the governance. Access reviews and monitoring aren't meaningfully helpful to prevent the kind of damage AI/MCP interactions can cause. I'm not worried about the admins themselves.

There are only two solutions I can think of:

• Prevent admins from using MCP: enable granular permission restrictions, treat as an app. This separation of duties seems entirely reasonable. Even if admins can enable/disable for themselves, at least we can monitor for that.
• Allow admins to restrict scope grants (contain the blast radius of a potential oops). Note: I know that service accounts can typically have their API privileges limited, but that's now how our IDE users are calling into jira/confluence; even so, it obfuscates the user-action events in the logs. So that's not really an option. 

It would be great to have better options to limit user access (including privileged users) to atlassian mcp; considering what it's capable of, I'm surprised there doesn't appear to be more of this baked in. Let me know if I'm overlooking anything in the setup instructions, but as it is; it looks like once called, anyone in the org can oauth into it assuming the app itself is approved.