Atlassian Rovo Security and Rovo MCP Server Governance for Jira and Confluence
Atlassian's Rovo MCP server lets Claude, ChatGPT, Cursor and other AI clients search, create and update Jira and Confluence content. Atlassian ships real admin controls for it, and its own documentation draws the line where they stop. This page shows what is covered, what API tokens skip, and when a second control is worth paying for.
Direct answer
Atlassian Rovo security for the MCP server rests on four admin controls: allowed client domains, a switch for API token authentication, a data security policy that can block agents from reading covered Jira and Confluence content, and MCP usage logs. Atlassian states that domain controls and data security policies apply only to OAuth 2.1, not API tokens, and that clients act with the signed-in user's existing permissions. None of it inspects the arguments of a write call or holds one for a second approver.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A US software company connects an AI coding assistant to Jira and Confluence through the Rovo MCP server so engineers can turn a spec into epics in seconds. It works well. Then a support engineer asks the same assistant to summarize an inbound ticket that came from a customer form. The ticket text carries instructions, the assistant follows them with the engineer's permissions, and internal tickets end up quoted in a public comment. Security researchers demonstrated exactly this pattern against Atlassian's MCP server in 2025. The admin console showed a healthy OAuth connection the whole time, because nothing was wrong with the connection. The problem was the action.
How AgentShield handles it
Use Atlassian's controls first. Allow only the AI client domains you have reviewed, turn API token authentication off unless a tool truly needs it, set a data security policy on projects and spaces the agents have no business reading, and review MCP usage logs. Then put an AgentShield gateway in front of the write paths your own agents use. Rules check the arguments of each call, so a comment on an externally visible ticket, a bulk edit or a page deletion waits for a named approver, and every allowed and denied action lands in one record.
The controls
The controls that secure which Jira and Confluence writes a Rovo MCP client can make, and which wait for a named approver.
What the Rovo MCP server secures natively
Atlassian documents the Rovo MCP server controls clearly, and the honest summary is that they decide who may connect and what content is visible, not what a connected agent may do with the access it has. These facts come from Atlassian's support documentation and its general availability announcement of February 4, 2026, read in October 2026.
| Control | What it does | Where it stops |
|---|---|---|
| Allowed domains | Admins can allow Atlassian-supported domains, add custom domains and delete ones they no longer trust, under Connectors in Atlassian Administration | Atlassian says you can only block domains for AI tools that use OAuth 2.1, not when they use API tokens |
| API token switch | An authentication setting turns API token access on or off. OAuth 2.1 is the default and recommended method | Turning tokens off does not change allowed domains or IP allowlists. Tools with tokens are governed by IP allowlists and token scopes |
| Data security policy | Lets an organization admin allow or block AI agents from reading Jira and Confluence data through the MCP server, at organization, site, content object or classification level | Needs Atlassian Guard Standard, and classification coverage needs Guard Premium. Enforced only for OAuth, not API tokens |
| IP allowlists | Apply to both OAuth and API token requests, and a blocked IP gets a permission error | Network location says nothing about what the request does |
| MCP usage logs and audit | Show how AI clients interact with Jira and Confluence, for audit and governance | Records activity after it happened. It does not stop a call |
| Existing user permissions | The client acts only where the signed-in user can act | Atlassian's disclaimer says clients can perform actions in Jira, Confluence and Compass "with your existing permissions" |
When a data security policy blocks agents, Atlassian says covered Jira work items are excluded from results, including JQL searches an agent runs, and a request for a specific item returns a response saying it does not exist or you lack permission. That is a clean read-side control. Atlassian also warns that agents which expect covered content may return incomplete results after a change, so tell the teams that depend on them before you switch it on.
What a signed-in user's permissions allow an agent to do
The Rovo MCP server was built so an AI client can work as the person using it. According to Atlassian's announcement, that includes creating and updating Confluence pages and creating Jira epics and issues in the right project and linking them to pages. Atlassian's admin documentation recommends least privilege, reviewing high-impact changes before confirming them and monitoring audit logs. That advice is correct, and it places the burden on the person at the keyboard and the permission scheme behind them.
| Action an MCP client can take | Why a clean OAuth connection does not make it safe |
|---|---|
| Read tickets and pages through search and fetch | Ticket and page text is untrusted input. A customer-submitted ticket can contain instructions the model reads as part of the task |
| Create issues and epics | An agent that misreads a spec can create hundreds of issues in a live project, and each one notifies people |
| Create or update Confluence pages | An edit to a runbook or policy page is a change other people will trust and follow |
| Comment on a ticket | On a service project with an external reporter, a comment can carry internal content out of the company |
| Act as an engineer with broad project access | The agent inherits everything that person can reach, including projects unrelated to the task |
Atlassian's own design means identity checks pass for every one of these. The user is real, the token is valid and the project permission allows the write. What is missing is a check on the specific action: this comment, on this ticket, with this content, from an agent that has just read untrusted text.
The Jira Service Management injection pattern, and what it teaches
In June 2025 Cato Networks published a proof of concept against Atlassian's MCP server using Jira Service Management. An outside party submits a crafted support ticket, and a support engineer later uses an MCP-connected AI tool to process it. The injected prompt told the assistant to collect other internal tickets and post them as a comment on the attacker's ticket. Cato called the pattern "Living off AI", and commentators described it as the lethal trifecta: private data, untrusted input and a channel to the outside in one setup. Atlassian's spokesperson said at the time that the company was exploring enhanced controls for MCP clients.
Atlassian has since shipped the data security policy, domain controls and usage logs described above, which narrow what an agent can read. They do not look at the content of a comment before it posts. If your support engineers use an AI client on tickets from the public, the pattern is still yours to close. Our page on MCP server security covers the general case, and the same rule applies here: treat every ticket body as hostile text and put the decision on the write, not on the read.
Atlassian Rovo governance checklist for US Jira and Confluence admins
- Open Connectors under the Atlassian MCP server in Atlassian Administration and list the allowed domains. Delete any AI tool your security team has not reviewed.
- Decide whether any tool needs API token authentication. If not, switch it off, because domain controls and data security policies do not apply to tokens.
- If you use IP allowlisting, confirm that it also covers MCP requests, and test a blocked address.
- Write a data security policy for projects and spaces that hold HR, legal, security or customer data, and decide who learns that agent searches will now return less.
- Review MCP usage logs weekly for the first month. Look for one user driving unusual volumes of writes.
- Identify the service projects with external reporters. Require that any AI client reading those tickets cannot post a comment without a human review.
- Give engineers who use AI clients the narrowest project roles that still let them work, because the agent inherits whatever they hold.
- Name who approves a bulk edit, a page deletion or an externally visible comment from an agent, and how fast they respond.
Where a second control earns its place
An AgentShield gateway sits on the paths your own agents use to reach Jira and Confluence APIs. It does not replace Atlassian's controls. It adds the one check Atlassian's design leaves out, which is a decision on each write based on its arguments.
| Risk | Atlassian's control | Second control |
|---|---|---|
| Unknown AI client connects | Domain allowlist and the API token switch | None needed. Use Atlassian's setting |
| Agent reads a space it should not | Data security policy | None needed for OAuth clients. Turn tokens off |
| Comment on an external ticket carries internal content | User permission only | Rule on the comment target and a scan of the content, then hold for a named approver |
| Bulk issue creation or edit | User permission only | Count limit per run and per day, approval above the limit |
| Page deletion or policy page edit | User permission only | Always held for a named approver |
| Proof for an audit of what the agent did | MCP usage logs | One record across Atlassian and every other system the agent touches |
The second control works on agents you build or route yourself, through a gateway endpoint. It cannot sit inside a vendor's hosted client that talks straight to Atlassian's remote server, which is why the Atlassian settings come first.
When to buy nothing, use Atlassian controls, or add AgentShield
| Your situation | What to do |
|---|---|
| Your team uses an AI client against Jira only for reading and searching | Buy nothing. Set domains, turn API tokens off and apply a data security policy |
| You have Guard Standard and need to hide sensitive spaces from agents | Use the data security policy. Check classification coverage against Guard Premium |
| You need a record of AI activity inside Atlassian only | Use MCP usage logs and audit logs |
| Agents you build write to Jira and also to billing, email or code systems | Add a gateway so one rule set and one record cover every system |
| Support engineers run AI tools on tickets from the public | Add argument rules and approval on comments and bulk writes |
| You need a defensible control in days, on a published price, without a program | Add the gateway in observe-only mode, then switch rules to enforce |
Three of six rows end without a purchase from us. If your team also tracks work in a service desk, see our ServiceNow AI agents security page for the matching gaps there, and human approval for AI agents for how to decide which actions deserve a person. The wider MCP gateway page explains how the enforcement point works.
FAQ
Common questions about atlassian rovo security.
Is Atlassian Rovo secure?
Atlassian hosts the Rovo MCP server on its cloud and applies existing user permissions, OAuth 2.1 by default, domain controls, a data security policy and usage logs. What it does not do is judge a specific write. An agent acting as a signed-in user can still create, edit or comment within that user's permissions, so high-impact actions need a second check.
What is the Atlassian Rovo MCP server?
It is an Atlassian-hosted remote server, generally available since February 4, 2026, that lets MCP-compatible AI clients such as Claude, ChatGPT and Cursor search and fetch Jira and Confluence content, create issues and epics, and create or update Confluence pages. Clients sign in with an Atlassian account and act with that user's permissions.
Can admins block AI agents from reading Jira and Confluence data?
Yes, through a data security policy. An organization admin can block agents from reading covered content at organization, site, content object or classification level. It needs Atlassian Guard Standard, classification needs Guard Premium, and it is enforced only for OAuth, not API tokens.
Do API tokens bypass the Rovo MCP server controls?
Partly. Atlassian says domain blocking works only for tools using OAuth 2.1, and data security policies are enforced only for OAuth. Tools using API tokens are governed by IP allowlists and token scopes. Admins can switch API token authentication off in the Authentication section.
Can a prompt injection in a Jira ticket make an AI agent leak data?
It can. In 2025 Cato Networks showed a crafted Jira Service Management ticket that told an MCP-connected assistant to copy internal tickets into a comment on the attacker's ticket. Atlassian's newer read controls help, but nothing inspects a comment before it posts, so write actions on public-facing tickets need review.
How do I audit what AI agents did in Jira and Confluence?
Atlassian provides MCP usage logs and audit logs showing how AI clients interact with Jira and Confluence. They cover Atlassian activity only. If the same agent also writes to billing, email or code systems, a gateway record that joins every action in one place gives a single trail for auditors.
Does AgentShield work with Atlassian Rovo?
Yes, for agents you build or route through a gateway, where it checks the arguments of Jira and Confluence write calls and holds risky ones for a named approver. It cannot sit inside a vendor-hosted client that connects straight to Atlassian, so set the Atlassian admin controls first.
More use cases