How to Block Confidential Confluence Spaces from Atlassian MCP
Product, support, and engineering teams want Confluence in Claude and Cursor, because that is where runbooks, specs, and onboarding guides live. The same site also holds the HR space, the legal playbook, board materials, and incident postmortems. Many people who need the first group of spaces can also open the second, and every space they can open is a space their AI agent can search through the Atlassian Rovo MCP server.
This guide shows where Atlassian’s admin controls stop and how a custom rule engine on MCP Manager’s gateway blocks specific Confluence spaces from AI agents while every person keeps their permissions.
Key Takeaways
- The Atlassian Rovo MCP server acts with each user’s own permissions, so an agent can reach every Confluence space its user can view.
- Atlassian’s data security policy can block MCP reads of chosen spaces, but for the whole organization at once.
- An MCP gateway rule adds per-team space boundaries, read-only spaces, and one enforcement point across MCP servers.
- Confluence content IDs don’t identify their space, so writes must be resolved to a space before they reach Atlassian.
- A Confluence space rule runs on a custom rule engine, which means the code must be built, hosted, and maintained by your team.
Can an AI Agent Read Every Confluence Space Its User Can Open?
Each user authorizes the Rovo MCP server with their own Atlassian account, and the server only exposes the spaces that account can already access. The AI agent inherits the person’s space permissions and page restrictions unchanged.
What changes is how that access gets used. A person opens the legal playbook for a contract question. An agent asked about the remote work stipend runs a CQL search across every space in scope and reads whatever ranks, including a draft compensation proposal in the HR space. Page bodies, comments, and space instructions are untrusted text the model processes, so an instruction planted in a page can steer an agent that has write tools or other servers connected.
AI clients that keep memory across chats can also resurface a restricted page in an unrelated conversation, so enforcement has to happen before a result reaches the client.
What Can Atlassian Admins Restrict on Their Own, and What Is Left Open?
Atlassian Administration offers two settings that belong in every rollout. The first is the Permissions tab under Rovo MCP server, where Read, Write, and Search can be allowed or blocked per app. The second is the Atlassian Rovo MCP server control in the data security policy, announced September 29, 2026. It can block MCP reads of covered pages, spaces, and classified content even when the user can view them, and its overrides can name up to 2,000 spaces.
Four things stay open:
- One boundary for everyone: Override types are apps, spaces, and, on Atlassian Guard Premium, classification levels. Users and groups are not among them.
- License and auth scope: The policy requires Atlassian Guard Standard and covers OAuth connections only, not API tokens.
- Space metadata: With reads blocked, MCP may still list spaces and create a space.
- Write access: Write is set per app, so no setting makes a single space read-only for agents.
Where an MCP Gateway Closes the Gap
An MCP gateway is one governed URL between the AI client and the Atlassian Rovo MCP server. The client connects to the gateway only. With per-user identities, the gateway forwards each request under the person’s own Atlassian identity. It applies rules to the request and the result and logs every call.
The person’s Confluence account and permissions stay unchanged. Only what the agent receives through the gateway changes.
A gateway is also the smallest unit of governance. Different space policies for different teams mean different gateways, each provisioned to its own team. To block Confluence spaces from Atlassian MCP, a custom rule engine is needed that the team builds and hosts.
| Question | Atlassian data security policy | MCP gateway rule |
| Block reads of chosen spaces | Yes, organization-wide | Yes, per gateway |
| Different boundary per team | Not among the documented override types | Yes, one gateway per team |
| Read-only space | No, write is set per app, not per space | Yes, by blocking write-tier calls to that space |
| Covered connections | OAuth only | All traffic routed through the gateway |
| Space listing under a read block | Still reachable | Can be filtered on the response leg |
| Other MCP servers | Atlassian only | Any server on the gateway |
| Setup | Admin settings, Guard Standard | Custom rule engine, code hosted by the team |
Need to keep a few spaces out of a Confluence rollout? Book a demo with MCP Manager.
What a Rule Engine Has to Work Out Before Blocking a Confluence Space
A gateway rule hands every tools/call to the custom rule engine, a webhook that answers with pass, block, modify, or error. Each call can be inspected on both legs.
- Request leg: The tool arguments are checked before they reach Atlassian.
- Response leg: The result is checked before it reaches the client.
- Metadata: The engine receives details such as serverGuid and toolName with each message.
- Scope: Rules apply to tool calls only, not to prompts or resources.
The built-in detection methods, regex and Microsoft Presidio, match patterns in message text. Deciding which space a call touches needs the custom engine.
Confluence traffic adds some complications. A numeric content ID carries no space prefix, so a request to getConfluenceContent rarely reveals its space. On Rovo MCP v2, most Confluence tools are deferred and run through executeRead, executeWrite, or executeDestructive, so the Mcp-Name header required by the 2026-07-28 MCP spec names the wrapper, and space policy still means parsing the JSON-RPC body. Finally, a tool that returns structuredContent should also return it as text under the MCP tools specification, so a rule must filter both copies.
None of these is a blocker. Each one is solved by resolving the space before a write is forwarded and by filtering both copies of a result, which the steps below cover.
Step-by-Step Guide to Blocking Confluence Spaces From AI
Build and test each step with a pilot team before provisioning the gateway more widely.
Step 1: Map Every Restricted Space to Its ID
Record each restricted space’s numeric space ID, its current key, and any earlier key. App admins can edit a Confluence space key, and Confluence’s space APIs have kept returning the original key after an edit, so payloads can carry either form. Key the policy on space IDs and map every key to them.
Then choose the list type:
- An allowlist fails closed, so a Confluence space created later by anyone with the Create Space permission stays out of reach until approved.
- A blocklist is simpler for a handful of sensitive spaces, but each new one stays exposed until added.
Step 2: Connect Rovo MCP Through the Gateway Only
Connecting the Atlassian Rovo MCP server takes three moves:
- Allow the callback: An Atlassian organization admin adds MCP Manager’s OAuth callback URL to the Rovo MCP server’s allowed domains.
- Add the server: The Rovo MCP URL is pasted into MCP Manager, which detects standard OAuth with dynamic client registration, so no client ID or secret is needed.
- Approve access: Each user approves Atlassian’s consent screen and selects the sites to authorize, so every call runs under that person’s own identity.
The same domain allowlist also decides whether users can connect an AI client directly and skip the gateway.
For detailed instructions, see the Connect Atlassian Rovo guide.
Step 3: Pin the Confluence Tool Surface
Feature provisioning under “Allow if conditions are met” exposes only allowlisted tools and fails closed for everything else, including tools Atlassian adds later. On September 28, 2026, for example, Atlassian added five Remix tools to Confluence permission groups that users had already approved.
Remove these unless a use case needs them:
- Download links: exportConfluenceContent and downloadConfluenceAttachment return a link, so the file never passes through the gateway.
- Sharing and permissions: enableConfluencePublicLink creates an anonymous share, and the permission and restriction tools change who can see content.
- copyConfluenceContent: A copy from a restricted space into an open one carries content past the policy.
- Prompts and resources: Gateway rules inspect tools/call traffic only.
On the default v2 endpoint, provisioning sees executeWrite, not enableConfluencePublicLink. Atlassian’s flat tool list for gateways, https://mcp.atlassian.com/v2/mcp?tools=all, lets provisioning allowlist Confluence tools by name. Otherwise, the engine must unwrap each call and enforce the same list.
Step 4: Resolve Targets Before Writes Reach Atlassian
The request rule fires before a call reaches Atlassian. Tools that edit, comment on, or move existing content, such as updateConfluenceContent, createConfluenceComment, and moveConfluenceContent, identify it by content ID. A response-leg check comes too late for them, because the change has already happened.
The engine has two ways to settle the target first:
- Look it up as the user: With header forwarding on, the engine receives the user’s Atlassian token. If the token’s scopes allow it, the engine can ask Confluence’s REST API which space owns the content. Enable it only for a service your team fully controls.
- Fail closed: A write whose target can’t be resolved is blocked.
For moves, check the destination as well as the source, and confirm argument names against each tool’s live inputSchema. Blocking write-tier operations while reads pass makes a space read-only for agents.
Step 5: Filter Search, Lists, and History on the Response Leg
CQL search is not scoped to a space, and returns matches from every Confluence space the user can view. The response rule removes restricted items with a modify verdict, so the agent keeps legitimate results.
For a worked example of both rules, see MCP Manager’s allowlist recipe for channels, projects, and spaces, then match its payload paths to captured Rovo responses.
Confluence adds paths the recipe doesn’t cover:
- Direct reads: Because the request can’t name the space, getConfluenceContent is usually decided here, from the space identifier in the result.
- Aggregates: searchConfluence, listConfluenceContent, and listConfluenceSpaces return lists, so rewrite counts and cursors along with items.
- Version history: diffConfluenceContentVersions and related tools return earlier revisions of a restricted page.
- Cross-product tools: Rovo search spans Jira, Confluence, and connected apps, and getTeamworkGraphObject accepts ARIs or URLs.
- Unparseable results: A covered tool’s result that can’t be parsed is blocked rather than passed unchecked.
For a blocked direct read, a not-found style error avoids confirming that the restricted page exists.
Step 6: Deploy, Register, and Attach the Engine
The custom rule engine is an ordinary web service. MCP Manager needs to reach it, which sets four requirements:
- Public HTTPS: A certificate from a public CA is required, and private addresses are rejected.
- Response time: Answers must arrive well under the 30-second timeout.
- Status codes: Every verdict, including block, returns HTTP 200.
- Idempotency: Failed attempts are retried, so the same message must produce the same result.
A static header configured on the engine authenticates each call, and MCP Manager’s static outbound IP can be allowlisted as a second layer.
Rules have no per-server or per-tool selector, so the engine routes every call on serverGuid and toolName. We recommend one endpoint over several, since each engine adds a round trip. Each verdict should carry a comment that states the decision, such as Blocked updateConfluenceContent: space 98765 is read-only for agents.
Once the endpoint is live, register and attach it to the MCP gateway:
- Add the engine under Rule Engines with the Custom provider.
- Add a rule on the gateway’s Rules tab and select the engine as the detection method.
- Set the detection hook to Both and leave the failure mode at Block.
Registering alone applies nothing. The built-in Test action runs without forwarded headers, so token-based lookups only work in live sessions.
Step 7: Test with a Pilot Team
Provision the gateway to two or three admins, then exercise each path:
- Read a restricted page by its ID and by its URL.
- Run a CQL search for a term found in restricted and open spaces.
- Edit or comment on a page in a read-only space.
- Move a page from a restricted space into an open one.
Confirm each verdict in the logs, where blocks appear as policy_enforced_abort and rewrites as policy_enforced_mutation. Read result bodies too, since an upstream failure returns a normal result with isError: true.
Want to see the rule engine working before committing to a build? Book a demo with MCP Manager and walk through a gateway rule live.
What Does It Take to Build and Maintain the Confluence Rule?
Building the Confluence rule means writing and maintaining a webhook with four verdicts, a resolver for content IDs, a parser per covered tool, and tests against captured payloads. Every new or changed Atlassian tool needs its payload checked, and the engine needs monitoring, since an outage pauses Confluence MCP under the default failure mode. InfoSec will also ask how coverage of every path is shown, which test cases, captured payloads, and logs help demonstrate.
No worries: you do not have to build this alone. A coding agent can draft the engine from the docs MCP server for agents, and the custom rule engine tutorial covers registration and testing. Product support is available on every plan if you need a hand. Review generated code before it enforces policy.
The effort buys policy that built-in detection methods cannot express:
- Custom boundaries: Spaces, operations, and read-only access can be set per team.
- Identity-aware decisions: With header forwarding, the engine receives the requesting user’s identity and, where token scopes allow, looks up content as that user.
- One codebase for several servers: The same engine can also cover Jira projects by routing on serverGuid and toolName.
- Layered controls: It runs next to Presidio or regex PII rules on the same gateway.
Where Confluence Rollouts Get Stuck, and How a Gateway Rule Helps
If you are rolling out Atlassian MCP, you will probably recognize at least one of the following scenarios. In each case, MCP Manager helps by blocking sensitive Confluence spaces at the gateway, so the rollout can continue without narrowing anyone’s permissions.
- You have adopted MCP in engineering and want to extend it: Other departments are waiting, but the server can only be switched on or off. Leadership wants an agent to have at most its user’s access, and usually less. A space rule delivers the “less” without touching anyone’s Confluence permissions.
- Your leadership team is worried about memory: An agent could read the board and strategy spaces, then reuse that content in an unrelated task. Blocking those spaces on both legs keeps the content from ever reaching the client.
- Your legal team works in Confluence: The contract clause library and the legal playbook stay fully open to the lawyers. Agents are blocked from them, so contract language never lands in a model context.
- You want agents to read runbooks but never edit them: Write-tier calls to the operations space are blocked on the request leg, while reads pass. Agents can summarize incident procedures and policies, and the source pages stay unchanged.
- Your support team pastes customer data into escalation pages: A space rule blocks the escalation space. A Presidio rule set to Replace tags personal data in the spaces that stay open.
- You roll out department by department: Engineering gets broad space access, product a narrower set, and business teams only the spaces their function needs. Each gateway doubles as a profile, so new employees connect through one URL.
Block Confluence Spaces at the Gateway, Not at the Person
Confluence permissions describe what a person may read. Atlassian’s data security policy adds an organization-wide floor for agents, and a custom rule engine on MCP Manager’s gateway adds per-team boundaries, read-only spaces, and the same enforcement across every MCP server. Attach and test both rules before anyone else connects, and Confluence stays available to every AI workflow except the spaces that must stay out.
If a few Confluence spaces are holding back your Atlassian Rovo MCP rollout, book a demo with MCP Manager and scope the rule that unblocks it.
FAQ
Can I block specific Confluence spaces from AI agents without disabling Atlassian MCP?
Yes. A request-leg rule blocks writes aimed at restricted spaces, and a response-leg rule removes restricted content from reads and search. Everything else passes, so the Atlassian Rovo MCP server stays enabled for all other spaces and Atlassian products.
Does blocking a Confluence space change anyone’s access in Confluence?
No. The rule only changes what agents receive through the MCP gateway. Space permissions, page restrictions, and the Confluence UI stay untouched, so people keep full access to their spaces. Only the AI agent acting on their behalf is kept out.
What does an agent receive when it asks for a blocked page?
The engine can return a modify verdict with a not-found style error, so the agent sees an ordinary failure instead of the page. This avoids confirming that the restricted page exists. A plain block verdict returns a generic JSON-RPC error instead.
Can a page be moved or copied out of a blocked space?
Only if the move and copy tools are exposed. Feature provisioning can hide them, and the request rule can check the destination space as well as the source, so content cannot be carried from a restricted space into an open one.
Can I block a page tree instead of a whole space?
Yes, with more work. The engine must resolve each content ID’s ancestors, as the Google Drive Folder Blocker does for folders. For Confluence, that typically means calling the REST API as the user through header forwarding, provided the token’s scopes allow it. A space-level rule avoids that lookup.
Can the same rule engine also block Jira projects?
Yes. Jira and Confluence tools come from the same Rovo MCP server, so one engine can route on the tool name and apply both policies. Each policy needs its own parser, because the payloads differ. See the guide to blocking Jira projects.
