nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rovo Agents: Separate "Use" and "View Instructions" permissions

Praveen T K_j21dti

Problem:
Currently, when a Rovo agent is set to "Open to all users," every user can both use the agent and view its full instructions (prompt/configuration). There is no way to allow all users to use an agent while restricting visibility of its instructions.

This poses a security risk when agent instructions contain sensitive information such as:

Internal workflow logic and approval criteria

Custom field IDs and label-based routing rules

Threshold values and conditional logic

Integration details and automation patterns

Use Case:
Our team has built the Approval agent, which contains sensitive vulnerability assessment thresholds, custom Jira field references, and approval workflow logic in its instructions. We need all users to interact with the agent, but exposing these implementation details to everyone creates a security concern.

Expected Behavior:
Provide a granular permission model for Rovo agents that separates:

Use permission — ability to interact with/invoke the agent (open to all)

View/Edit instructions permission — ability to see the agent's prompt, configuration, and knowledge sources (restricted to owners/editors only)
Hide instructions from users completely
Set instruction visibility permissions
Create truly private agent configurations

Accepted answers

Arkadiusz Wroblewski

Hello Praveen,

Atlassian Rovo currently doesn't natively separate "use agent" permissions from "view instructions," meaning anyone who can invoke an agent can also see its prompt configuration. To safeguard sensitive logic, thresholds, or secrets, it's best to keep your prompts generic and offload the actual decision-making to a hidden backend process like Jira Automation or a Forge app.🫣

You could also split your audience by using a simplified public agent for general users and a restricted internal one for reviewers. This definitely warrants raising an Atlassian feature request for distinct "Use" versus "View Configuration" permissions.

There are actually many of this Feature Requests.

What you need to understand is that governance around AI is still actively evolving.

[ROVO-877] Org Admins should have full Owner/Editor access to all Rovo Agents in Studio - Create and track feature requests for Atlassian products.

[ROVO-722] Feature Request: Delegated Instruction Editing with Diff Review - Create and track feature requests for Atlassian products.

[ROVO-142] Define "who" can "use" a specific Rovo Agent - Create and track feature requests for Atlassian products.

Best,

Arkadiusz🤠

All comments

Arkadiusz Wroblewski

Hello Praveen,

There are actually many of this Feature Requests.

What you need to understand is that governance around AI is still actively evolving.

[ROVO-877] Org Admins should have full Owner/Editor access to all Rovo Agents in Studio - Create and track feature requests for Atlassian products.

[ROVO-722] Feature Request: Delegated Instruction Editing with Diff Review - Create and track feature requests for Atlassian products.

[ROVO-142] Define "who" can "use" a specific Rovo Agent - Create and track feature requests for Atlassian products.

Best,

Arkadiusz🤠

Praveen T K_j21dti

Hi Arkadiusz,

Thanks for your prompt response .

The issues I faced currently is since users have access to view instructions, they are duplicating the agent and modify some part of it and execute it.
Here we are not able to do governance like which agent did these changes.

And one more issue is users are duplicating and creating the agent with same name exactly as copied one. So difficult to distinguish which is original one.

As you suggested will try to implement by hiding actual decision-making to a backend process like Jira Automation or a Forge app.

I feel for some domain at least ROVO agents name should be unique

Thanks,

Praveen

Arkadiusz Wroblewski

@Praveen T K

One important thing to keep in mind is that Atlassian is doing a lot around Rovo right now.

That also means that features, governance, and administration options are still actively evolving. It is worth checking the settings and documentation regularly, because this area can change quickly. You may see new options appear from one day to the next.😉

Best,

Arkadiusz🤠

Praveen T K_j21dti

Sure @Arkadiusz Wroblewski ,

Thanks for the details.

Regards,

Praveen

Rebekka Heilmann (viadee)

Hi @Praveen T K

with the Issue you described above.. User copying and not giving Agents proper names.. It sounds like there is a general Governance issue. If they do not create/use them responsibly, maybe they shouldn't have Agent Creation permissions at all?

The least I would recommend is having an Agent policy and best practices that include things like naming and copying existing Agents.

But I totally agree that Rovo, specifically Agents, lack lots of governance controls on a technical level. Enforcing said policy is not really scalable as of now.