Restrict Atlassian Plugin to write to specific spaces

Question

Hey,

We’re currently looking for a way to restrict the Atlassian Rovo Plugin (MCP) from writing to tickets in our Customer Support space while still allowing it to read from that space.

At the moment, we haven’t been able to find an option to restrict write access for the plugin on a per-space basis. The only option we’ve found is to exclude a space entirely.

Is there a way to configure read-only access for specific spaces?

Any advice would be greatly appreciated. Thanks!

Sami Shaik · Answer

Hi @Finn Witzenhausen ,

@Mia Tamm _Simpleasyty_  is right that "read everywhere, write only here" is the governance boundary everyone will need. The good news is that it already exists today, just not as an agent-level setting, and the agent-level version is on its way. Here is the model as Atlassian documents it, so you can build the boundary now.

How the boundary works today: the agent is the user. Per Atlassian's governance doc, when someone interacts with a Rovo agent, the agent acts on that person's behalf and can only read or change what that person can read or change: if the user cannot comment, the agent cannot comment; if the user cannot delete a page, neither can the agent (https://support.atlassian.com/rovo/docs/rovo-agent-permissions-and-governance/). So the write boundary is the Confluence space permission scheme of the invoking user, and a user who is a viewer in Space A and an editor in Space B gets an agent that reads both and writes only to B. Nothing bypasses that.

Two agent-level controls stack on top. In Agent Studio you can remove write tools from the agent entirely (an agent with no create-or-edit tool cannot write anywhere) and you can state limits in its instructions. The doc is explicit that instructions are a limit, not a guarantee, so treat tools as the enforcement and instructions as the guidance.

The part to plan for: automation rules. When an agent runs inside a Jira or Confluence automation rule, it executes with the permissions of the account that connected Rovo to the rule, which is usually an admin. That is the one place where "the agent is the user" turns into "the agent is the admin," and it is where the boundary you want has to be designed on purpose (a dedicated low-privilege account for rule connections is the practical answer). Good discussion of the trap here: https://community.atlassian.com/forums/Atlassian-AI-Rovo-discussions/Discussing-governance-for-Rovo-agents-within-Automation-flows/td-p/3239485

What is coming: Agent Accounts. Atlassian announced at Team '26 that agents can get their own scoped identity, managed by org admins like a user account, so you grant an agent only the space and product access it needs instead of inheriting a person's permissions. That is exactly the feature you are hoping for, and it is currently in early access rather than general availability, so treat the date as Atlassian's and not mine. Until it reaches your site, the three layers above give you the same result with a bit more discipline.

Mia Tamm _Simpleasyty_ · Answer

Exactly @Finn Witzenhausen. I think the “soft boundaries” part is especially interesting.

Not every action needs a simple allow/deny rule. In some cases, teams may want AI to read everything but only modify content that meets certain conditions — for example based on space, content type, ownership or classification.

That kind of contextual permission model would make agents much easier to trust in enterprise environments.

Finn Witzenhausen · Answer

Yes, I already guessed so. Is there a way to submit this as a Feature-Request to the Atlassian team?