Rovo agent permissions vs CogniRunner approvals: AI agents in Jira, as far as you let them
Gabriela Perdum
Author
13 min readOctober 4, 2026
Key takeaways
Rovo agent permissions cover three things: who can create agents (all users, up to 10 selected groups, or no users), who can edit one, and who can use it. Use access can only be limited to individual users; groups aren't supported, and ROVO-875 asking for them had 28 votes on 2 October 2026.
A Rovo agent acts as the person using it unless an admin gives it its own account. In chat it asks for confirmation before consequential actions; in an automation it can act without anyone confirming, unless you restrict it to read actions.
Atlassian's own guidance puts the hard approval in the workflow: an approval step that holds a transition, available on Premium and Enterprise. Agent events in the organization audit log need Atlassian Guard Premium.
CogniRunner 6.1 agents made in the setup wizard start in Learn and change nothing until an admin moves them up. From Ask first on, every delete, configuration or identity call waits for a Jira administrator's approval, which expires after 24 hours.
CogniRunner's limits: on Marketplace its agents write as the app, not as their own account, and its guard dog only detects and notifies. It never undoes a delete.
In November 2025 someone asked on the Atlassian Community whether Rovo agent permissions could be set by group, and that question has been viewed 1,920 times since. The short answer is still no. You can limit who creates agents by group, but who can use an agent is a list of individual people, and that's the bit admins keep tripping over.
I read Atlassian's governance pages, the two announcement posts behind them (6,736 and 6,583 views) and the open tickets on 2 October 2026, so everything below is as of that day. First I'll walk you through what Rovo lets an admin control, and what it writes down. Then I'll show you the other half of the problem, the one permissions don't solve: what happens when an agent wants to delete something. That's where Mihai's work on CogniRunner comes in, and I'll be honest about what it doesn't do as well.
Rovo agent permissions and governance: what an admin can set today
There are three separate switches, and they're easy to blur together.
Creating agents is open to everyone by default. Atlassian's Rovo agent permissions and governance page lists the three options a Studio admin has: "All users", "Selected groups", which "limits agent creation to up to 10 user groups", and "No users", which leaves creation to you and the other organization admins.
One thing to watch if you go for groups. There's an open bug, ROVO-1228: a Studio app admin who isn't also an org admin can't add groups to that create permission. The group list never loads, and a group you type in shows Saved but is gone after a refresh. It was filed on 11 September and sits in Atlassian's short-term backlog. The workaround is to ask an organization admin to add the groups. If your groups won't stick, it's not you.
Editing an agent is per agent. The person who builds it can add Editors, who can edit, and Managers, who can also add other editors and delete the agent. Heads up, the docs and the product announcement don't quite agree here. The governance page still says you give each person "either editor or manager", while the February 2026 announcement says the roles are now "managers, editors, users". If your screen shows three roles, that's why.
Using an agent is the one people ask about. It's also the loosest. "When you create an agent, it becomes available for everyone to see and use by default." You can restrict it, and then "agents with restricted access are only visible by the people you add". Everyone else won't see it in the directory or as an option for automation.
Who can use a Rovo agent: individual users, not groups
Here's the sentence that answers the Community thread, straight from the governance page: "Restricting agent access to specific groups or teams is currently not supported. You will need to add users individually."
Jensen Fleming from Atlassian said the same under the user permissions announcement in February: "currently only users". Groups "added a ton of dev complexity", so they shipped without them. The request to add groups is ROVO-875. It's at Gathering Interest with 28 votes, so if you need it, go vote.
Groups do work for one thing, and that's creation. The August 2025 governance announcement is where that arrived.
The agent acts as you, unless it has its own account
Permissions on the agent decide who gets to talk to it. What the agent can then reach is a different question, and Atlassian answers it with identity.
By default an agent uses the account of whoever is using it. The governance page puts it plainly: "If the user can't comment, the agent can't comment." The other option, set up in Configure a Rovo agent's identity, is the Agent's account. Then organization admins decide which apps it can reach, space admins and end users decide which spaces and pages, and its changes "appear under the agent's name making it easier to track in audit logs".
That last part matters more than it sounds. On a user's account, an automated agent's changes are logged as the person who set up the automation. And if an admin never sets up an Agent's account, that's what you get.
You can also narrow an agent through its instructions and the tools you give it. Just don't lean on the instructions. Atlassian's best practices page says it twice: "Guardrail instructions are suggestions. There is no guarantee that the agent will follow them."
What Rovo logs when an agent acts
People sometimes assume there's no trail at all. There is, in three places, and which ones you get depends on your plan.
The first is the work item itself. Atlassian's guardrails guide says agent actions land "in the work item history alongside human activity", under the user's name or the agent's, depending on the identity above.
The second is the organization audit log. Atlassian's list of audit log activities includes "Created Rovo agent", "Updated Rovo agent", "Deleted Rovo agent" and "Started chat with Rovo agent", plus "Invoked tool" for Rovo MCP. Atlassian files all four under Rovo user actions. When Rovo activities first arrived in the audit log in April 2025, the note said user actions are for Guard Premium. Admin actions, like connectors and bookmarks, are for Guard Standard and up.
The third is newer. Atlassian's August 2026 update announced it: if your organization has Atlassian Guard Premium, "every time someone invokes an agent, an "Invoked Rovo agent" event is captured" under Insights, Audit Log. It records who invoked it, from where (Rovo Chat, Slack, Teams), what tools it used and what permissions it ran under. That's from Atlassian's bi-monthly Rovo agents update.
So the honest summary? The work item history is always there. The agent events in the audit log, including the per-invocation one, are Guard Premium.
Human in the loop for AI agents in Jira: who approves the delete
So who says yes before an agent changes something?
In chat, the person using it. Atlassian's page on agent tools says the agent "will respond asking for confirmation before executing consequential tools that may mutate data across systems". The best practices page goes further: in interactive use "there's always a human in the loop to review and approve an action before the agent does anything". The same tools page also caps bulk actions in Jira at 20 work items at a time.
In an automation, nobody. "The agent acts autonomously and will perform actions without a user confirming every task." You can limit the Use agent step to read actions only, and admins can stop agents acting in automations altogether.
You'll find one Atlassian page that says the opposite, so let me save you the confusion. The tools page still says an agent in an automation "cannot use its own tools" and can only return text. The automation page says an agent there can "take actions directly". And Atlassian's August 2026 update, the newest of them, says agents in automation rules "can execute these actions directly" now. No stopping to ask. Plan for the agent acting.
Agents on work items are their own case. You can assign an agent to a work item, or attach one to a workflow transition (that needs a space admin with Edit workflows). On a transition, "the agent is triggered when any team member moves a work item to the allocated status." And Atlassian's own guide is clear that "Assigning the agent runs it. It does not yet put a human in the loop, that is the checkpoint you add next."
For anything hard to undo, that guide to human-in-the-loop patterns for AI agents in Jira points you at the workflow: "approval is a workflow approval step that holds a transition until a named person signs off". It also says "Native approvals are available on Premium and Enterprise plans."
That's a good pattern, and I'd use it. But notice what it gates. It holds a transition. It doesn't hold a single API call that an agent decided to make halfway through its work. And the person confirming in chat is whoever is talking to the agent. They can only confirm what their own permissions allow, but they're the requester, not a named approver.
That's the gap CogniRunner's agents were built around.
Learn, Shadow, Ask first, Live: a CogniRunner agent starts with no write access
CogniRunner is our Jira app for AI workflow rules, and since Marketplace version 5.0.0 on 30 September 2026 it also has agents, which it calls virtual administrators. They work a queue on a schedule: a JQL filter in a service desk, say. The version on Marketplace on 4 October is 6.1.0, from 3 October. It fixed rules, tests and AI providers and changed nothing this article says about agents. The screenshots below were taken on 6.0.0, on 2 October.
Every agent made in the setup wizard starts in Learn, whoever makes it. In Learn it reads, keeps notes and proposes facts. It doesn't draft replies, ask anyone, file anything or change anything in Jira or Confluence. New agents also come with working hours on, invited work only, a second check on customer replies and a daily token cap.
The Agents tab says the rule in its own words: an agent starts in Learn and changes nothing until you promote it. This one is a demo persona in Shadow with 3 drafts staged. CogniRunner 6.0.0 production install on our demo site, captured 2 October 2026.
Only a CogniRunner admin can move it up. If someone who isn't an admin tries to choose a phase, they get Learn anyway. An admin can also schedule the move for after a set number of runs (the "Set an automatic move" link in the next screenshot), but the agent never picks its own phase.
Shadow adds drafts. The agent writes the replies and records the changes it would make, and a person approves or rejects each one. Ask first lets it ask people questions, file change proposals and run a request someone approved. Live lets it post answers and make changes within its powers, its working hours and its caps.
Look at two things: the 3 drafts waiting under Needs you, and the Brakes panel on the right with the 250,000 tokens a day cap. CogniRunner 6.0.0 on our demo site, 2 October 2026.
Those brakes are worth a second look. The demo agent may send 6 messages an hour and 30 a day, and make at most 200 changes in one run. It also only changes the issue it's working on. If it decides another issue needs a change, that's recorded for a person to make. And a reply that fails its second check three times stops and waits for a person.
There's a check on every run too. The agent acts for a named person, and before each run CogniRunner asks Jira whether that person's account is still active and can still browse every project it reads and writes. If it's allowed Atlassian operations (more on those below), that person also needs Jira's Administer permission. If any answer is no, or Jira can't answer, the agent runs in Learn. A lasting no stays until an admin reverses it.
Delete, configuration and identity calls wait for a Jira administrator
This is the part I'd want to know about if I were deciding whether to let an agent near my site. So let's be precise.
Even in Live, a CogniRunner agent never deletes anything, changes configuration or touches users and groups straight from a model turn. In Ask first and Live those calls wait under "Waiting for your approval", showing exactly what would be sent. In Learn and Shadow they don't run at all.
A few details make that approval mean something:
The approver has to hold Jira's Administer permission, checked live at the moment they click. If Jira can't answer, the approval is refused.
The approval is tied to the exact request. If what's waiting isn't what you approved, nothing runs, and it only runs while the thing it changes still looks the way it did when the request was filed.
A request expires after 24 hours. One agent can have at most 20 waiting.
A token can only approve as the Jira administrator who created it, and a token with no person behind it can't approve at all. A model can never approve its own request.
No agent can change the org-admins, site-admins or cognirunner-guardians groups, even with approval.
The approval queue and the allowlist, both empty on purpose: this demo agent has no Atlassian operations allowed, so nothing can wait. Note the 0 of 40 limit. CogniRunner 6.0.0 on our demo site, 2 October 2026.
To be clear about what you're looking at, that queue is empty. Our demo agent isn't allowed any operations, so I haven't got a real waiting request to show you here.
The middle card, Try a request, is the one I'd use first. It shows what a call would pass without sending it. On this agent it has nothing to try, because nothing's allowed yet.
AI agent guardrails: allowed operations, a guard dog and a token cap
Atlassian's guide to AI agent guardrails and safety in Jira has a line I really like: "A guardrail only works if the system enforces it, not the agent." CogniRunner has two that work that way, the allowlist and the token cap, plus a guard dog that watches for what gets past them.
The allowlist comes first. Beyond its ordinary actions, an agent can call only the Atlassian REST operations on its own list, up to 40, picked from Jira, Jira Service Management, Assets and Confluence. Only a Jira administrator can add one. The catalogue is built from Atlassian's published API specs, and the model never names a host, a path or a method itself.
The token cap is about money. Atlassian's guardrails guide lists "Runaway cost" as a risk and says spending "needs limits like any other resource". It's not abstract on the Rovo side either: Atlassian's Jira docs say Rovo credit allowances apply from 3 December 2026. New CogniRunner agents get a cap of 250,000 AI tokens a day. When it's spent, the work waits for the next day (UTC) and the agent's history says why. One turn that's already running can go a little over, and the next one is refused. The budget is also checked inside each turn, and a Learn turn uses at most three rounds.
Then there's the guard dog. It watches issue deletes on the whole site, by anyone, people included. It also notices when automation answers someone's bulk change. When one account deletes 10 or more issues in 10 minutes, or 3 in a project you've marked protected, it notices. Both numbers are adjustable on its card, which only organisation admins see. Once you've set an inbox project, it files an incident issue there and notifies the organisation admins and the leads of the affected projects.
Set up the controls on your own site
If you're going to try either, here's the order I'd do it in.
For Rovo:
Decide who can create agents in Studio settings: all users, up to 10 groups, or nobody but org admins.
Restrict any sensitive agent to the named people who need it. Remember it's one user at a time.
Give agents that run in automations an Agent's account, so their changes show under the agent's name.
In each automation's Use agent step, choose read actions only wherever the agent just needs to read.
Add a workflow approval step on the transitions where the impact lands, if you're on Premium or Enterprise.
If you have Guard Premium, check the "Invoked Rovo agent" events after the first week.
For CogniRunner:
Create the agent with "New virtual administrator" on the Agents tab. It lands in Learn.
Leave it in Learn for a while and read what it writes down before you trust it with anything.
Move it to Shadow and approve or reject its drafts. You'll learn more from the ones you reject.
Only then have a Jira administrator allow Atlassian operations, the fewest it needs, and run each one through Try a request.
Ask an organisation admin to set the guard dog's inbox project and mark your protected projects.
Check the token cap under Brakes, and move to Ask first or Live only when the drafts stop surprising you.
What CogniRunner doesn't do
A few honest limits, because they change the decision.
On Marketplace, a CogniRunner agent doesn't get its own Jira account. It writes as the app, so Jira shows the app's name on its changes, and only within what the person it acts for may do. That's the opposite of Rovo's Agent's account, which really is a separate identity.
On a Marketplace install the agent writes as the app, and the guard dog can raise the alarm about a bulk change but can't switch the automation rule off. All three credentials read not set. CogniRunner 6.0.0 on our demo site, 2 October 2026.
The guard dog detects and tells people. That's all. It never restores anything and never blocks a delete, and on Marketplace it can't switch off the automation rule behind a bulk change either. It also only watches Jira issues, not Confluence: issue deletes, and bulk changes that automation answers.
The admin approval covers deletes, configuration and identity calls made through the allowed operations. It isn't a gate on every write. In Live, ordinary changes run within the agent's powers and caps, and replies go through the staged drafts you approve in Shadow and Ask first.
And the AI. On Standard, the agents run on your own AI provider, any CogniRunner supports except goose, which can't make the tool calls an agent needs (there's a tutorial on connecting an OpenAI key). On Atlassian's zero-key Forge LLM, they need the Coder edition and one of its frontier models, the same edition behind the CogniRunner Coder.
Rovo or CogniRunner: pick by who should say yes
They're not really competitors, and you can run both.
In chat, a Rovo agent acts as the person using it, and they confirm consequential actions. On a work item someone assigned it, it acts as them too, and Atlassian's own guide says the approval checkpoint is one you add. You control who can use it, one user at a time for now.
If the agent works a queue on its own, Rovo can do that too, in an automation and ideally on an Agent's account, with a workflow approval step on the transition. CogniRunner's difference is that a Jira administrator signs off on each destructive call before it's sent, and the agent climbs phases only when an admin decides. The CogniRunner page has two short videos of the setup and the phases if you'd like to see it move.
Either way, the workflow approval step Atlassian recommends is still worth adding on the transitions where the impact lands. A second gate that doesn't depend on the agent is the whole point of a guardrail :)
