Dev agents are only as safe as the permissions behind them.
Rovo Dev Agents pick up work in Jira and produce changes against your repositories, inside the systems your developers already use rather than in a separate tool somebody has to adopt. Our work is permission scope, ownership, change control, and usage governance before agents run against production.
Rovo Dev Agents act inside your Atlassian estate. We scope what they can reach, record who owns them, and put the change control underneath before they run against anything that matters.
What it is
Rovo Dev Agents pick up work in Jira and produce changes against your repositories, inside the systems your developers already use rather than in a separate tool somebody has to adopt.
They are for engineering organizations whose work is already in Jira and whose code is already in Bitbucket, and who want routine changes handled without creating a review queue nobody has capacity for.
What it does
It acts with an identity
It authenticates and holds permissions like any other account, which means it can be scoped, reviewed, and revoked the same way.
It works where the work already is
It operates on items in Jira and changes in your repositories, inside the estate you already administer rather than beside it.
It inherits your branch and approval model
Whatever protections exist on a repository apply to the agent. Where they are thin, the agent is what makes that visible.
It consumes metered capacity
Usage is measured, which makes cost a governance question during the year rather than a surprise at renewal.
Where it fits
L4, agents and automation. This sits at the top of the Stack, which means every layer beneath it decides what the agent can actually do. An agent inherits the repository permissions, the branch protections, and the approval model already in place. Where those were never designed, the agent surfaces that on its first run rather than at the point somebody asks what changed.
What we do with it
Readiness before rollout
We establish which identities exist, what each can reach, and which of them are already unowned, before an agent is added to that population.
Permission and branch model design
A repository and approval model an auditor can follow, designed once rather than negotiated per team.
Change control underneath the automation
Approved needs a definition, an owner, and an evidence trail before anything automated is allowed to act on it.
Custom agents and extensions
Where the native capability stops, we build on Forge, inside the same permission model.
Usage and cost governance
Ownership, review dates, and consumption tracked as an operation rather than discovered at renewal.
Where it earns its place
A manufacturer piloting with one team
A quality team with documented procedures and a few agents is a better first rollout than a broad program, because success there creates the internal pattern for everything after.
An insurer standing up new squads
Squads launching on standardized project templates are the moment to decide what an agent may touch, before local habits form.
An engineering group with inherited branch rules
Where protections were set per repository over a decade, an agent rollout is the forcing function that finally makes them consistent.
Proof
Monthly active users on Rovo, which makes agent capability table stakes and governance the thing that differentiates.
Atlassian Q2 FY26 shareholder letter.
Of security leaders are confident their identity management can handle agent identities.
Cloud Security Alliance and Strata, 2026.
World Class Software Development Finalist, 2024-2025
Atlassian Partner Awards, 2024-2025
Questions we get
Should the identity work come first?
Can it act on production?
How do we stop one?
What does it cost to run?
Licensing
Rovo capacity is metered against your Atlassian entitlement, so the practical question at renewal is what the agents actually consumed against what was provisioned. That reconciliation sits with the rest of the estate in licensing and renewals.