AI readiness assessment for Jira: what gets checked before an agent goes in
Before an AI agent reads or writes anything in Jira, five things decide whether it helps or does damage: how permissions carry into what it retrieves, how clean your fields and workflows are, who owns each automation, whether changes are logged, and which agent belongs where. This is the Jira version of the two-week audit, same price, plus those checks.
Key takeaways
- An agent that searches Jira or Confluence on a user’s behalf is only as safe as the permission schemes, issue security levels and page restrictions behind it.
- Duplicate fields and drifting workflows are the usual reason an agent gives confident wrong answers: it cannot tell which of three "Priority" fields is real.
- Rovo covers a lot of in-issue work out of the box; a custom agent earns its cost only where Rovo cannot reach, and the assessment says which side each use case falls on.
Permissions and how they reach AI retrieval
Jira decides who sees what through permission schemes, project roles, groups and issue security levels; Confluence adds space permissions and page restrictions on top. A human user meets those rules one screen at a time. An AI that searches on their behalf meets all of them at once, and any rule that was quietly wrong becomes a leak with a chat interface.
I check which identity each AI integration acts as, whether that identity sees more than the person asking, and whether restricted projects or spaces would surface in answers. The output is a short list of fixes to make before any agent gets a token.
Field and workflow hygiene
An agent reasons from your fields. If a site has three fields that all mean priority, statuses that differ by project for no reason, or screens where half the fields are never filled, the model has no reliable signal to work from. I measure how much of that exists, which projects carry most of it, and which of the clean-ups actually matter for the use case you have in mind.
Who owns each automation rule
Jira automation tends to grow faster than anyone tracks it. Rules written by people who left, rules that fight over the same field, rules that run on every issue in the site: each one is a thing an agent can trigger by accident. The assessment lists every rule, its owner or the absence of one, and the rules an AI step would collide with.
Audit logging for agent actions
When an agent changes something, you need to know what changed, who asked for it and how to undo it. I check what the Jira and Confluence audit logs already record for your plan, what an agent’s actions would look like in them, and what extra logging the build needs so every AI change can be traced and reversed. That record is the agent audit trail your security review will ask for.
Rovo, a custom agent, or neither
Rovo is Atlassian’s own AI layer and handles a good share of in-issue work already; what it can and cannot change is mapped in the guide on what Rovo can change in Jira. A custom agent, connected through MCP or the Jira APIs, makes sense where Rovo cannot reach, such as across systems or into configuration. For each use case the assessment recommends one of the two, or no agent at all.
Who this version is not for
If your work does not run in Jira, JSM or Confluence, take the general audit instead. If you only need permissions or automations cleaned up and have no AI plans yet, a fixed-price Jira and JSM automation project costs less than an assessment.
AI Readiness Audit
$3,500 USD, fixed
2 weeks. Credited in full against a Deployment that starts within 90 days. Invoiced after a short scoping call; pay by card through Paddle or by bank transfer.
Questions
Do you need Jira admin rights for the assessment?
Does this cover Jira Service Management?
Will you recommend Rovo?
Bring the use case you have in mind; the call is enough to tell whether the Jira checks apply.