Jira Now Runs AI Agents: Governance Questions Emerge

The Jira instance you administer is becoming a runtime for AI agents. That shift has governance consequences nobody is talking about clearly yet.

SmartBear's BearQ, now surfaced inside Jira, is one data point. Atlassian's own Rovo agents are another. The pattern is consistent: AI capabilities are no longer living in separate SaaS dashboards that your teams occasionally open. They are being embedded directly into the Jira UI and, more importantly, into Jira's data layer — reading issues, writing comments, creating or transitioning work items, sometimes acting on webhook triggers without a human in the loop.

For a project manager, this looks like productivity. For a Jira admin, it looks like a new class of actor in your instance that you may not have a governance model for yet.

What "embedded AI" actually means at the API level

When a vendor embeds an AI agent into Jira, one of a few things is happening technically:

• OAuth app with scopes — the agent authenticates as an OAuth 2.0 app and acts within declared Jira API scopes. You can see this in your Atlassian admin console under "Connected apps."
• Forge app with autonomous invocation — the agent runs on Atlassian's Forge infrastructure and can be triggered by Jira events (issue created, field changed, etc.) without the user clicking anything.
• External service with a service account — the agent uses a bot user's API token. Older pattern, still common, harder to audit because the actions appear under a named user account.

The governance question is the same in all three cases: what can this agent do, when is it allowed to do it, and where do its actions appear in your audit log?

With a standard Marketplace app, the answer is usually bounded and static — the app reads certain fields, displays a panel, maybe writes to a custom field. With an AI agent, the action surface is intentionally open-ended. That is the point. An agent that can only do one thing is not much of an agent.

The audit log problem

Jira Cloud's audit log captures administrative events well. It captures user-initiated issue changes reasonably well. It is not designed around the concept of an autonomous agent making a sequence of decisions and writes across dozens of issues in response to a single trigger.

If BearQ or a Rovo agent creates ten sub-tasks, transitions three issues, and adds comments to a sprint's worth of tickets in response to a CI failure event — what does your audit trail look like? Who is accountable if the agent made a wrong call?

This is not hypothetical. It is the next support ticket you will get from an engineering manager asking why their sprint board looks different than it did yesterday.

Before you approve an AI-embedded Marketplace app at the org level, it is worth asking the vendor explicitly:

• Does every action the agent takes appear in the Jira audit log under an identifiable actor?
• Can the agent be scoped to specific projects, or does it act across the entire instance by default?
• Is there a dry-run or preview mode before the agent is allowed to write?
• What happens when the agent encounters a permission boundary — does it fail silently or surface an error?

Scope creep is structural, not a bug

AI agent vendors have a product incentive to make their agents as capable as possible. Broad Jira API scopes make agents more useful. A testing agent that can only read test results but cannot create or link issues is less impressive in a demo than one that can do the full workflow end to end.

This creates a structural tension: the more powerful the agent, the more you need a governance policy before you install it, not after.

Cloud Fortified status — which La Forge holds, and which SmartBear's Marketplace presence also reflects — tells you that a vendor has passed Atlassian's security review and participates in a bug bounty program. That is a real signal about the vendor's security posture. It does not tell you what the agent will do with the permissions you grant it.

These are different questions. Security certification answers: "Is this app built safely?" Governance policy answers: "What is this app allowed to do in my specific instance, and who decided that?"

A working approach for admins evaluating AI-embedded apps

There is no established playbook for this yet, which is part of the problem. Here is what a reasonable evaluation looks like today:

1. Identify the authentication pattern. Check your Connected Apps list in Atlassian Admin immediately after a trial install. Review the declared scopes before any agent is active.

2. Install into a staging project first. Scope the trial to one non-critical project. Most Jira AI integrations respect project-level restrictions if you configure them; some default to instance-wide.

3. Run a supervised session. Give the agent a real workload in staging and watch what it produces. Do not rely on the vendor's demo.

4. Check what appears in the audit log. Run a test action and search the audit log for the agent's actor identity. If you cannot find the action, that is a gap you need to resolve before production.

5. Define a policy before rollout, not after. Decide in advance: which projects can agents operate in, who can enable or disable them, and what the escalation path is if an agent makes a destructive change.

The broader shift

The Atlassian ecosystem is moving toward Jira as an orchestration layer, not just a tracking tool. AI agents are the most visible expression of that shift right now. For admins, the practical consequence is that the instance you govern is accumulating autonomous actors alongside human ones — and the tooling to manage that distinction is still catching up.

Asking hard governance questions before an AI-embedded app goes org-wide is not obstruction. It is the job. The vendors building good products in this space should be able to answer those questions clearly. If they cannot, that tells you something worth knowing before the rollout.