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

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:

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.
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:

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?
Have you opened the Permissions tab, and did the Write defaults surprise you?
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.

Comments

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:

Keep API Tokens OFF unless a specific service-account use case requires them.
Use IP Allowlists as the primary defense for non-OAuth connections.
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:

Yes. We use API token access, to give our own internal tools access.
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.
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.

Sami Shaik

@Anne Saunders , thank you, this is the comment the post needed, and you are right in a way that changes the headline for most readers: IP allowlisting is a Premium and Enterprise control, so on Standard and Free the token door has no network guard at all. The domain list never sees token traffic, and the one preventive control that could is not on the plan. That leaves exactly the three things you named: the token, its scopes, and the account's permissions, plus the Permissions tab as the only org-wide gate. On Standard, trimming that tab is not defence in depth; it is the perimeter. I will move that sentence into the post itself rather than leave it in the comments.

Two things that strengthen the Standard posture, since the network layer is unavailable:

Scoped API tokens with an expiry, created for the service account rather than a human, with only the scopes the internal tool calls. A leaked full-access token from an admin's account is the worst case; a leaked read-scoped token from a service account that expires in 90 days is a contained one. And the org admin view of user API tokens shows you which accounts hold tokens at all, which on Standard is your only inventory.
A dedicated account per integration with a project role that matches what the tool does, so "the account's permissions" is a small, reviewable list instead of a person's accumulated access.

On the usage landing under Jira Administration while you use no AI for admin: I would not guess at the attribution from here, but it is worth a screenshot with a date, because if MCP calls from your internal tools are being attributed to an admin product line, that is the "client, not a person" case in the flesh and it belongs in the follow-up. If you can share what the breakdown shows, I will put it next to my own org's numbers and we can see whether the pattern holds.

@Viswanathan Ramachandran , your five-line summary is the reference view, and Anne's is the first real row. Between them the follow-up table has its two columns: what should be true, and what is true on a Standard org that had to open the door. Thank you both.

Anne Saunders

The reason I assume the usage is somehow misattributed, or the app is mislabeled, is that I know we've had metered Rovo usage in "vanilla" Jira (what would have been "Jira software" in the recent past).

It would have been kind of neat (if also upsetting) for that usage to have been somehow attributable to a client, but my audit log shows no activity in that same period under an API Token or API key Authentication type.

Welcome!

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

Quick Links

Find more posts tagged with

jira-cloud

security

jira-service-management-cloud

rovo

atlassian-administration

mcp

ai-governance