Your MCP domain allowlist has two doors it does not guard. Have you opened either?

[Sami Shaik]

Third in the series after three doors and the fourth door, A2A. This one is about the doors most of us think we have already locked.

What I thought the control was. Atlassian Administration, Rovo, Rovo MCP server, Domains tab: a list. Atlassian's supported AI partners are allowed by default, you can add your own domains, or you can turn the Atlassian list off and add nothing, which is what I did months ago: no partner domains, no own domains, MCP effectively closed. That control is real and it works (control Rovo MCP server settings).

What I found on the next tab. The Authentication tab has two switches, both off by default, and each one routes around the domain list:

1. Allow API token authentication. Atlassian's words on the control page: "Tools that authenticate via API token do not use domain allowlists and are instead governed by your IP allowlist configuration and the scopes granted to their tokens or API keys." Once on, a client presenting a valid scoped token from any domain connects with that account's permissions.
2. Allow enterprise managed authentication (Beta). The caption in the console says it plainly: "Access is controlled by an IdP, not the domains list." Authorisation moves to your identity provider; the domain list is no longer consulted.

Why you will be asked to open the first one. The v2 tool sets for Jira Service Management and Bitbucket are only available through API token authentication (authentication and authorization). The first team wanting an AI agent on JSM queues through MCP will ask for the token switch, and from then on the domain list covers the interactive tools and nothing else.

And the third tab decides what a client can do once inside. Permissions lists Read, Write, Search, Delete and Manage per toolset. On my org today, with nobody having touched it: Read 13 of 13 allowed, Write 13 of 13, Search 4 of 4, Delete 0 of 1, Manage 0 of 1, plus a banner telling me new toolsets arrived and were allowed automatically. So the default posture is: writes on everything, deletes and admin blocked, and each new toolset opens on arrival. That tab is where the real least-privilege decision lives, and I suspect most orgs have never opened it.

What still guards both doors, and what each costs:

• IP allowlists, per product, apply to token, OAuth and IdP clients alike. Two catches from the doc: most orgs do not run them because they break remote work, and some AI tools use their own outbound IPs, so a user on an allowed VPN can still be blocked unless the tool's ranges are added.
• Token scopes and tracking. A token client is bounded by its scopes, and org admins can view and revoke user API tokens. Detective, not preventive.
• A data security policy rule, "Prevent Atlassian Rovo MCP server access," exists in the policy controls, so MCP can be blocked by classification and policy scope. I have not confirmed which plans carry it; if you have, say so below.
• Monitoring. Atlassian publishes a page on monitoring Rovo MCP server activity. Read it before the switch, not after.

And it is metered. MCP calls that search or pull context draw from the shared Rovo credit pool, up to 10 credits a call for search and Teamwork Graph tools, with extra usage billing from 3 December (how Rovo credits work). A service account's token in a backend loop is a meter running with nobody looking at it.

Where I am today: Atlassian domains off, no domains added, both authentication switches off, so nothing connects. Delete and Manage blocked by default; Read, Write and Search wide open by default, which I am now going to trim before the first request to open a door arrives.

What mine looks like today (Atlassian Administration, Rovo, Rovo MCP server):

Domains tab: Atlassian supported domains off, no domains added.

Permissions tab: Read 13/13, Write 13/13, Search 4/4 allowed; Delete 0/1, Manage 0/1.

Authentication tab: API token off, enterprise managed authentication (Beta) off.

Three questions, and I will summarise the answers in a follow-up:

1. Have you enabled API token or enterprise managed authentication for the MCP server, and what forced it: JSM tools, Bitbucket, a backend integration, or an IdP mandate?
2. Have you opened the Permissions tab, and did the Write defaults surprise you?
3. Who in your org watches the Rovo credit meter, and has anyone attributed a spike to an MCP client rather than a person?

Every control above was checked against the Atlassian pages linked, and against my own console, on 9 September 2026. If Atlassian closes the gap (domain enforcement for tokens, or a per-token domain binding), I will update this post rather than leave it standing.

[Viswanathan Ramachandran]

Hi @Sami Shaik 

Your analysis is highly accurate and highlights a critical distinction in Rovo's security architecture: the difference between interactive (OAuth) and non-interactive (API Token) authentication.

You have correctly identified that the Domains tab is not a universal firewall for MCP. Instead, it is a specific control for the OAuth 2.1 redirect flow. Your two doors analogy is an excellent way to describe the bypasses that exist when moving from user-driven tools to service-style automations.

Answers to the Core Questions

1. Does the Domain Allowlist guard API token connections?

No. As you suspected, the domain allowlist only applies to tools connecting via OAuth 2.1.

• The Reason: OAuth requires a browser redirect to a specific URL (the domain), which Atlassian can validate. API tokens are passed directly in the request header, so there is no redirect origin to check.

• The Guard: For API tokens, the door is instead guarded by IP Allowlists and Token Scopes. If you enable API tokens, you must ensure your organisation's IP allowlist is strictly configured, as the domain list will no longer provide protection for those connections. Control Atlassian Rovo MCP server settings | Atlassian Support

2. Are permissions for new toolsets automatically allowed?

Yes, by default. The current posture for the Atlassian Rovo MCP server is to allow Read, Write, and Search permissions for new toolsets as they arrive.

• The Risk: This open by default approach ensures that new features work immediately for users, but it conflicts with the principle of least privilege.

• The Recommendation: Admins should proactively visit the Permissions tab to trim these down. For example, blocking Write or "Delete globally and only enabling them for specific, trusted toolsets is the safest configuration. Understand Atlassian Rovo MCP server | Atlassian Support

3. Is credit usage metered for service accounts?

Yes, and it is metered per call. MCP calls that search draw from the shared Rovo credit pool.

• The Meter: A service account using an API token in a backend loop can consume credits rapidly (up to 10 credits per search call).

• The Oversight Gap: Unlike a user-facing chat where a human sees the credits used or the response, a backend automation can run silently. Monitoring Rovo credit usage at the organisation level is essential once the API token door is opened. https://support.atlassian.com/rovo/docs/how-rovo-credit-usage-works/

Summary for your Follow-up

If you were to summarise this for your community peers, the key takeaway is: The Domain Allowlist is a browser-security control, not a data-access control.

To truly secure MCP, admins must:

1. Keep API Tokens OFF unless a specific service-account use case requires them.

2. Use IP Allowlists as the primary defense for non-OAuth connections.

3. Audit the Permissions tab every time a New toolsets arrived banner appears to ensure Write/Delete access isn't granted unintentionally.

[Sami Shaik]

@Viswanathan Ramachandran , thank you, and the redirect-origin explanation is the sentence the post was missing: OAuth 2.1 has a browser redirect to a domain Atlassian can check, a token in a request header has nothing to check against, so the domain list was never able to see that traffic. That is why I would rather admins understand it as a browser-flow control than as a firewall, exactly as you put it.

Two refinements from my side, then a request.

On IP allowlists as the primary defence for token clients: agreed, with the catch that Atlassian's own page states: some AI tools call from their own outbound IP ranges, so a service account running on a vendor's infrastructure needs the vendor's ranges on the allowlist, not the office ones, and that list is the vendor's to change. For a backend loop on infrastructure you control, the allowlist is the right primary control; for a SaaS agent, it is a control you share with someone else.

On trimming Permissions: your shape (block Write and Delete at the category level, then enable only the toolsets a named integration needs) is the one I am going to apply, and it has a side effect worth naming: the "new toolsets allowed" behaviour means a category left open keeps opening as Atlassian ships tool sets, while a category trimmed to specific toolsets does not inherit the new ones. Trimming is also how you stop the drift.

The request: the post's three questions were meant to collect what people have actually done on their own orgs, and a Champion's console is the one I would most like to see. Have you had to open either switch on any org you administer, and if so, what forced it and what did you put in front of it? The follow-up post is going to be a table of real configurations, and yours would anchor it.

[Viswanathan Ramachandran]

Hi @Sami Shaik 

Thank you for the refinements.  Spot on regarding Browser Flow Control vs. Firewall, that distinction is the key to the whole model.

While I don't currently administer a live production instance, its my personal interests to offer a reference view on how these switches should be anchored. 

In Summary,

• API Token Switch: OFF by default. 

• Permissions: Restricted, not Inherited.

• Identity: OAuth for humans; Service Accounts for headless.
• Gating: Manual toolset allowlisting to kill feature drift.
• Defense: IP Allowlists are shared responsibility; Permissions are sovereign.

On this note, looking forward to seeing your follow-up post. 

[Anne Saunders]

@Sami Shaik, there's a Standard tier wrinkle that changes the token-door math for a lot of your readers: the guard you name for that door (IP allowlists) is Premium/Enterprise-only.

Product IP allowlisting isn't available on Standard or Free, so below Premium the token door has no network fallback. The domain list never sees token traffic, and the one preventive control that could is absent. Open that switch on Standard and the the token, its scopes, and the account's permissions become the whole boundary.

We're a live case: standard org, token auth on (our internally built tools needed site access), and with no allowlist to reach for, the load-bearing control became the Permissions tab.  Write disabled, Delete and Manage left blocked. On Standard, trimming Permissions isn't defense-in-depth, it's the whole defense.

Your three, quickly:

1. Yes. We use API token access, to give our own internal tools access.
2. I was surprised! The day it hit our instance, I opened it, immediately disabled Write, and kept Delete/Manage off. We want our non-Atlassian tools analyzing our data, not confidently wrong in it in ways we won't catch.
3. I'm the one who watches usage for our org; it's pretty low and barely moving. One oddity, though: some usage lands under Jira Administration though we aren't using AI for admin tasks (we do use AI in Jira, and I'm guessing this is a typo/misattribution), but your "attributed to a client, not a person" question has me wondering.

Glad to be a 'Standard' row in your follow-up table 😄

[Viswanathan Ramachandran]

Hi @Anne Saunders 

This is a fantastic addition. That Standard Tier wrinkle is the missing piece of the puzzle.

If you are below Premium, you don't have the IP Firewall door at all. In that architecture, the Permissions tab stops being a secondary control and becomes your Primary Perimeter.

Takeaway for Standard Orgs:

• The Token Door: Opening it without an IP allowlist means you are betting entirely on Token Secrecy and Identity Scoping.

• The Permissions Tab: Trimming isn't just best practice here, it’s the only thing preventing a confident LLM from performing a Delete action that you have no network-level way to intercept.

• The Usage Oddity: That Jira Administration attribution is likely the system level overhead of the MCP server itself or the client-side cost of the internal tool connection. It’s a great reminder that in a headless model, attribution gets blurry fast.