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; } } }

Discussing governance for Rovo agents within Automation flows

Andrew Zimmerman_rvmutq

I’m curious how other admins are governing the use of Rovo Agents within Jira Cloud Automation flows (rules), especially in enterprise environments with sensitive or segmented data.

One thing that concerns me is how the Rovo connection currently works inside automation flows.

As I understand it, the automation creator/editor connects Rovo using their own identity. The Rovo agent then executes using the permissions of that connected user during rule runs. The automation can subsequently output that agent response into comments, fields, emails, etc.

This seems like it could create indirect permission bypass scenarios depending on how the automation is designed.

For example,

A flow uses a Rovo Agent action with a prompt like:
“Find similar tickets to this work item”
The connected user has broad visibility across Jira and/or Confluence spaces
The automation then posts the findings into a comment on the work item

Potential problem:
The users viewing that work item/comment may not normally have permission to view the referenced content themselves.

If those same users asked Rovo directly, Rovo would correctly respect their permissions. But through automation, the info retrieval and response is effectively happening through a pre-authenticated privileged identity. The automation output can then expose information downstream to less privileged users.

That feels like a data leakage risk, which has me wondering:

How is your organization handling this?
Are people using dedicated low-privilege service accounts for Rovo-connected automation?
Are there governance patterns emerging around AI-enabled automation flows specifically?
Are admins restricting who can create/edit automation flows that contain Rovo Agent components, or treating these as privileged integrations?
Are there safeguards I’m missing that prevent this scenario?

I’m especially interested in hearing from admins operating at enterprise scale or in regulated industries. Thanks for your thoughts on any of the above questions!

Comments

Wallace Chen

Great question. I came across a couple of similar discussions recently. Here's how I think about it visually:

SCENARIO A — Rovo in Chat  ✅ Permissions respected
─────────────────────────────────────────────────────
User A ──asks──▶ Rovo Agent ──reads as User A──▶ Jira/Confluence
(limited)        (executes                       (only what User A
AS User A)                      can see)
│
▼
Response scoped to User A

SCENARIO B — Rovo in Automation (default today)  ⚠️ Escalation risk
─────────────────────────────────────────────────────────────────────
Trigger ──▶ Automation Rule ──▶ Rovo Agent
event                            (executes AS RULE CREATOR)
│
▼
Jira/Confluence
(ALL data the creator can see)
│
▼
Posted to comment / field
│
▼
Seen by Users B, C, D
(who may not have direct access
to the referenced content)

SCENARIO C — Mitigated (scoped agent identity)  ✅
─────────────────────────────────────────────────────────────────
Trigger ──▶ Automation Rule ──▶ Rovo Agent
event                            (executes AS SCOPED AGENT ACCOUNT)
│
▼
Limited data sources
(only what the agent account
was explicitly granted)
│
▼
Output audience matches data scope

On Scenario C about the scoped agent account, not sure if you have seen this announced at Team '26 (May 2026): Agent Accounts give Rovo agents their own dedicated, scoped identity so they don't inherit a human user's broad permissions.

The concept: when you enable Agent Account mode for a Rovo agent in Studio, the agent gets its own identity that Org Admins manage separately — adding it to groups and granting only the product / project / space access the agent actually needs.

I think this can already start exploring through the Early Access Program https://developer.atlassian.com/platform/marketplace/early-access-program/

A tiered governance model I've seen working well:

Knowledge / read-only → broader use OK
Triage / metadata updates → scoped projects, no delete permissions
Content drafting → human-in-the-loop review before anything is surfaced
Fully autonomous write actions → explicit approval, logging, and a kill-switch

A few operational practices worth to mention:

Use naming conventions or labels on Rovo-enabled rules so admins can spot them during audits
Limit rule edit permissions on those projects to a smaller admin group
Sandbox-test any rule that posts agent output into broadly visible fields or comments
Run periodic audits of agent-generated content to catch inadvertent exposure

Curious to hear more from others on real use cases and practice — especially anyone in regulated industries who's worked through this in production.

Prashanth

Dear All,

Greetings,

Interesting discussion. One thing I keep wondering is whether scoped Agent Accounts, while safer, may eventually become operationally heavy for enterprise admins at scale.

Now admins potentially manage:

1) User permissions

2) Group permissions

3) Project/space permissions

4) AND separate Rovo Agent identities + access scopes

That could become quite clumsy in large organizations with hundreds of automations and agents.

Part of me wonders whether the longer-term model should instead be more “viewer-context aware” rather than “agent identity aware.”

Meaning:

the automation or agent may retrieve/process centrally, but the surfaced output should still dynamically respect the permissions of the person viewing it.

The simplest analogy I can think of:

If I stand in front of a mirror, it should show my face.
If another person stands in front of the same mirror, it should show their face - not mine, and not both mixed together.

In the same way, perhaps Rovo outputs should ideally render relative to the viewer’s permissions, not purely based on the identity that executed the automation.

Otherwise we may end up solving one governance problem by introducing another layer of permission administration complexity around AI agents themselves.

Curious whether others see the same tradeoff, especially at enterprise scale.

Having said the above, I reckon it gets even difficult in regulated industries to maintain so many permissions coz all companies of regulated indsutries have large user base.

Thoughts appreciated.

Wallace Chen

Thanks @Prashanth — good point on the operational overhead at scale. But I'd push back on the "viewer-context aware" direction.

If I understand correctly, the mirror model you described would mean the same comment/field/page displays different content depending on who's viewing it, based on each viewer's permissions to the upstream sources.

The challenge is: in Jira/Confluence, content is static once written. A comment is the same bytes regardless of who reads it. Permission checks happen at one layer only — "Can this user see this artifact?" — yes or no, full content or blocked entirely. This has been true long before Rovo:

Paste a JQL result into a description → anyone with issue access sees it, even if they can't run the JQL themselves
Summarize a restricted Confluence page in a comment → anyone with comment access sees the summary
Same applies to any automation output

The mirror model would require tracking upstream provenance of every sentence and dynamically redacting/rewriting per viewer at read time. That's a fundamentally different content model, not an extension of the current one.

It's also worth noting this follows the standard IAM model (not Atlassian-specific):

Authentication — Who are you? (SSO/MFA via standards like SAML/OIDC and identity providers like Okta)
Authorization — What can you access? (Permission schemes, space permissions, issue security)
Accounting/Audit — What did you do? (Logging for compliance)

To reduce admin overhead on #2 and #3 at scale, we have introduced Atlassian Guard to centralize identity, SCIM provisioning, access policies, and audit logging. Agent Accounts extend this same model — giving agents their own scoped identity, following the same service-account pattern enterprises already use for CI/CD pipelines and integrations.

Prashanth

@Wallace Chen Brilliant, this is what I wanted to listen from you, exactly the same, what you are doing already and how you are doing it, great, Learnt something new today. Thanks mate.

Only wish is, if Rovo output/comments can be dynamic as per user permissions by refreshing a page, would be great. The dynamism will be Dynamic ROVO.

On the other hand can you comment your opinion on this thread of mine please, just want to pick your brains.

https://community.atlassian.com/forums/Jira-questions/Enterprise-wide-operational-platform-on-Jira-Cloud-Rovo/qaq-p/3239383

Rebekka Heilmann (viadee)

Hey @Andrew Zimmerman

a bit late to the discussion but here is how we handle it:

A section in the usage policy that only allows the Agent owner to use their own Agent in their own Automation. Nobody else is allowed to use it.
Jira Automation and Rovo Agent creation each require separate certification and approvals before permissions are granted
A separate KB article on Rovo in Automations explaining exactly that problem and with best practices, like limiting edit permission

What already works is that updating someone elses rule will require a re-connect of the Rovo Agent, forcing you to use your own user in the connection.

Atlassian is aware of the issue and already working on a solution as part of some EAPs. While you cannot use actual Service Accounts within Automations, Agents will get their own Agent Account with their own Permissions which can then be used as connection in Automations.

Andrew Zimmerman_rvmutq

Thanks @Rebekka Heilmann _viadee_ for sharing your insights and how you handle this. Much appreciated!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

automation

jira-automation

rovo