Skip to content
Agentic Control Plane

The Atlassian MCP server control model, explained

The Atlassian Rovo MCP server is first-party, Atlassian-hosted (https://mcp.atlassian.com/v1/mcp, with an authv2 variant recommended), launched in 2025 and now generally available, covering Jira, Confluence, Jira Service Management, Bitbucket Cloud, and Compass — about 55 tools per the supported-tools list, organized into read/write/search permission groups per product. It’s the interesting counterpoint to Notion in this series: both vendors built their controls as an admin plane over connections rather than calls, but Atlassian built the stronger version — allowlists with teeth, an IP check on every call, and an audit log of individual tool invocations (one of only three in the series, with Slack and Zapier). Sources: the understand, control settings, and monitor activity docs, plus the official repo.

This page covers the server’s own controls. For the cross-server picture, see the MCP server controls comparison; for what a control layer adds on top, the coverage matrix.

What’s at stake on this surface

The write side is the org’s system of record for work: create and update Jira issues, write Confluence pages, act on service-desk requests, touch Bitbucket. An agent that can edit the ticket queue and the wiki can rewrite what the organization believes about its own state.

The distinctive risk is on the read side, and it’s structural: Jira Service Management is an external-input surface. Service-desk tickets arrive from outside the org — that’s their job — so any agent wired to JSM tools reads untrusted text as routine work. Every server in this series has an injection story; this is the one where the carrier arrives through the front door, addressed to the team, wearing a ticket number.

Auth and permission mirroring: the floor, vendor-enforced

Two authentication paths: OAuth 2.1 (the default — users link AI tools through a consent screen) and API tokens for headless, service-style clients, which an org admin must enable. Coverage differs by path: per the repo docs, JSM and Bitbucket tools work only via API token, Compass only via OAuth.

The floor under both is permission mirroring, in Atlassian’s words: “Access is scoped to the user’s existing permissions in Atlassian” — MCP clients act “with your existing permissions” in Jira, Confluence, and Compass. Enforced on Atlassian’s side, same as GitHub’s token scope and Notion’s permission system: the one line the agent can’t configure its way past. And with the same corollary — the floor is whatever the connecting user can see, which for most users is a lot.

The admin plane: the strongest connection-altitude controls in the series

Everything below lives in Atlassian Administration, out of the agent’s reach — the property Notion’s Enterprise plane has, executed with more mechanisms:

  • Domain allowlist. Org admins control which AI tools may connect over OAuth: Atlassian-supported partner domains (Anthropic and OpenAI among them) are allowed by default and can be blocked — though only as a set (“You cannot block individual domains” within it) — and admins add or delete custom trusted domains individually. Caveat stated plainly in the docs: domain blocking applies to OAuth only; API-token tools bypass the domain allowlist entirely.
  • API-token toggle. An org-level switch turns token auth off outright — closing the path that skips the domain check.
  • IP allowlisting, evaluated per tool call. The org’s IP allowlist isn’t a connect-time check: requests are evaluated against it on each tool call. This is genuinely per-call enforcement — the only per-call decision any server in this series makes natively — and it’s worth being precise about what it decides: a network property. Where the call comes from, never what the call does.
  • Permission groups. Tools group by intent — read_jira, write_confluence, search_atlassian — and per the repo docs, “Organization admins grant or revoke access at the permission-group level,” each tool inheriting its parent group’s access. This is real surface reduction — revoke the write groups and you have an org-wide read-only posture — at a grain of about a dozen switches, org-wide, with no per-tool selection below the group and no per-connection variant.
  • Revocation. The MCP app lands in Connected apps after first consent; site and org admins can review or revoke it there, and users can revoke their own grants.

Grade it generously, because it earns it: this is the most complete answer any vendor in the series gives to “who may connect, from where, with which product surfaces.” Notion’s plane answers a subset of these questions on its Enterprise tier; Atlassian answers them across tiers, adds the per-call IP check, and backs it with the audit log below.

The audit log: the only per-call record in the series

The centerpiece. Per Atlassian’s monitoring docs, an event is recorded “every time a tool is used through the Atlassian Rovo MCP server,” and each entry “includes the tool name, action, and user who performed it” — queryable in Atlassian Administration under Insights → Audit log, filtered as “Rovo MCP User Actions,” with ALQL for advanced search. Twelve servers in our comparison write no call-level record at all; this is one of the three that do (Slack, gated to Enterprise Grid, and Zapier are the others). When something goes wrong on this surface, an admin can answer “which tools fired, as whom” from the vendor’s own console. That is not a small thing, and Atlassian should get full credit for shipping it — on any plan, which Slack doesn’t match.

Now its limits, because they’re the shape of the general audit gap:

  • It’s a record, not a rule. Nothing reads the log before the call; nothing can hold a call based on it. The invocation is written down after it happens, unconditionally.
  • Arguments aren’t part of the stated record. Tool name, action, user — not what the tool was asked to do. “write_jira fired” is in the log; the payload isn’t stated to be.
  • Attribution thins on the token path. API-token calls log as the token’s service account, “rather than individual end users in the AI tool” — one identity for every user of a headless integration. OAuth authorization visibility has its own caveat: additional users authorizing an already-installed app don’t appear.
  • It’s one vendor’s silo. The record lives in Atlassian’s console and covers Atlassian’s surface. An agent that reads a poisoned ticket here and acts through some other server exits the log at exactly the interesting moment. Cross-server invisibility is unchanged by the best single-vendor log.

What’s missing

  • No per-connection read-only. Permission groups give an org-wide coarse version; nothing lets one agent be read-only while another writes.
  • No per-tool filtering. The grain stops at the group.
  • No approvals. No native way to hold a write for a human — the docs advise users to “review high-impact changes before confirming,” which is guidance to the human, not a mechanism in the server.
  • No per-call policy. The IP check aside, every control decides which clients connect, not which calls are allowed. An allowed client, on an allowed IP, in an allowed permission group, can make any call those grants cover — and the audit log will faithfully record it.

Injection: the ticket is the payload

The reference incident is a proof of concept, so state it as one: in 2025, Cato Networks demonstrated a technique it called “Living off AI” against Atlassian’s MCP server — an external attacker files a support ticket carrying a hidden prompt injection; an internal engineer processes it with MCP-connected tooling; the agent acts on the injected instructions with internal privileges. Per the reporting (citing Infosecurity Magazine, June 2025), this worked “without any direct access to the MCP server” — the “support engineer effectively becomes an unknowing proxy.” Atlassian’s own repo docs are candid that LLM clients are vulnerable to prompt and indirect injection. Note what the admin plane does against this chain: the attacker’s ticket sails past the domain allowlist (the client is approved), the IP check (the engineer’s IP is fine), and permission mirroring (the engineer has the permissions). The audit log records the resulting calls, attributed to the engineer. Every control holds; the incident happens anyway, because none of the controls operate at the altitude the attack does.

Where the native model ends

The pattern, stated once: the record exists; the rule doesn’t. Atlassian built the series’ best connection-altitude plane — allowlists, a per-call IP check, group-level surface reduction, revocation — and the series’ only per-call audit trail. What no mechanism does is decide a call: no approval hold, no condition on a write following an untrusted read, no policy that distinguishes one write_jira invocation from another. And the one per-call artifact that does exist is a per-vendor silo — authoritative about Atlassian’s surface, blind one server over.

The practical posture: keep the domain allowlist deliberate, disable API tokens unless a headless integration genuinely needs them (and give it a least-privilege service account, since the log will show that account, not the user), revoke write permission groups your agents don’t need, and treat every JSM-connected agent as reading attacker-supplied text — because it is. Then put the part no vendor console holds — per-call policy, approval on writes, and a record that follows the agent across servers — in a layer the agent can’t edit. On this surface that layer isn’t compensating for a weak admin plane; it’s finishing the sentence the best admin plane in the series starts.