Assessing agent readiness before your first Rovo rollout

Rovo is the easiest agent rollout most Atlassian customers will ever do, which is exactly the problem. Turning it on is a switch. Deciding what it should be allowed to see, who owns it, and how you would answer an auditor about it is a project.

This is the checklist we run before a first rollout. It is deliberately ordered so that the items that are hardest to retrofit come first.

1. Can you list the identities that already exist?

Before adding a new class of identity, you need the current one written down. That means humans, service accounts, integration users, tokens, and anything else that authenticates.

Ninety-two percent of security leaders say they lack full visibility into the machine identities already running in their environment (2026 CISO AI Risk Report, 235 large-enterprise leaders). If that describes you, the agent rollout is not the first problem to solve. The inventory is.

The test is simple. Ask for a list of every non-human identity with access to Jira and Confluence, with an owner against each one. If that list takes more than a day to produce, it does not exist.

2. Does the content the agent will read have a permission model you trust?

An agent that reads Confluence inherits the permission model of Confluence. If a space is open because opening it was easier than modeling it, the agent will surface its contents to anyone who asks a question that touches it.

This is the single most common surprise in a first rollout. The permissions were technically correct and practically wrong, and nobody noticed because no human had ever read across the whole corpus at once. An agent does exactly that, on the first day.

Run the check before rollout, not after: pick the three most sensitive spaces you have and confirm that their restrictions are deliberate rather than inherited.

3. Does the agent have its own identity?

An agent acting as a person is an accountability problem. The work it does enters the same queues as human work, the audit trail attributes it to a human, and there is no way to revoke the agent without revoking the person.

Only 23 percent of organizations report having an identity strategy that covers agents at all (Cloud Security Alliance and Strata, 2026). The fix is not complicated, it is just rarely done: provision the agent as its own identity, through the same directory and the same lifecycle as everything else.

4. Is the scope smaller than the person who set it up?

The default failure is that an agent gets the permissions of whoever enabled it, because that is the path of least resistance. An administrator enables Rovo, and the agent can reach everything an administrator can reach.

Eighty-one percent of security leaders worry about excessive access held by non-human identities (Okta Global CISO Insights, 2026). Scope the agent to what its job requires: read broadly if it must, but write narrowly, and to named spaces or projects rather than to everything.

5. Does someone own it by name?

Not a team, a person. The owner is who gets asked when the agent does something unexpected, who reviews its scope at the next access review, and who decides when it is retired.

An agent without a named owner is the same object as a service account without a named owner, and it fails the same way: it survives every reorganization because nobody has standing to remove it.

6. Is there a budget, and does someone watch it?

Agent usage has a cost curve that does not look like seat licensing. It moves with how much people use it, which is not knowable in advance and is very knowable in arrears.

Set a ceiling before rollout and decide who sees the number monthly. This is unglamorous and it is the item most likely to turn a successful pilot into an uncomfortable conversation in quarter three.

The budget question also settles a design question people otherwise argue about. If usage is metered and visible, the team scoping the agent has a reason to make it narrow, because narrow is cheaper. If usage is invisible, every scope argument is abstract and the broad option wins by default.

7. Can you tell agent work from human work afterward?

If an agent drafts a summary, updates a field, or transitions an issue, the record should say so. Otherwise the first audit that asks who made a change gets an answer that is technically true and practically useless.

This is worth testing explicitly. Have the agent do something, then look at the issue history and ask whether a person reading it in six months would know a machine did it.

8. Does change control cover it?

Most change processes were written for humans deploying software and for administrators editing configuration. An agent that can transition issues or edit pages is making changes, and the process usually has nothing to say about it.

Only 16 percent of security leaders say they govern access to their core platforms effectively (2026 CISO AI Risk Report, 235 large-enterprise leaders). Extending change control to agents before rollout is much easier than doing it after the first incident.

9. Do you know what it connects to beyond Atlassian?

The connective tissue is standard now. The Model Context Protocol passed 97 million monthly SDK downloads and was donated to the Linux Foundation in December 2025 (Anthropic and the Linux Foundation, December 2025), which means agents reaching across tools is the normal case rather than the exotic one.

Okta's Cross App Access launched with more than 25 early adopters at announcement, including Anthropic, Zoom, and Slack (Okta newsroom, Cross App Access partner announcement, 2026). The direction of travel is that these connections become governed identity relationships. Decide now whether yours will be.

10. Have you decided what happens when it is wrong?

Agents produce plausible output, which is a different risk profile from software that produces correct or broken output. The question is not whether it will be wrong. It is who notices, how, and what they do.

For a first rollout the answer can be simple: a human reviews anything the agent writes, and there is a named route for reporting a bad result. What matters is that the answer exists before the rollout rather than being invented during the first incident.

It also helps to decide in advance what you would do if the agent were consistently wrong about one domain rather than occasionally wrong about everything. The first is a scoping failure and the fix is to narrow what it reads. The second is a fit failure and the fix is to stop using it for that job. Teams that have not separated those two cases tend to respond to any bad result by widening access, on the theory that the agent needed more context, which is precisely the wrong direction.

Where this usually lands

Most organizations pass items one, two, and five with some work, and fail three, four, and seven outright. That is a normal result and it is fixable in weeks rather than quarters, because the underlying model is the same identity model the rest of the estate already needs.

None of this argues for delaying the rollout. It argues for doing the identity work in the same quarter rather than the quarter after the first audit finding. A rollout that ships with a scoped identity, a named owner, and an attributable record is not slower than one that ships without them. It is the same rollout with three decisions made on purpose instead of by default.

Only 18 percent of security leaders are confident their identity management can handle agent identities (Cloud Security Alliance and Strata, 2026). The organizations that will be in the confident group are the ones treating the first rollout as an identity project that happens to involve an agent, rather than an agent project that happens to involve identity.