Secure Jira and Confluence access for AI agents

Through Atlassian, agents can search and read Jira issues and Confluence pages, and create or update them when your policies allow it – every call runs through your policies and is logged for audit. A single resource covers both products.

Server URL: https://mcp.atlassian.com/v1/mcp

Credential modes

Atlassian supports per-org dynamic registration only, so there is no app to create on Atlassian's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.

Before you begin

• An Atlassian Cloud site with Jira, Confluence, or both.
• Administrator access to your Atlassian admin console at admin.atlassian.com, to allowlist the gateway origin on the Rovo MCP server config.
• Administrator access to your Agent Authority workspace, to add the resource.

Setup

1. In the Agent Authority console, go to Resources and click Add Resource.
2. Select Atlassian from the catalog.
3. On Choose how to install Atlassian, click Per-org dynamic registration. Selecting it adds the resource right away with its tools and scopes pre-configured.
4. Allowlist the gateway origin in Atlassian, as described in Dynamic client registration below. Without this step, user sign-in still succeeds but every tool call fails at runtime.

After you add the resource, an Admin setup required dialog appears. Its Setup guide button links to the section below.

Dynamic client registration

When you add the resource, the gateway registers its own OAuth client with Atlassian – the credential that lets it sign users in. The one piece of setup Atlassian requires is allowlisting the gateway origin on the Rovo MCP server config.

In your Atlassian admin console at admin.atlassian.com, go to Settings → Rovo → Rovo MCP server → Domains and add your gateway origin under Your domains:

https://oauth.aisecurity.services.<region>.connect.secureauth.com/**

Replace <region> with your region (us, eu, or aus). The /** suffix authorizes any path under that origin.

Verify the connection

The gateway syncs the Atlassian tools automatically. To check the connection end to end, ask your agent to run a request:

List my Jira projects

If your projects come back, the connection is working. If sign-in succeeded but tool calls fail, the gateway origin is most likely still missing from the Rovo MCP server allowlist.

How users connect

Access is per user. Each additional user connects their own Atlassian account the first time their agent calls an Atlassian tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. A single resource covers both Jira and Confluence. Go to Connections to manage linked accounts.

Available tools

Tool names are matched exactly by policy rules unless you use a wildcard, so copy them from here verbatim – and check the Available Tools card on the resource's Overview tab in the Agent Authority console for the authoritative list of what your install actually exposes.

Required scopes

The gateway requests these scopes automatically when it registers the client, so there is nothing for you to configure. Atlassian decides what to grant, and any scopes it returns during registration replace the list below.

• read:jira-work – read projects, issues, and comments
• write:jira-work – create and update issues, comments, and worklogs
• read:jira-user – read Jira user information
• manage:jira-project – manage project-level configuration
• manage:jira-configuration – manage global Jira configuration
• read:confluence-content.all – read all Confluence content including pages and blog posts
• read:confluence-content.summary – read content summaries
• write:confluence-content – create and update Confluence content
• read:confluence-space.summary – read space summaries and metadata
• write:confluence-space – modify space settings
• read:confluence-user – read Confluence user information
• read:confluence-groups – read Confluence group membership
• read:confluence-props – read content properties
• write:confluence-props – write content properties
• search:confluence – search Confluence content
• offline_access – maintain access when the user is offline

Policy examples

Rules are evaluated top to bottom and the first match wins; a call that matches no rule is denied. New rules are created at the top of the list, so create the rule you want evaluated last first.

• Read-only access: allow get*, search*, fetch, atlassianUserInfo, lookupJiraAccountId, then disable or delete your organization's seeded Allow all rule. The allow rule alone restricts nothing – createJiraIssue, editJiraIssue, transitionJiraIssue, and every other write tool keep matching Allow all. Removing it is org-wide, so add the allows everything else needs first; alternatively keep Allow all and use the deny recipe below.
• Block writes: add deny rules for create*, edit*, update*, transition*, addCommentToJiraIssue, addWorklogToJiraIssue above any allow rules.
• Allow full access for a specific agent: scope an allow rule for * to agent claude-code on this MCP server. This grants – it does not restrict other agents, who fall through to whatever rule matches next.

Next steps

• Create a policy – start from the read-only pattern in Policy examples above.
• Give Claude read-only access to Jira – a worked policy for this exact resource.