How to Block Specific Jira Projects from Atlassian MCP
Engineering wants Jira in Claude and Cursor for triage, sprint planning, and backlog work. Security wants the HR investigations project, the incident response board, and the M&A tracker kept away from every AI agent, including agents of people who belong to those projects. Until both requirements can be met, the Atlassian Rovo MCP server stays switched off.
This guide covers what Atlassian’s admin controls already handle, where they stop, and how a custom rule engine on MCP Manager’s gateway can block Jira projects from AI agents without disabling the server.
Key Takeaways
- The Atlassian Rovo MCP server acts with each user’s own Atlassian permissions, so an agent can reach every Jira project its user can see.
- Atlassian’s admin controls set one organization-wide policy: read, write, and search permissions per app, plus a data security policy control that can block MCP reads of specific Jira projects.
- A gateway rule adds what an organization-wide policy can’t express: different project boundaries per team, read-only access to specific projects, and one enforcement point across Atlassian and other MCP servers.
- Blocking takes two rules. A request-leg rule stops calls that name a restricted project, and a response-leg rule removes restricted items from JQL, board, and search results.
- An engine filters nothing until a gateway rule references it, so provision the gateway to a pilot team first and widen access only after every path behaves as intended.
Why Jira Permissions Are Not an Agent Boundary
Atlassian states that the Rovo MCP server never grants access beyond what the authenticated user already has. That floor is also the ceiling: every project a user can browse is a project their agent can search.
The difference is intent. A person opens one work item on purpose. An agent answering “what’s blocking the Q4 release?” runs JQL across every project in scope and reads whatever comes back. Descriptions and comments are untrusted text the model processes, so an instruction planted in a ticket can steer an agent that has write tools or other servers connected. Indirect prompt injection does not need a vulnerability in Jira, only access to content.
The usual fixes both fail: removing the person from the HR investigations project breaks their job, and turning the server off removes Jira from every AI workflow.
What Atlassian’s Native Controls Cover
Atlassian has added meaningful MCP controls, and a rollout should use them first. Scope at the source, and treat gateway rules as the layer on top.
- Permissions by intent: Organization admins can allow or block Read, Write, and Search for the MCP server, per app. Blocking Write for Jira stops every agent from editing any work item.
- Data security policy: Announced on September 29, 2026, the Atlassian Rovo MCP server control can block MCP reads of covered Jira work items even when the user has permission to view them. Blocked items drop out of JQL results, and direct requests return a “does not exist or you don’t have permission” response.
- Domain allowlist: Admins decide which AI tools may connect to the Rovo MCP server over OAuth 2.1.
Three properties define where these controls stop:
- One policy for everyone: Data security policy overrides target apps, spaces, and, on Atlassian Guard Premium, classification levels. The documented override types do not include users or groups, so engineering and finance agents get the same boundary.
- License and auth scope: The control requires Atlassian Guard Standard and is enforced for OAuth connections only, not API tokens.
- Per-app write permission: The Permissions tab turns write access on or off for Jira as a whole, not per project.
If one organization-wide boundary on reads is enough and you have Guard Standard, the data security policy may cover your case. An MCP gateway rule handles policies that vary by team, operation, or server.
Want to see how an MCP gateway separates human access from agent access? Book a demo with MCP Manager.
How a Rule Engine Sees Rovo MCP Traffic
MCP Manager’s gateway sits between the AI client and the Rovo MCP server and brokers each user’s own Atlassian identity. A gateway rule hands every tools/call to your custom rule engine on the request leg, the response leg, or both. The engine receives the JSON-RPC body plus metadata such as serverGuid and toolName, and answers with pass, block, modify, or error.
Tool Names Differ Between Rovo MCP v1 and v2
What toolName contains depends on the endpoint version. On Rovo MCP v2, the server advertises a small set of primary tools and lets clients find the rest through discover. Deferred tools then run through executeRead, executeWrite, or executeDestructive, depending on risk tier. For those calls, the gateway sees the wrapper as the tool name, and the real tool and its arguments sit inside the call’s arguments.
Connections on the v1 endpoint are documented to start exposing v2 tools on March 1, 2027. Until then, the tool names a v1 connection returns are only known from its live tool list.
The Mcp-Name Header Does Not Identify the Project
The 2026-07-28 MCP spec puts the tool name in the Mcp-Name header so gateways can authorize without parsing the body. For a deferred Jira call, that header carries the execute wrapper, not the operation or the project. Project-level policy still requires inspecting the JSON-RPC body.
Build the Parser from Live Payloads
Atlassian also documents a flat, paginated tool list for gateways that need every tool up front. Because tool names and payloads differ between endpoint versions, the parser should be built from the live tool list and captured payloads of the connected endpoint, not from older examples.
Step-by-Step Guide to Building Jira Project Controls
To block Jira projects from Atlassian MCP with MCP Manager, a custom rule engine is attached to a gateway rule that sits between the AI client and the Atlassian Rovo MCP server. The engine inspects each tool call and result, and blocks or filters anything that belongs to a restricted project. The setup should be built and tested with a pilot team before the gateway is provisioned more widely.
Step 1: List the Projects and All of Their Keys
Collect the key of each project to block. Atlassian’s UI now calls Jira projects “spaces,” while tool names such as listJiraProjects keep the older term.
Include previous keys. Admins can change a project’s key, and Jira saves previous keys so links and queries using them keep working. A list with only current keys misses requests that use an old one.
Then choose the list type. A blocklist is simpler when a handful of projects are sensitive. An allowlist fails closed, so a newly created project stays out of reach until someone approves it.
Step 2: Connect the Rovo MCP Server and Close the Side Door
Before connecting, an organization admin adds MCP Manager’s OAuth callback to the Rovo MCP server’s allowed domains. The server is then added in MCP Manager with Atlassian’s primary endpoint, https://mcp.atlassian.com/v1/mcp, as described in the Connect Atlassian Rovo guide. Each user approves Atlassian’s consent screen and selects the sites to authorize, so every call runs under their own identity.
The same allowlist that admits MCP Manager also decides whether users can connect Claude or Cursor directly to Atlassian and skip the gateway. Gateway rules only apply to traffic that passes through the gateway, so review which other domains stay allowed and work through the MCP Enterprise Lockdown Checklist.
Troubleshooting tip: If the connection succeeds but most Jira tools return “401 unauthorized, scope does not match” while getAccessibleAtlassianResources still works, the endpoint variant is a possible cause. In one proof of concept, the team had connected Atlassian’s OAuth 2.1 variant URL (/v1/mcp/authv2), and reconnecting on the primary URL resolved the error.
Note: Atlassian Rovo MCP v2 is generally available at /v2/mcp, and from March 1, 2027, v1 connections expose v2 tools automatically. Tool names in the rule should therefore be checked against the live tool list.
Step 3: Pin the Tool Surface with Feature Provisioning
Before writing code, shrink what the rule has to cover. Feature provisioning under “Allow if conditions are met” exposes only the tools on your allowlist, and fails closed for anything else.
That matters for Jira because the tool list keeps changing. Atlassian adds tools to permission groups that users have already approved, and the tools appear in their sessions shortly after, without a new approval step. In September 2026 alone, the changelog lists six new Jira tools and one renamed tool. An MCP gateway allowlist keeps each new or renamed tool away from agents until someone has checked that the rule can parse its payloads.
Three choices are worth making here:
- Hide downloadJiraIssueAttachment unless agents need it. It returns a short-lived download URL, so the file itself never passes through the gateway for inspection.
- Leave delete and manage tools off. Atlassian disables the delete_jira and manage_jira groups by default, but an organization admin can enable them. Leaving them off the gateway allowlist keeps them unreachable through the gateway either way, unless a specific use case requires them.
- Block prompts and resources unless needed. Gateway rules inspect tools/call traffic only.
Step 4: Build the Request-Leg Rule for Writes and Direct Reads
The request rule fires before a call reaches Atlassian. It covers tools that name their target:
- Writes such as createJiraIssue, editJiraIssue, transitionJiraIssue, addOrEditJiraIssueComment, and createJiraIssueLink.
- Direct reads such as getJiraIssue and listJiraIssueComments.
The engine unwraps execute calls, reads the project or work item key from the arguments, and blocks calls to restricted projects. A call that should name a target but doesn’t is blocked too.
This is also where per-project read-only access lives. Blocking write-tier operations for a project while passing its reads lets agents summarize the incident board without commenting on or transitioning its tickets.
Step 5: Build the Response-Leg Rule for Search and Aggregates
JQL and cross-product search take a query, not a project, and return matches from every project the user can see. The response rule removes restricted items with a modify verdict, so the agent still gets legitimate results.
MCP Manager’s allowlist recipe for channels, projects, and spaces provides example request-leg and response-leg handlers. These are instructional starting points, not production-hardened code, so Jira’s tool names and payload paths have to be mapped and tested against captured responses.
Jira adds cases the recipe doesn’t cover:
- Aggregate tools: searchJiraIssuesUsingJql, getJiraBoardIssueData, getJiraBoardSprintData, and listJiraProjects all return lists that need filtering, along with any total or pagination fields.
- Related work items: A permitted work item can reference a parent or linked work item in a restricted project. Check captured payloads for those fields, and decide whether a key alone is acceptable or its summary must go too.
- Other identifier formats: getTeamworkGraphObject accepts ARIs or URLs, and Rovo’s search spans Jira, Confluence, and connected apps. The parser must recognize every form found in real payloads, not only KEY-123.
- Unparseable results: A result from a covered tool that can’t be parsed is blocked rather than passed unchecked.
For direct requests, a not-found style error, as Atlassian’s data security policy uses, avoids confirming that the restricted project exists.
Step 6: Deploy, Register, and Apply
The engine needs a public HTTPS endpoint with a public CA certificate, HTTP 200 for every verdict, responses well under the 30-second timeout, and idempotent handling, since failed attempts are retried. Authenticate calls with a static header configured on the engine, and allowlist MCP Manager’s static outbound IP. Enable header forwarding only if the engine must call Atlassian as the user, for example to resolve an ARI, because it passes the user’s tokens to your service.
Register the engine under Rule Engines with the Custom provider, then add a rule on the gateway’s Rules tab that uses it, with the failure mode left at Block.
Troubleshooting tip: If blocked projects still show up in agent responses, check the gateway’s Rules tab. Registering an engine under Rule Engines does not activate it, and an engine filters nothing until a gateway rule references it.
Step 7: Test with a Pilot Team
Until the rule is applied, agents on the gateway reach everything their users’ Atlassian permissions allow. Provision the gateway to a team of two or three admins only, then run prompts that exercise each path:
- Fetch a restricted work item by its current key and by a previous key.
- Run a JQL search that spans restricted and permitted projects.
- Ask for the active sprint on a board that pulls from several projects.
- Comment on a work item in a read-only project.
Confirm each verdict in the logs, where the engine’s comment names the project and tool. Read result bodies, not only the status: under the MCP spec, a tool that fails upstream returns a normal result with isError: true, so an Atlassian 401 may look like a successful call. Widen access only after every path behaves as intended.
Custom rule engines are one of MCP Manager’s advanced features. Get a pricing quote for your team.
What Building a Custom Jira Rule Engine Includes
A Jira project rule is code your team owns. The work is bounded, and one engineer can own it. In one proof of concept, an engineering team built a comparable Slack engine in about a week.
Building the engine includes:
- A webhook with a parser per Jira tool and the four verdicts
- A public HTTPS endpoint with monitoring
- Tests against captured payloads
- Updates when Atlassian adds or renames tools
Three ownership points should be settled before the build starts:
- Maintenance: The people who administer Jira are often not the people who maintain a web service, so the parser needs a named engineering owner.
- Security review: InfoSec will ask how coverage of every path is demonstrated. The engine’s test cases, captured payloads, and logs are the evidence.
- Operations: The engine sits in the path of every Jira call. With the default failure mode, an outage blocks calls, which is safe but pauses Jira MCP until the service recovers.
MCP Manager supports you through the build. Point a coding agent at the MCP Manager docs for agents and let it draft most of the engine, then review the result like any other code before it enforces policy. The custom rule engine tutorial walks you through registration end to end. If you get stuck, product support is available through in-product chat and tickets on every plan, and Enterprise and higher-tier plans add a dedicated Slack channel.
Real-World Scenarios for Blocking Jira Projects
Typical Jira projects teams need to keep away from agents are HR investigations, security incident boards, and support queues with customer data, and each one calls for a different kind of rule. The four scenarios below show which rule fits which situation:
- Engineering first, everyone else next: Each department gets its own MCP gateway, because the gateway is the smallest unit of governance. The engineering gateway blocks the HR and legal projects. The product gateway blocks the same projects plus the security incident board. Both use the same Atlassian server with different rule sets.
- Security and vulnerability board: Engineers need this board for their jobs. An agent asked about open bugs in the checkout flow should still not pull unpatched vulnerability details into a model. A full block on the board keeps that content out, while the engineer’s own Jira access stays unchanged.
- Release planning that agents may read but not edit: Agents can summarize the roadmap project for status updates. Write-tier operations can be blocked for that project, so tickets cannot be commented on, edited, or transitioned.
- Support projects with customer data: Tickets often contain pasted customer email addresses. A project rule keeps agents out of support projects they do not need. A Presidio rule set to Replace turns detected entities in the remaining projects into typed tags such as <EMAIL_ADDRESS>. Presidio is less reliable for names in free-form text, so regex rules should cover structured identifiers.
Atlassian MCP Without the Risk: Block Jira Projects at the Gateway
To block Jira projects from Atlassian MCP, the boundary has to apply to the agent and not to the person. Jira permissions decide what a person may see, so every project a user can open is also a project their agent can search. Atlassian’s permissions and data security policy now set an organization-wide floor, and a custom rule engine on MCP Manager’s gateway adds the per-team, per-project, and per-operation rules that this floor cannot express.
The engine is code that your team builds, hosts, and maintains, and the work is bounded: one engineer, a request-leg rule, a response-leg rule, and tests against captured payloads. Apply and test the rule with a pilot team before anyone connects, and Jira stays available to every AI workflow except the projects that must stay out.
If your organization is holding back the Atlassian Rovo MCP server because of a few Jira projects, book a demo with MCP Manager and scope the rule that unblocks it.
FAQ
Can I block specific Jira projects from AI agents without disabling the Atlassian MCP server?
Yes. A request-leg rule blocks calls that name a restricted project, and a response-leg rule removes restricted items from JQL, board, and search results. Everything else passes through, so the Atlassian Rovo MCP server stays enabled and Jira remains available to agents for all other projects.
Should I use Atlassian’s data security policy or a gateway rule?
Both fit together. Atlassian’s data security policy blocks MCP reads of covered spaces for the whole organization, requires Atlassian Guard Standard, and applies to OAuth connections only. A gateway rule adds per-team boundaries, per-project write control, and the same enforcement across other MCP servers.
Does blocking a Jira project change anyone’s access in Jira?
No. The rule only changes what agents receive through the gateway. Project roles, permissions, and the Jira UI stay untouched, so people keep full access to their projects. Only the AI agent acting on their behalf is kept out of the restricted projects.
Can agents read a Jira project but not change it?
Yes, as a policy choice. For each project, a request-leg rule can either block write-tier operations such as creating, editing, commenting, and transitioning, or let them pass. Blocking them while reads pass lets agents summarize a project without changing it. Atlassian’s own write permission is set per app, not per project.
Does the same rule engine cover Confluence spaces?
Yes. Confluence tools come from the same Rovo MCP server, so one engine can route on the tool name and apply a space policy next to the project policy. Each policy needs its own parsing, because Confluence payloads differ from Jira payloads.
Is a managed Jira project blocker available?
Not today. Jira project blocking runs on a custom rule engine that your team builds and hosts. If you need a managed option, you can raise it with your MCP Manager contact or when booking a demo.
