A reader of my last discussion put it better than I had: on his org, Rovo Overview shows zero users with AI enabled and the Rovo Access blocklist says no AI is in use, while the Rovo MCP server page and the Teamwork Graph say an external tool could read his Confluence tomorrow. Both are true. They are answers to different questions, and the admin console does not say so.
Here are the four switches that govern external AI access to your data as of this week, where each lives, what it actually controls, and the default it arrived with. All four read from my own Standard-tier org on 5 October; verify yours.
Switch 1. Which tools may connect. Atlassian Administration → Rovo → Rovo MCP server → Domains. Each external client is tied to a domain, and the page either allows Atlassian-supported domains by default or allowlists explicitly (control Atlassian MCP server settings). This is the switch most admins know, and it has a hole the same page documents: it only governs tools that authenticate with OAuth 2.1. A client using an API token is not subject to the domain list at all. Keep that in mind for switch 3.
Switch 2. What any connected tool may do. Same page, Permissions tab: read, write and search, per product, with finer toolsets behind Edit details (configure MCP server permissions). Atlassian's doc now states this tab takes precedence over Connected Apps and per-app Marketplace permissions, so it is the primary control, not one of several. Two weeks ago I found a new write toolset switched on because "allow new write toolsets by default" was on. That default says yes to new write capabilities until you say no.
Switch 3. How tools authenticate. Same page, Authentication tab, two toggles: Allow API token authentication and Allow enterprise managed authentication, labelled Beta, which hands MCP authorisation to your identity provider through cross-app access (configure enterprise-managed authentication). Both were off on my org. The first deserves a change ticket because of switch 1's hole: with it on, any user's API token becomes an MCP credential that your domain allowlist cannot see. The second deserves one because it moves the gate out of this console and into your IdP.
Switch 4. Which content is in scope. Atlassian Administration → Security → Data protection → Data security policies → the Atlassian MCP server control, added 29 September (Rovo MCP changelog). It arrived on my org set to Allowed, zero overrides, "Updated by: Atlassian." It supports overrides by app, by space and by classification level, which makes it the one switch that can say "regulated content never leaves through MCP, everything else may." Until you touch it, nothing is excluded.
And one that is coming. The Forge rovo:mcp module went to Preview on 1 October (developer changelog): a Forge app can expose its own tools to external AI clients. External access is off by default and must be enabled per app installation; during Preview, enabling it exposes every tool the app declares. It is not on your console until such an app is installed, and the first one will arrive as a request from an app owner, not from security.
Why the pages disagree
Rovo Overview and Rovo Access govern the in-product Rovo features (Chat, Search, Agents) per user. The MCP server page and the Data security policy govern external clients reaching your data; the MCP server acts within the signed-in user's product permissions, not their Rovo entitlement. So "zero users with AI enabled" and "an external tool can read our Confluence" can both be true on one org. The Teamwork Graph, which both read, being populated is a precondition of either, not evidence of use. Each switch sits on its own page, owned on most orgs by three different people.
What I would do this week
- Open all four pages and write down Updated by and the date on each. If a switch says "Atlassian," nobody on your side decided it.
- Allowlist domains deliberately; turn off the supported-domains default if your org does not use the tools it covers.
- Turn off "allow new write toolsets by default." Grant write per toolset when someone asks.
- Leave both authentication toggles off until there is a change ticket with a name on it, and treat API token auth as the one that bypasses the domain list.
- Classify the content that must never leave, then add a Data security policy override for that classification on the MCP server control.
- Put all four pages on one internal page, with owners, so the next new row has somewhere to be noticed.
- Read the audit log: every MCP tool call is recorded under Insights → Audit log, filtered to Rovo MCP user actions, with the tool, the action and the user (monitor MCP server activity). It is the only place that shows what actually happened, as opposed to what was allowed.
Credit to @Jason Hills for the observation that framed this, and to the Gamma and Okta threads from last week, where the first two of these answers were worked out in public.
Verified against the Atlassian support pages and changelogs linked above, and against my own organisation's console, on 5 October 2026.
