Issue Summary

Currently, the Rovo Dev {{

{GenerateCode}}} action in Jira Automation runs in restricted mode by design. This means that when Rovo Dev is triggered via an automation rule, the session is stripped of all Jira and Confluence MCP tool access. The agent can only perform code-related operations (clone repo, create branch, open draft PR) but cannot read or write Jira issues, change statuses, add comments, or access Confluence content within the automation session.

This restriction exists because the automation session runs as the "connection user" (the person who set up the rule) rather than the user who triggered it, creating a security risk around prompt injection and privilege escalation. However, this severely limits the usefulness of Rovo Dev in automation workflows that require interaction with Jira data.

Notably, assigning work directly to Rovo Dev (outside automation) provides full MCP access and works as expected, the limitation only applies to the {{{GenerateCode}

}} automation action.

Public documentation confirming this behavior: [Work with Rovo Dev in automations | Rovo | Atlassian Support|https://support.atlassian.com/rovo/docs/work-with-rovo-dev-in-automations/]

"Rovo Dev automation actions run in a restricted mode and don't use Atlassian Teamwork Graph context."

Customer Use Case

A customer wants to:

1. Build an automation flow with handoffs between Rovo Dev agents where {{ {GenerateCode}}} can read the Jira issue details (description, acceptance criteria, custom fields) to inform code generation
   
   # Have Rovo Dev update the Jira issue status and add comments upon completion within the same automation session
   
   # Create end-to-end automated workflows where Rovo Dev handles both code generation AND Jira interactions without requiring manual intervention
   
   Currently none of these are achievable because:
   * The {{{GenerateCode}

   }} action runs in restricted mode, Jira MCP tools (mcp_jira_get_jira_issue, etc.) are not loaded into the sessio

Expected Results

Customers should have the ability to:

1. Enable Jira MCP tool access for Rovo Dev in Automation: either via an admin-controlled setting or through the planned "Agent Accounts" solution that provides a dedicated bot identity with configurable, scoped permissions

1. Configure which MCP tools are available in automation sessions on a per-project or per-rule basis, allowing admins to balance security with functionality (e.g., allow read-only Jira access but not write)

1. Maintain security safeguards while enabling richer automation, such as audit logging, scoped permissions, and admin opt-in controls rather than a blanket restriction