How to control which MCP clients and agents reach Jira and Confluence

You control which MCP clients and agents reach Jira and Confluence in Atlassian Administration, under Connectors, then Atlassian MCP server, where you set the allowed client domains, the allowed authentication methods, and Read, Write, and Search permissions for each app. Every connection still acts as a person or an account with that account's existing permissions, so the identity behind each connection decides how far an agent can actually reach.

What the Atlassian Rovo MCP Server is

The Atlassian Rovo MCP Server is a cloud-hosted Model Context Protocol server that gives external tools access to Jira, Confluence, and other Atlassian apps. Atlassian announced general availability in February 2026. Atlassian Administration lists the same thing as Atlassian MCP server, so expect both names.

Most clients connect to https://mcp.atlassian.com/v2/mcp. Atlassian's setup guide covers Claude, ChatGPT, Cursor, VS Code with GitHub Copilot, Codex, Windsurf, and any other client that supports MCP. Once connected, a client can search, summarize, and create or update work items and pages on request. MCP calls consume Rovo credits from the same shared pool as Rovo Chat and agents.

How clients connect: OAuth 2.1 or an API token

There are two ways in, and they behave differently for access control.

OAuth 2.1 (the default). The person sees an Atlassian consent screen and approves the client. The consent sets which Atlassian apps and scopes the client can use, and the token is typically tied to one site. Atlassian says access is scoped to the user's existing permissions.

API token (advanced). This works only if an organization admin allows it. The client sends either a personal API token with the owner's email (Basic auth) or a service account API key (Bearer). Atlassian positions it for backend services, CI/CD pipelines, bots, and automated agents. The token is not tied to one site, and domain rules do not apply to it. Atlassian says your IP allowlists and the token's scopes govern it instead, on top of the account's own permissions.

Behavior	OAuth 2.1	API token
Acts as	The person who consented	The token's owner, or a service account
Available	By default	Only if an organization admin allows it
Domain rules apply	Yes	No
IP allowlists apply	Yes	Yes
Data security policy MCP control applies	Yes	No
Audit log shows	The person	The token's account, not each person using the tool

The admin controls in Atlassian Administration

Most controls sit on one page: Atlassian Administration, then Connectors, then Atlassian MCP server. Organization admins manage it. These settings cover Atlassian's hosted server only. A self-hosted MCP server that calls Jira or Confluence directly falls under your API token policy, connected apps settings, and IP allowlists instead.

Domains

By default, Atlassian allows a list of Atlassian-supported domains, its AI partners such as claude.ai and chatgpt.com. You can block that whole list by clearing Allow Atlassian supported domains, but you cannot block single domains on it. Select Add domain to approve the client domains or patterns you trust, such as https://*.example.com/**. The supported list also includes localhost and 127.0.0.1, which lets local MCP clients on people's own machines complete the OAuth flow.

Authentication

The Authentication section turns API token authentication on or off. Turning it off stops tools from using tokens and leaves your domains and IP allowlists as they were. The same area holds enterprise-managed authentication, covered below.

Permissions

The Permissions tab sets whether the server can Read, Write, and Search, and Edit details lets you set each one per app, for example Jira but not Confluence. Atlassian says this tab now takes precedence over Connected apps settings, and changes take effect immediately. Watch Apply to future additions: while it is on, new permissions of an allowed type reach users as soon as they are added, without admin review.

Data security policy

With Atlassian Guard Standard, a data security policy can use the Atlassian MCP server control to block MCP reads at the organization, site, or content level, and at the classification level with Guard Premium. Blocked work items and pages are not returned through MCP, even when the person could open them directly. This control applies only to OAuth connections, not API tokens, and it does not cover custom MCP servers.

IP allowlists and connected apps

IP allowlists, which Atlassian lists for Premium plans of Jira, Jira Service Management, Confluence, and Compass, also apply to MCP requests on both authentication methods. Some clients use their own outbound IP addresses, so add those ranges too. Separately, admins can select Block user apps in a site's Connected apps settings, which stops users from installing any OAuth app. Atlassian calls that a blanket setting, so start with the MCP page.

Access is bounded by the account behind it

Atlassian's own disclaimer says MCP clients can perform actions in Jira, Confluence, and Compass "with your existing permissions," and it advises least privilege. The server does not grant anything the account lacks. A client connected by a Jira admin works with that admin's permissions. A pipeline on a service account key can reach whatever that account and its token scopes allow.

So every MCP connection is only as safe as the account behind it. The settings above decide which doors exist. The account decides how far each one opens. If your permission schemes give broad groups wide access, an agent inherits that breadth the moment someone connects it.

What admins can see afterwards

• Tool calls. Every tool call through the server is recorded in the organization audit log with the tool name, the action, and the user, on all plans. Go to Insights, then Audit log, and filter for Rovo MCP User Actions or search for MCP.
• First authorization. With Guard Standard, the audit log shows when a user first authorized the server through OAuth, which installs the Atlassian MCP app. Later users who authorize it do not appear, so the log is not a full list of who has connected.
• API token connections. Calls appear under the account that owns the token, not under each person using the external tool. A shared token hides who asked for what.
• Tokens. Insights, then API token activity, lists managed accounts' user API tokens with their created, expiry, and last-used dates, and lets you revoke them.
• Usage. Insights, then Platform usage, shows Rovo credit consumption, which includes MCP calls.

Atlassian keeps audit log activity for 180 days. With Atlassian Guard, activity logged from October 1, 2026 is kept for 365 days. Export what you need to keep longer.

Treat every MCP connection as an identity

Each connection acts as a person or an account, so record four things for each one that matters.

• Owner. A named person managed in Okta, plus a backup. For a service account, put the owner in its description too.
• Scope. The apps and spaces it needs, set through the account's groups and permissions, plus the token scopes for API tokens. Service account token scopes cannot be changed after creation, so narrowing one means issuing a new token.
• Credential with an expiry. OAuth for one person in their own client. A service account API key, created under Directory, then Service accounts, for a shared pipeline. When you create an API token you set its expiry, from 1 to 365 days, so pick the shortest period that works and write the date down.
• Review date. When the owner next confirms the connection still has a purpose and still has the minimum scope.

Never put a personal API token in a shared agent or pipeline. Its calls look like that person's in the audit log, and it depends on that person's account lifecycle. Our guide on service accounts vs agent identities covers that choice in detail, and our guide on approving and auditing Rovo agents covers agents built inside Atlassian.

Where Okta and Atlassian Guard fit

Okta stays the source of truth for the people behind every connection: who works here, which groups they are in, and when they leave. With Guard user provisioning, deactivating someone in your identity provider deactivates their managed Atlassian account. Service accounts cannot be provisioned from your identity provider, so their ownership record has to live where your change approvals live.

For Claude, Atlassian documents one more option: enterprise-managed authentication, also called Cross App Access. After the Okta-side setup, you turn on Allow enterprise managed authentication on the Authentication tab and add your Okta tenant URL. Access through Claude is then controlled by your identity provider's policies, such as app assignments, groups, and conditional access, instead of the domains list.

Guard supplements this on the Atlassian side. Any authentication policy can block members from creating or using user API tokens. With Guard Standard, a policy can also set when user API tokens expire, and an external user policy can block external users from API token access.

A checklist you can work through this week

1. Record the current state. Open Connectors, then Atlassian MCP server. Note the supported domains setting, your custom domains, whether API token authentication is on, and the Read, Write, and Search status per app.
2. Pull the last 30 days of tool calls. Filter the audit log for Rovo MCP User Actions and list every person and account that made a call.
3. Decide your client policy. Name the clients you approve. If any domain on Atlassian's supported list is not one of them, block the list and add back only the client domains you approve, including localhost patterns if you approve local clients.
4. Set permissions per app. Turn off Write where nobody needs it, and decide whether Apply to future additions stays on.
5. Turn off API token authentication unless a named pipeline needs it. If one does, move it to a service account API key with the minimum scopes, a short expiry, and the owner in the description.
6. Check tokens. In API token activity, flag tokens with no expiry, tokens held by leavers, and tokens nobody can explain. Revoke what has no owner.
7. Protect your most sensitive content. With Guard Standard, use the data security policy MCP control to block it from MCP reads.
8. Write the owner record and set the review date. One line per connection: owner, scope, credential, expiry, review date. Review the audit log monthly and scopes quarterly.

Where to start

If you do not know who has already connected, start with the audit log filter above. Our free Atlassian identity check then reviews the identities behind those connections: user API tokens and their expiry, single sign-on gaps, unowned service accounts, and Rovo agents, with a findings list ranked by risk and cost. We change nothing. If you already know the gaps, our agent usage policy and guardrails service sets ownership, scope, and off switches for MCP-connected agents, and our identity and access service designs one model for people and machine identities across Okta and Atlassian Guard.