Is It Safe to Connect Claude to Jira?

Safe enough if an Atlassian admin sets the permissions first. If nobody does, you’ve granted far more than the name suggests. You connect for Jira tickets, and the same connector reaches Confluence, Bitbucket, Loom and your service desk, with tools that make a page public and merge code.

I haven’t tested this connector. Everything here comes from public pages I read on October 31, 2026.

The listing in Claude’s directory shows 21 tools. Atlassian’s docs name 100 more that can change something, and the full catalog runs to about 250. The table of what 33 connectors can change compares it with your other apps.

Can Claude connect to Jira and Confluence?

Yes, through one connector. The listing says: “Search, read and update Jira, Confluence, Bitbucket, Loom and other Atlassian apps with your existing Atlassian permissions.”

Claude inherits each person’s permissions, so it can’t do what the person who connected it can’t do. It can do whatever that person can, in every Atlassian app they use.

What can Claude reach besides Jira tickets?

Confluence, Bitbucket, Loom and the service desk, mostly through four of the 21 listed tools. Atlassian’s docs describe discover as “Natural-language search over the deferred tool catalog”, and executeRead, executeWrite and executeDestructive as an “Execution pathway to run any deferred tools identified via discovery”.

These all come from the same page:

If your pipelines deploy, running one is a deploy.

Two Jira groups start off. The docs say delete_jira and manage_jira are “disabled by default”, and describe deleteJiraIssue as “Permanently delete an issue. Cannot be undone.” Leave both off. No other group on that page carries that note.

Can Claude make a Confluence page public?

Yes, if the person who connected can edit the page and an admin allows public links. On sites created on or after October 16, 2023, the site-wide toggle starts on and so does each space’s. The link on each page starts off.

Atlassian’s guide says public links “ignore any restrictions to who can access a parent item, the space, and the site itself”. It also says they “are not indexed by search engines”, so a stranger needs the actual link. They’re limited to paid Confluence plans.

If you don’t use public links, turn off the site-wide toggle in Confluence administration, under Settings, Security, Public links. Look at what’s live first, because Atlassian warns: “All active public links on your instance will be turned off and have to be manually turned back on.”

How do I limit Claude to just Jira?

Start with Atlassian. A block there applies whichever AI tool or Claude plan someone connects from.

In Atlassian. Go to Atlassian Administration, Connectors, Atlassian MCP server, Permissions. Use “Edit details” under Read, Write and Search to set each app separately. Admins “grant or revoke access at the permission-group level”, so you can’t keep one tool in a group and drop another. Creating a Confluence page and turning on its public link both live in write_confluence. The group names below come from that tool page.

Keep “Apply to future additions” off in that dialog. With it on: “New permissions won’t require manual review by admins and will be available to users as soon as they’re added.” Leave the row checkbox on the main table alone too, because the same page calls it “the same idea”. And new tools arrive “without the client needing to reconnect”.

This costs you something. Claude can’t draft a Confluence page or read a pull request linked from a ticket. For a first month I’d take that trade.

In Claude. On Team and Enterprise, an owner sets each tool to “Always allow, Needs approval, or Blocked”, and “individual users can’t override it.” Set executeWrite and executeDestructive to Blocked. Set the named Jira writes (createJiraIssue, editJiraIssue, transitionJiraIssue, addOrEditJiraIssueComment) to Needs approval. Leave executeRead allowed, since ordinary lookups like listJiraProjects aren’t on the listing and have to go through it. The Atlassian groups decide what it can read.

For sensitive spaces, Atlassian’s data security policy can block AI reads at “an organization, site, content object, or classification level”, even for people who can open that content themselves. It needs Atlassian Guard Standard (Guard Premium for the classification level) and is “enforced only for OAuth”.

Who can connect Claude to your Jira?

Anyone on your site, unless you’ve changed it. Atlassian says “we automatically allow the Atlassian-supported domains” by default, and its list includes claude.ai and claude.com. You can’t pick and choose: “You cannot block individual domains.” On Claude’s side, a Team or Enterprise owner has to enable the connector first, which does nothing about someone on a personal plan.

Each connection carries that person’s rights, so the group settings above are what keep a personal Claude account in check. API tokens are a separate door. Domain rules don’t apply to them, and the same settings page has the switch to turn them off. Unless a backend automation needs it, make sure it’s off.

Can a Jira ticket trick Claude?

Yes, and service desk tickets are the worst case, because strangers write them. Atlassian’s own post says that with a command hidden in data, “the model can be tricked into treating it as a legitimate user command.”

Researchers at Cato showed this against Atlassian’s server in 2025. As quoted by Simon Willison, an outside user “submits a malicious support ticket” and an internal user runs an AI action. The last step: “Data is exfiltrated to the threat actor’s ticket or altered within the internal system.”

Anthropic’s Cowork safety page names the two conditions: Claude “can read information outside your trusted boundary, and can perform actions that could compromise the user.”

Blocking the service desk groups doesn’t remove the outside text. Atlassian’s developer docs say each request has a “Jira platform Issue used to represent this Request”, so expect read_jira to open those tickets for anyone with access to the project. The fix is the account: connect with one that can’t see your service desk projects. Needs approval then puts a person in front of the action. If you read the prompt.

Can admins see what Claude did in Jira?

Yes, on every plan, with two gaps. Atlassian’s monitoring page marks tool logging “Available for all tiers”, and each entry has the tool name, action and user. Find it under Insights, then Audit log. Without Guard, you get 180 days of it.

The first gap is connections. The event for the first authorization needs Guard Standard, and “If additional users authorize the app, they do not appear in the audit log.” Keep your own list of who connected. The second is API tokens, where entries show “that account, rather than individual end users in the AI tool”.

Does Claude train on your Jira data?

Not by default on Team or Enterprise. Anthropic says “we will not use your inputs or outputs from our commercial products”, unless you report feedback.

On personal plans it’s a setting you choose. Training data “does not include raw content from connectors”, though it can include what’s “directly copied into your conversation with Claude”. On company plans, Anthropic keeps chats until someone deletes them, so a summary of a confidential ticket now lives in Claude too. If retention rules apply to you, ask whoever owns them. This isn’t legal advice.

How do I connect Claude to Jira safely?

1. Set the Atlassian groups from the table, and turn off “Apply to future additions”.
2. Make sure API tokens are off unless something needs them. Turn off public links if nobody uses them.
3. Set the tools in Claude as an owner, for the whole organization.
4. Connect with an ordinary account, not a Jira or Confluence admin, and one outside your service desk projects.
5. Test it on throwaway data. Ask Claude to read a Confluence page, publish it and merge a pull request. Each should fail or stop for your approval. A block on Atlassian’s side reads “Access denied: Your organization admin has not authorized”.
6. Check the audit log for your test. Write down who connected.

What I couldn’t confirm

• Which groups start switched on in a new organization, and whether “Apply to future additions” starts on. Check your Permissions tab.
• Whether a tool set to Needs approval in Claude can also run through executeWrite. Atlassian’s docs only say the execute tools run deferred tools, so keep executeWrite Blocked.
• Whether Claude asks before executeWrite when no owner has set it.
• Whether Cato’s attack works on today’s version. Cato’s report blocked my requests, so I read Willison’s quotes of it.
• Whether service desk tools work over a normal sign-in. The tool page says yes and the developer guide says API token only. Block them either way.

Should I connect Claude to Jira?

Yes, if someone with Atlassian admin rights will do this setup first. Searching and summarizing tickets is the useful part, and it needs very little of the catalog. If nobody owns those settings, wait. The listing warns that “Anthropic does not control which tools developers make available”, so reread the group list every few months.

For the rules around it, use the one-page connector policy in the QuickBooks post.

If you’d rather plan which of your tools to connect, and how, the setup planner asks six questions and gives you a plan without asking for an email. If you want a second look at a list you already have, bring your connected apps to a 30-minute call.