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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.