Give Claude read-only access to Jira

You want Claude to pull context from Jira: what's the status of ENG-123, who's the assignee, what did the last comment say. You don't want it filing tickets, editing fields, or moving a ticket through its workflow while you're still deciding how much to trust it. One policy rule gets you there: every read tool allowed, everything else denied by default.

What you'll need

• The Atlassian resource added to your gateway (Add Atlassian)
• Claude Desktop connected as an agent (Connect Claude Desktop)
• Admin access to Access Policies

Steps

1. Navigate to Access Policies and click Add Rule.
2. Name it something that describes the intent, for example "Claude: read-only Jira and Confluence."
3. Set the effect pill to Allow.
4. Set the MCP scope pill to Atlassian, so the rule only ever matches this resource.
5. Open the tools pill and add these patterns one at a time, pressing Enter after each: get*, search*, fetch, atlassianUserInfo, lookupJiraAccountId. Together they match every read tool the Atlassian MCP server exposes, including getJiraIssue, searchJiraIssuesUsingJql, search, getConfluencePage, and getVisibleJiraProjects, and none of the write tools like createJiraIssue or transitionJiraIssue.
6. If Atlassian is shared with agents other than Claude and you want this restriction to apply only to Claude, also set the Agent scope pill to Claude — Claude Desktop registers under the Claude agent type.
7. Set the status to Active.
8. Click Create.

You don't need a separate deny rule. Without any rules, all requests are denied by default, so createJiraIssue, editJiraIssue, transitionJiraIssue, addCommentToJiraIssue, addWorklogToJiraIssue, and every Confluence write tool stay blocked simply because no rule allows them. If your organization still has the default Allow all rule, disable or delete it first — otherwise calls that match no other rule fall through to it and succeed, and this rule restricts nothing.

Removing Allow all is org-wide, not Jira-wide: every agent and resource whose access was quietly riding on that fall-through — a CI agent on GitHub, anything you haven't written a rule for yet — is denied the moment it's gone. Write the allow rules those workloads need first, then remove it.

Want to go further and restrict reads to specific Jira projects? Add a CEL condition to the same rule:

!has(request.args.projectIdOrKey) || request.args.projectIdOrKey in ["ENG", "INFRA"]

The has() guard matters here: only the project-metadata tools (getJiraProjectIssueTypesMetadata, getJiraIssueTypeMetaWithFields) take a projectIdOrKey argument — an issue-level tool like getJiraIssue reads by issueIdOrKey and has no project field to check. This condition scopes those two tools to ENG and INFRA; it doesn't restrict getJiraIssue or searchJiraIssuesUsingJql, since neither one carries a project argument the gateway can evaluate. If you need every read scoped by project, enforce it in Jira's own permission scheme — the policy engine can only gate on fields a tool's schema actually exposes.

Verify it works

1. Ask Claude something that requires a read, for example "what's the status of ENG-123?" It should answer using getJiraIssue or searchJiraIssuesUsingJql.
2. Ask Claude to comment on or transition that same issue. Most often Claude will answer that it has no such tool rather than failing a call: denied tools are filtered out of the tool list it receives at connect, so it never sees addCommentToJiraIssue to attempt it. If it does try, the call fails.
3. Open Agent Trail (Audit log) and confirm the read tool executed successfully. If Claude did attempt the write, that row shows a gateway.tool.error with error_type: blocked_by_policy and no rule name — the call matched no rule at all, which is the default deny working. Only an explicit Deny rule gets named on the entry. If Claude never attempted the call, there's no row to find, which is the expected outcome.

Next steps

• Credential modes — Atlassian only supports dynamic client registration; see how that compares to the other catalog resources.
• Block an agent from deleting GitHub branches — the same deny-by-default shape applied to a different resource.
• Tags — once you have more than one agent reading Jira, tag them instead of editing this rule per agent.