Agent readiness is whether your Atlassian estate is safe and useful for agents before you switch them on. You check five things: identities, permissions, content, who controls the agents, and how you will measure them and turn them off.
Most readiness checklists focus on the agent: which use case, which prompt, which model. Those questions matter, but they are the easy part. The hard part is what the agent lands on. A Rovo agent either works with the permissions of the person using it or runs under its own agent account. Either way, it reads the content your teams have written over the years, and acts through the same Jira and Confluence your people use. If those layers are messy, the agent is messy too, only faster.
This guide covers the five checks Atlas Bench runs in an agent readiness assessment, what "ready" looks like for each, and how to check it yourself. For a shorter version focused on a first Rovo pilot, see our guide on assessing agent readiness before your first Rovo rollout.
Check 1: Every identity is explained
What ready looks like: every account with access to Jira or Confluence belongs to a real person or a system with a named owner. Leavers lose access the same day. Nobody has two accounts.
Why it matters for agents: an agent that uses a person's account acts as that person. An account that should have been removed is an account that can still use agents. A duplicate account is two sets of permissions for one person, and usually one of them is wrong.
How to check it:
- Export users from Atlassian Administration. The export includes last active dates.
- Join it with your identity provider and HR records on email. Every row that does not match needs an explanation.
- Test deprovisioning with a real leaver. With Atlassian Guard and SCIM set up, deactivating a person from your verified domain in your identity provider deactivates their Atlassian account.
- List external users. Accounts outside your verified domains do not follow your managed-account authentication policies. With Atlassian Guard, you can apply an external user policy that requires them to verify with your single sign-on. Each one still needs an owner.
Atlassian bills for everyone with access to an app, whether or not they log in, so this check usually pays for itself. If your provider is Okta, our Okta SSO and SCIM for Atlassian Cloud service covers this layer end to end.
Check 2: Permissions match what people should see
What ready looks like: your Jira permission schemes, Confluence space permissions, and groups grant what their names say, and sensitive content is restricted where it lives.
Why it matters for agents: agents make over-sharing visible. A Confluence space open to the whole site was a small risk when finding a page meant knowing it existed. An agent can search it, summarize it, and quote it back to anyone who asks.
How to check it:
- List the groups that grant access to large numbers of spaces or projects. For each, confirm who is in it and why.
- Find spaces with HR, finance, legal, or security content and confirm they are restricted.
- Check Jira projects that use a default permission scheme granting browse access to everyone.
- For connected tools such as Google Drive or SharePoint, confirm Rovo's permission sync is working, so restricted files stay restricted.
Fix problems in the permission model, not in each agent. One fix protects every person and every agent that uses a person's account. Agents with their own account need a separate check of what they have been granted, which is covered in Check 4.
Check 3: The content is worth reading
What ready looks like: the pages and work items an agent will draw on are current, owned, and not duplicated across sites or spaces.
Why it matters for agents: an agent answers from what it finds. Three versions of the onboarding page produce three answers. Custom fields duplicated across Jira sites produce reports that do not add up.
How to check it:
- Pick the two or three use cases you plan to start with and list the spaces and projects they depend on.
- Archive or label stale pages in those spaces. Name an owner for each space.
- If you run more than one Jira site, decide whether the agent should span them. If it should, consider consolidating them first so one set of fields and rules applies.
Check 4: Someone controls the agents
What ready looks like: you know who can build agents, who owns each one, which identity each uses, what each can change, and which automations call them.
Why it matters: by default, anyone with access to Rovo Studio can create an agent, and new agents are open to all users. Agents can create Jira work items, update statuses, and create or edit Confluence pages. In automation rules they can be set up to act without asking for confirmation.
How to check it:
- In Rovo Studio settings, limit agent creation to selected groups or to Studio admins until you have an owner model.
- In Atlassian Administration, under Rovo, review which apps Rovo is turned on for. On Enterprise plans you can also control access by user group through allowlists.
- Give every agent a named owner, a one-line purpose, and a review date. Retire agents nobody claims.
- Decide which agents use a person's account and which get their own agent account. For agents with their own account, review the access they have been granted by admins, space admins, and users. Agents that run in automations are safer with their own account, because with a user's account they use the permissions of whoever set up the rule.
- List every automation rule that calls an agent. Where the agent only needs to draft text, prevent it from acting in the automation.
- If people connect outside assistants through the Atlassian Rovo MCP server, review whether API token access is on and, for tools that connect with OAuth, the domain allowlist.
Our step-by-step guide on how to review Rovo agent access covers this check in detail.
Check 5: You can measure it and turn it off
What ready looks like: each agent has a test set it has to pass before more people use it, you can see what agents and connected tools did, and you know exactly how to stop one.
How to check it:
- Build a test set for each agent. Rovo agent evaluations take a CSV of up to 100 prompts and can score response accuracy or resolution rate.
- Confirm the audit log shows what you need. Tool calls through the Rovo MCP server are logged as "Rovo MCP User Actions." Organization-level audit logs need Atlassian Guard or an Enterprise plan and keep events for up to 180 days, so check what yours records before you rely on it.
- Write down the off switches. Blocking Rovo for an app in Atlassian Administration turns off Rovo features, including agents and chat, in that app. Preventing agents from acting in automations stops automated writes. To stop one agent, restrict or delete it, revoke its access, or remove it from automation rules. MCP access has its own controls. Limiting who can create agents stops new ones but does not turn off the ones you have. Know who is allowed to use each switch.
A one-page readiness scorecard
| Area | Ready when | Most common gap |
|---|
| Identities | Every account has a person or an owner; leavers lose access the same day | Deactivated in the identity provider, still active in Atlassian |
| Permissions | Groups grant what their names say; sensitive spaces are restricted | Old project groups with broad grants |
| Content | Source spaces are current and owned | Duplicate pages and fields across sites |
| Agent control | Creation limited; every agent owned; identity chosen on purpose; automations listed | Agents built by anyone, owned by no one |
| Measurement and off switch | Test sets pass; audit log reviewed; stop procedure written | No test set, so nobody knows if answers are right |
What order to do this in
Start at the bottom. Identity first, then permissions, then content, then the agents themselves. It is tempting to start with the agent because that is the visible part. But every gap in the lower layers shows up in the agent's behavior, and fixing it there means fixing it once per agent instead of once for the estate.
This is the model Atlas Bench, an Atlassian Platinum Solution Partner, uses across its work: four layers, from identity and access at the bottom to agents and automation at the top, and each one load bearing for the one above. Our agent readiness assessment is fixed scope. You get the findings, the ownership gaps, and the order to close them in.
Run the five checks with us
Our agent readiness assessment covers all five checks in this guide, in this order, with fixed scope agreed up front. You get the findings, the ownership gaps, and the order to close them in.
Get an agent readiness assessment Or talk to an architect
Questions we get
Do we need to be ready before we try Rovo at all?
No. A small pilot with a known group and low-risk content is a good way to learn. Readiness matters before you open agents to everyone, turn on write actions, or connect them to automation.
How long does a readiness assessment take?
It depends on the size of the estate. Ours is fixed scope and agreed up front, and the output is a findings report with the order to close each gap.
Is this only about Rovo?
No. The same checks apply to outside assistants connected through the Rovo MCP server and to Forge apps. Forge apps can act as the app itself, not only as a user, so also review the scopes and permissions each app is granted.
What is the most common finding?
Accounts and groups nobody can explain. It is also the finding that most often lowers the license bill once it is fixed.
Can we do this ourselves?
Yes. Everything in this guide uses settings and exports you already have. Teams bring us in when the estate is large, spans several sites, or needs evidence an auditor will accept.
