Usually not, at least not currently from Jira's own records. Atlassian's Rovo agents act under the identity of whoever invoked them, so a Rovo-driven change typically shows up in work item history as the confirming human, not the AI. As human+AI collaboration scales, that blind spot matters: recovery can't depend on knowing who or what caused a problem, because you often can't find out.
Not clearly. Atlassian's own documentation states that when someone interacts with a Rovo agent, "the agent is acting on that person's behalf" — it inherits the invoking user's identity rather than operating as a separate one. In practice, Jira admins have confirmed exactly what that means day to day: a Rovo action triggered through chat shows the human who confirmed it in the work item's history, and an action triggered through automation shows the automation rule as the actor. Rovo's own involvement isn't recorded at the item level either way.
This isn't a hypothetical edge case — it's an active discussion among Jira admins right now, with the most recent community activity on the topic dated within the past two months.
Something, but not what you'd need for an incident. Atlassian's admin-level audit log does track Rovo at the account and agent level — chat sessions started, agents created or modified, connector activity — filterable specifically by "Atlassian Rovo." What it doesn't capture is the specific work item changes an agent's actions led to, or any prompt/response content.
Customers have noticed this gap too: there's an open, actively-voted request asking Atlassian to expand Rovo-specific audit logging, still unresolved as of this writing. Until that changes, the honest answer is that native Jira tooling isn't built to answer "did a person or an AI make this decision."
When something goes wrong in a human+AI workflow, the instinct is to ask "who did this." Given the gap above, that question can eat up your entire response window without an answer. The more useful question — and the one you can actually answer — is "what changed, where, and when." That's a question about the data, not about identity, and it's answerable regardless of whether a person or an agent triggered the change.
This is where a searchable, durable audit trail matters — not because it tells you who or what caused a problem, but because it tells you exactly what happened. Revyz captures Jira's audit data into your backups and makes it filterable by date range, author, event category, and changed object, with retention that extends well past Jira's native window. That's still useful even without a clean human/AI distinction: you can narrow to the time window an incident occurred and the work items or projects (spaces) affected, build an accurate picture of the damage, and then restore exactly those work items from a snapshot taken before the incident — without a disruptive full-project (space) rollback that would also undo unrelated work.
To be direct about what this does and doesn't do: it doesn't add attribution data Jira itself doesn't produce. It makes what Jira does record easier to search and keeps it around longer, and pairs that with the ability to undo precisely what changed.
A few practical habits reduce how often this gap actually bites:
Does Jira's work item history show when Rovo made a change? Not directly. When a Rovo action is triggered through chat, the human who confirmed it appears in the work item history — not Rovo. Automation-triggered actions show the automation rule as the actor instead. Rovo's specific involvement isn't recorded at the item level in either case.
Does Jira's audit log track what Rovo agents do? Partially. Atlassian's audit log captures account-level Rovo activity — chat sessions started, agents created or modified, connector actions — filterable by "Atlassian Rovo." It does not capture the specific work item changes an agent's actions resulted in, or any prompt/response content.
Can you tell whether a bad Jira change was caused by a person or an AI agent? Often not with certainty, using native Jira records alone. Because Rovo acts under the invoking user's identity, the audit trail typically shows a human account regardless of whether a person or an agent drove the action. Customers have an open, unresolved request asking Atlassian for more detailed Rovo-specific audit data.
If you can't tell who caused a bad change, how do you fix it? You don't need to know who or what caused it to fix it — you need to know what changed. A searchable, backed-up audit log lets you filter by date range and changed object to isolate the affected work items, then restore just those from a snapshot taken before the incident.
How does Revyz help if it doesn't add attribution data Jira doesn't already track? It doesn't invent attribution Jira doesn't capture, — it makes the audit data Jira does record searchable and keeps it available well past Jira's native retention window, so you can still investigate an incident weeks later and restore precisely what changed.
While native cloud tools protect against site-level disasters, they aren't designed for item-level human or AI errors. If an AI agent accidentally bulk-modifies or overwrites 500 Jira tickets, native tools cannot selectively roll back just those 500 tickets. Revyz provides the granular control needed to undo specific automated mistakes fast.