Understand Rovo agent accounts
Rovo agents can find information and perform tasks across your Atlassian apps and any connected apps. You can control what Rovo agents access using organization-wide settings and specific permissions granted by the person who created the agent, admins, or other users.
How agent accounts work
Just like users, Rovo agents use an Atlassian account to access Atlassian apps and connected, third-party apps. You can manage which account an agent will use — either the account of the person interacting with it, or the agent's own account.
When agents use a person’s account, it gets the same permissions and access across Atlassian apps as that person. When the agent acts, the action is recorded as performed by the user with the agent's help.
If the agent uses its own account, its access is managed the same was any user in your organization:
Organization access: Default access set by organization admins who determine what apps and agents can access within your organization. This acts as a safety net so that agents interact only with approved data sources. These settings are managed in Atlassian Administration. Read more about managing agents in your organization
App access: App and space admins can grant or deny agents access to spaces.
User access: Any user can grant an agent access to their own content.
Control what an agent can access
When you build an agent, you choose which account it will use. There are two options, and whichever you pick defines whose permissions the agent will adopt.
User’s account
The agent will adopt the identity of the person who’s using it, inheriting all of their existing permissions and access.
For example, if Luke asks the agent a question, the agent can only view and use information that Luke already has permission to access within his organization.
Anything the agent creates, edits, or updates will appear as being performed by the user that’s interacting with it. In automations, these actions are logged against the user who set up the automation.
This access type works best for chat and personal assistance use cases, because the agent can access everything the user can.
Agent’s account
The agent will use its own account with permissions managed by admins at the organization, space or app level — just like user permissions. And like with a user, people can grant an agent access to their space or page.
For example, a Rovo agent used in automations might have some basic access in an organization, but specific access to a space where it performs tasks. This allows team to automate the agent safely and securely, without depending on a user's credentials and the access they have.
Anything the agent creates, edits, or updates will be credited to the agent.
This option is best when using agents in automations, where you may not want an automated agent using someones permissions.
Choose what an agent can access
Agent access in automation flows
When a Rovo agent is used as part of an automation flow, the access you choose becomes extra important because there’s no human approving each step or agent action.
In automations, a User’s account relies on the permissions of the person who creates the automation flow, not the agent’s own identity. The agent will have access to all the spaces and content the person creating the automation has, which may include restricted spaces or content. Even if an agent is configured to use specific tools, it can still perform any action the user can, potentially giving it more access than it needs to run the automation.
The Agent’s account however, uses the agent's own identity to navigate whatever specific spaces and content it’s been granted access to. The agent may have been given default access to some spaces and pages, but it’s worth checking it has access to read and act in the spaces you need it to work.
For most automation use cases, we suggest you use the Agent’s account to minimize security risks. The agent can then operate within whatever narrow access it has been granted, rather than the full access of a specific user.
If you have an agent configured to with a User’s account, you can always clone it and change the access to Agent’s account. This requires your admin to set up default access for agent accounts in your organization.
Before you set up agents in automations, understand the risks and best practices
Imagine you want every new Jira work item automatically triaged.
Using Agent’s account, the agent acts under its own identity, with only the permissions granted to it by you, admins and other users. When an event triggers, and the agent runs, any changes will appear under the agent's name making it easier to track in audit logs.
If you were to change the agent to have a User’s account the agent will use the permissions of whoever sets up the trigger or automation. This means that changes will be logged as being performed by a user (or users) not the agent.
Was this helpful?