Summary

This was originally reported as a bug but this is intended behaviour.

In automations, agents always use the permissions of the connection user in the automation.  That is because automations are designed to run when there is no user present. This means whether triggered by a ticket create, a schedule, a manual trigger, or any other trigger.

We will soon be introducing agent accounts  which will allow the agent to run in all these places with it's own agent permissions. If you, or any customers are interested in this leave a comment an I'll share the EAP when ready.

This has been changed to a feature request to support agents in manual automations using the triggering users permissions, which I believe is what is being asked here.

Original Description

When a Rovo agent is invoked via a Jira Automation rule or JSM playbook — configured to "act as the user who triggered the rule" — the agent's Confluence search results include links to pages that the triggering user does not have permission to view. This results in unintended exposure of restricted content references in automation contexts.

Steps to Reproduce

1. In Confluence, create a page with page-level view restrictions (Restrictions > "Only specific people can view this page"). Ensure the test user does NOT have view access to this page.
2. In Rovo, create a new agent and configure its knowledge source to include the Confluence space where the restricted page was created in step 1.
3. In JSM, go to Project Settings > Automation and create a new rule. Set the Actor to "User who triggered the rule". Add an action: "Use agent" and select the Rovo agent created in step 2. Add a second action: "Add comment to work item" and set the comment content to the result/output of the Rovo agent action. Save and enable the automation rule.
4. In JSM, go to Playbooks and create a new playbook. Add a step with step type "Automation rule" and select the automation rule created in step 3. Save the playbook.
5. Log in as a user who does NOT have permission to view the restricted Confluence page created in step 1.
6. As that user, create a new JSM ticket.
7. Trigger the playbook on that ticket.
8. Observe the comment added to the ticket by the automation — it includes a link to the restricted Confluence page.
9. Click the link as the triggering user — a 403 / "You don't have permission to view this page" error is returned in Confluence.

Expected Results

The Rovo agent only surfaces Confluence pages that the triggering user has permission to view. The comment added to the work item should not contain links to pages the triggering user cannot access.

Actual Results

The comment posted to the work item includes a link to the restricted Confluence page. Clicking the link as the triggering user results in a 403 / "You don't have permission to view this page" error in Confluence.

Additional Context

• This issue does NOT occur in Rovo Chat. When the same user interacts with the same Rovo agent directly via Rovo Chat, restricted pages are correctly excluded from results. Permissions work as expected in that context because the user's authenticated session token is used directly.
• This issue is specific to the JSM automation/playbook invocation path. The "act as the user who triggered the rule" setting appears to apply to Jira actions (e.g. adding comments, transitioning issues) but does not appear to be correctly propagated to the Rovo Search layer when the agent performs its Confluence content lookup.
• As a result, the Confluence search within the agent likely executes under a broader service/bot account identity, bypassing page-level view restrictions.
• The "Content Read" verification that is intended to filter search results based on the acting user's permissions does not appear to function correctly in this automation-triggered context.
• Space-level exclusion is not a viable workaround for customers whose internal KB spaces use view restrictions at the page or subtree level across many spaces — which is a common real-world configuration.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available