nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Inquiry about MCP setting (w/ Claude)

김지호_정보보호사무국_

Hi Atlassian Community,

We're currently using Atlassian with Claude Enterprise, and we'd like to restrict Rovo MCP server access so that only connections from our company's Claude organization are allowed — not personal Claude accounts.

The concern is straightforward: if an employee connects their personal Claude account (claude.ai) to our company's Atlassian via MCP, they could access all Confluence and Jira data from outside the organization, which is a significant security risk.

Since both personal and enterprise Claude accounts share the same domain (claude.ai), domain-based filtering doesn't help here.

Our question:
Is there currently any way to restrict MCP connections based on the Claude organization (e.g., Enterprise org), rather than just the domain?

If this isn't currently supported, we'd like to request this as a feature — specifically, the ability to allowlist specific Claude organizations or tenants at the Rovo MCP Server level.

This would be especially valuable for organizations that want to enable MCP for productivity while preventing unauthorized data access through personal AI accounts.

Thanks in advance for any guidance or feedback.

Accepted answers

Arkadiusz Wroblewski

Hello @김지호_정보보호사무국_

Your concern is very very Very Very.....valid, but Atlassian’s Rovo MCP Server currently lacks tenant-level controls. Because personal and enterprise Claude share the same domains, domain allowlisting cannot distinguish between them.

For now, you must rely on broader security layers: disabling API-token auth, minimizing write permissions, using IP allowlisting, and checking if Claude Enterprise can restrict integrations on its side. To achieve true tenant-specific filtering, I recommend raising a feature request with Atlassian or look if there's already one.

Best,

Arkadiusz 🤠☀️

All comments

Arkadiusz Wroblewski

Hello @김지호_정보보호사무국_

Best,

Arkadiusz 🤠☀️

김지호_정보보호사무국_

@Arkadiusz Wroblewski

Thanks for the answer.

If I pay for Atlassian Guard, would that resolve the issue? I'd like to know whether it's still not possible even then.
Please let me know if you have any information on this.

Arkadiusz Wroblewski

Guard can "Tighten" your Security but The underlying limitation Stays, MCP controls filter by domain, which cannot differentiate between a personal Claude account and your corporate Claude Enterprise organization. For an official production security decision, I recommend confirming this with your Atlassian account contact, but you will ultimately still need that tenant-level feature request.

Best,

Arkadiusz🤠

Mahima_miniOrange

Hi, This is a very relevant concern for organizations looking to enable AI assistants while maintaining strong governance over their Jira data.

If you're looking for more granular control over how Claude interacts with Jira, you may want to explore AI Governance Gateway for Jira, available on the Atlassian Marketplace.

The app allows organizations to define group-based policies to control AI access to specific Jira projects and restrict or allow specific Jira operations. It also provides audit logs and a governance dashboard to monitor AI-driven activity.

If you'd like to see how it works, feel free to reach out to mahima@xecurify.com for a demo.

Hope this helps!

Thanks,
Mahima

김지호_정보보호사무국_

Hello,

Thank you for your response.

I have a few questions about the product.

How it works: Does it create an MCP server exclusively for our Atlassian tenant, and then we connect it in Claude?
When setting up on Claude's side: Is this something the administrator handles? If we need to share the MCP server URL with regular users, I'm concerned about the possibility of it being leaked. Could you clarify?
After setup is complete: Will it be impossible for anonymous personal accounts (other than the company's official Claude account) to connect to the company's Atlassian account via MCP?

Please confirm the above, and if you have any guide documents, please share them as well.

Thank you.

Mahima_miniOrange

Hi @김지호_정보보호사무국_

Happy to clarify each point.

1) How it works: Does it create an MCP server exclusively for our Atlassian tenant, and then we connect it in Claude?

Yes. When you install the app, it provisions an MCP endpoint that is unique to your Atlassian installation (a Forge web-trigger URL). You add that URL in Claude as a custom connector. Every request from Claude hits your governance layer first, which enforces your access policies and then relays the call to Atlassian's Rovo MCP. The app runs 100% on Atlassian Forge-there is no external server or database, so your data stays within Atlassian.

2) When setting up on Claude's side: Is this something the administrator handles? If we need to share the MCP server URL with regular users, I'm concerned about the possibility of it being leaked. Could you clarify?

An administrator gets the connector URL from the app's admin page and shares it with users; each user adds it once in their own Claude. Sharing the URL is safe, because the URL is an endpoint, not a credential. The endpoint enforces OAuth 2.1 with PKCE, so:

Any request without a completed OAuth login is rejected (fail-closed) — the URL on its own returns nothing.
Each user must sign in with their own Atlassian account, and the app relays calls under that user's own Atlassian token. So even after signing in, a person only ever sees what their own Atlassian account is allowed to see — further narrowed by your policies.

A leaked URL is therefore not usable by anyone who isn't already a valid, authenticated user in your Atlassian org.

3) After setup is complete: Will it be impossible for anonymous personal accounts (other than the company's official Claude account) to connect to the company's Atlassian account via MCP?

Anonymous or non-Atlassian accounts: Access is impossible without authenticating as a valid Atlassian user in your organization (through your normal Atlassian/SSO login). Unauthenticated requests fail closed. Every access is tied to a real, authenticated user and is governed by your group/project/operation policies.
One important clarification: the MCP layer authenticates the Atlassian user, not the Claude account. Our app governs what can be accessed and what operations are allowed. Distinguishing "the company's official Claude account" from "an employee's personal Claude account" is not enforced at the MCP layer — that is controlled on Anthropic's side via Claude Enterprise / Tenant (domain) Restrictions, optionally combined with network egress controls. If blocking personal Claude accounts entirely is a requirement, we recommend pairing our app (data-access governance) with Claude Enterprise tenant restrictions (account-level control).

Please find the guide here and feel free to schedule a demo

Best regards,
Mahima

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

cloud

confluence-cloud

security-and-access-policies

not%20applicable