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; } } }

Four MCP switches landed in my admin console since September. How many have you reviewed?

Sami Shaik

I opened Data security policy this morning and there is a row I did not create: Atlassian MCP server, default configuration Allowed, applies to Jira and Confluence, overrides 0, updated by Atlassian (first screenshot below). It arrived on 29 September (Rovo MCP changelog) as a data security policy control that governs how external AI tools read and write Jira and Confluence data, with overrides by app, space and classification level. It is the right control to have. It is also the fourth switch for external AI access that has landed in my org since early September, and every one of them arrived with a default somebody else chose.

Here are the four, as they stand on a Standard-tier org today:

Data security policy → Atlassian MCP server. Allowed by default, no overrides. If you classify content, this is where you can keep a classification level away from MCP clients entirely. Until you touch it, nothing is excluded.
Rovo MCP server → Permissions. The write toolsets. Two weeks ago I posted that a new write toolset had switched itself on in my org because "allow new write toolsets by default" was on. Still on unless you turned it off.
Rovo MCP server → Authentication. Two toggles, both off on my org: Allow API token authentication (non-interactive access for agents and pipelines) and Allow enterprise managed authentication, marked Beta, which hands MCP authorization to your identity provider instead of the domains list (second screenshot below). These are the two I would want a change ticket for before anyone flips them.
Forge rovo:mcp module, in Preview since 1 October (developer changelog). A Forge app can now expose its own tools to external AI clients; the admin control during Preview is a single switch per app that exposes every tool the app declares. This one is not in the admin console yet unless you have such an app installed; it will be.

Three questions, because the answers will tell us more than the docs do:

Did the MCP server row appear in your Data security policy, and had anyone on your side reviewed it before you read this? I am especially interested in orgs with classification levels in use: did you add an override, and for which level?
Is enterprise managed authentication showing as Beta on your org too, and has anyone wired it to Okta or Entra yet? A thread this week suggests the Okta path works with the right values and the Entra path is not yet validated; a second data point would help.
Who owns these four switches in your organisation? On most orgs I have seen, the Rovo MCP page is owned by whoever set up Rovo, the Data security policy by security, and Forge apps by the app owners. Four switches, three owners, one data flow.

I will fold what comes back into a longer write-up next week. No vendor pitches please; this one is about the admin console.

Comments

Jason Hills

I am concerned about this and other such issues as well.

We had AI turned off, as having it on would violate the CISO's policies, but turning all that functionality on by default makes us nervous. It's not transparent whether our initial settings were upheld.

Sami Shaik

@Jason Hills , Thank you for being first, and your line "it is not transparent whether our initial settings were upheld" is the whole issue in one sentence. One concrete thing you can do on Monday: the Data security policy row and the Rovo MCP server pages both show "Updated by" and a date, so you can establish whether your CISO's AI-off decision was carried into these four switches or whether they arrived at their defaults regardless. If they arrived Allowed, that is worth raising with your Atlassian contact as a question, not a complaint: "which of our existing policies did the new control inherit from?" If you post what you find, that is exactly the data point this thread is for.

Jason Hills

Greetings,

Actually, I look in a different place.

In the Rovo Overview, there's a list of "Users with AI Enabled" that has no entries. That's my first check.

But after that, the concern is whether Atlassian or third-party AI use is occuring. Rovo Access is where the blocklist is, and it suggests that the answer is "no."

The issue is that the Rovo MCP server and especially Temwork Graph CLI suggest that it is.

The solution is simple.

Those UIs need to be coordinated to show the dependencies. The breach of turning on ungoverned AI on some of our resources would be immense if not catastrophic. Hence, for reassurance, the locking mechanisms need to be absolutely clear. My read of the situation is that Atlassian is trying to grant really fine-grained control, which is appreciated.

Side note. As a person who manages a lot of development, this almost feels like different people or teams weren't talking to each other to coordinate and integrate the components.

Sami Shaik

@Jason Hills , that is the finding, and you have named the gap precisely: the pages that say "no AI" are measuring different things from the pages that say "AI is reachable." Rovo Overview's "Users with AI enabled" and the Rovo Access blocklist govern the in-product Rovo features (Chat, Search, Agents) per user. The MCP server page and the Data security policy control govern external clients reaching your data, and a client can be allowed there while the user it acts for has never had Rovo turned on; the MCP server acts within the user's product permissions, not their Rovo entitlement. So "no users with AI enabled" and "an external tool can read our Confluence through MCP" can both be true on the same org, which is the dependency the UIs should show and do not. The Teamwork Graph is the third thing: it is the index both sides read, so it being populated is not a sign of use, it is a precondition of it. Your suggestion is the right ask for Atlassian: one page per org that lists every surface through which AI can touch the data, with its switch and its last change. I am writing that up this week with your question as the framing, and I will credit you for it.

Sami Shaik

@Jason Hills , the write-up is up, with your observation as the framing and a correction I owe you: the Forge rovo:mcp control is off by default per installation, not a single global switch.

https://community.atlassian.com/forums/discussion/3310181/four-switches-govern-external-ai-access-to-your-data-three-of-them-do-not-talk-to-each-other

Welcome!

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

Quick Links

Find more posts tagged with

atlassian-guard

rovo

data-security

atlassian-administration

mcp