Service accounts vs agent identities in Atlassian Cloud: which to use and who owns each

Use a service account when a script or integration calls Jira or Confluence on its own, and give a Rovo agent its own Agent's account when it runs in automation with no person present. Agents that people chat with should keep using that person's permissions, and every non-human identity needs a named human owner who answers for it.

Atlassian handles agent identity as a choice inside Studio: a Rovo agent runs either on the User's account of whoever is using it, or on its own Agent's account that admins manage like a user. Most other actors that work without a person at the keyboard run as a service account, an automation flow actor, a Forge app, an MCP connection, or a person's API token. The real decision is who owns each non-human actor, what it can reach, and how you turn it off.

What a service account is in Atlassian Cloud

Atlassian defines a service account as an account that is not associated with a person, so it does not need a password and cannot be used to sign in to the Atlassian Cloud interface. An organization admin creates it in Atlassian Administration under Directory, then Service accounts. Atlassian generates the account ID and email, and the email cannot be changed later. Atlassian suggests using the optional description for the person or app that uses the account. We treat it as required.

• Limits. Every organization can create five service accounts for free. Atlassian Guard Standard raises the limit to 250, and an Enterprise subscription raises it to 1,000. Service accounts are not available in Atlassian Government Cloud.
• Billing. A service account with Jira or Confluence access does not count toward your user limit, so Atlassian does not charge your Jira or Confluence plan for it.
• Credentials. A scoped API token, or an OAuth 2.0 client ID and secret. API tokens expire after 1 to 365 days (one year by default), and their scopes cannot be changed after creation. OAuth 2.0 access tokens last 60 minutes, and this option requires the centralized user management experience.
• Permissions. The same permission and scope requirements as user accounts. You assign app roles and can add the account to groups.
• Off switch. Revoke a credential (an API token can take up to 10 minutes to stop working), or delete the account, which removes its access to all apps and deletes its credentials.

One detail matters for identity design. Atlassian says you cannot provision service accounts from your identity provider, and group syncing from one such as Okta may not be available for them. The ownership record has to live somewhere you control.

How Rovo agents get their permissions

When someone builds an agent in Studio, they choose its identity under Access and identity.

• User's account. The agent adopts the identity of the person using it and has the same permissions. Its actions are recorded as that person's. In automations, they are logged against the person who set up the automation.
• Agent's account. The agent has its own account. Organization admins decide which apps it can reach, and space admins and users decide which spaces and pages. Its changes are credited to the agent, which makes them easier to trace in audit logs.

Atlassian recommends the Agent's account for most automation, because an agent on a User's account can reach everything the automation's creator can, including restricted content. If an admin has not set up the Agent's account, agents default to the User's account, so check which one your automated agents actually use.

Admins control the rest. A Studio app admin sets who can create agents: all users (the default), up to 10 selected groups, or no users. An organization admin sets default access for future agents in Atlassian Administration under AI and Rovo, then Agents, then Default access. Atlassian lists Atlassian Guard Premium as the plan for managing each agent's app and group access in Atlassian Administration. Our guide on approving and auditing Rovo agents covers the approval record in detail.

The other non-human actors you already have

• Automation flow actors. In Jira automation, the default actor is a user called Automation for Jira, so its changes show under that name in a work item's history. In Confluence automation, the actor is the person who created the flow. In Jira, app admins can set anyone as the actor, which means a flow can act as a specific person.
• Forge apps. A Forge app can call Atlassian APIs as itself, through its app user, and if the app has the required permissions, that call works regardless of who is using the app. Its reach comes from the permissions the app declares and you approve at installation.
• External tools over the Atlassian MCP server. By default, tools connect with OAuth 2.1 through an interactive consent flow, in the user's context. An organization admin can also allow API token authentication, with a personal token or a service account key.
• Personal API tokens. A script running on someone's own API token acts as that person. Atlassian lets people create tokens with or without scopes, and recommends scopes.

Service account or agent's account: how to choose

• A script, integration, or backend service calling Jira or Confluence with no person present: a service account with a scoped credential. Atlassian's own advice is a separate account for each integration.
• A Rovo agent that runs in an automation flow: an Agent's account, with only the apps, spaces, and tools the task needs.
• A Rovo agent that people chat with: the User's account, so it never sees more than the person asking.
• An external assistant that one person uses: OAuth 2.1 through the MCP server, so it works in that person's context.
• A shared external agent or pipeline: a service account key, and only if your admins allow API token authentication for the MCP server.
• Never: a person's API token inside a shared integration.

Why a person's API token is the wrong default

A token created by a person depends on that person's account. Atlassian's knowledge base says the token stops working once the account is deleted, so check automation flows and external scripts first. The quieter failure runs the other way: the same article says a user's tokens remain usable as long as the account still has access to your site, so an incomplete offboarding leaves them working.

Atlassian gives admins some controls. User API tokens expire after one year by default, and people can choose 1 to 365 days. With Atlassian Guard Standard, an authentication policy can set the expiry for its members. Any authentication policy can block members from creating new tokens or using existing ones. Organization admins can see managed accounts' tokens under Insights, then API token activity, with created, expiry, and last-used dates, and revoke them there. Atlassian's Guard plan page lists user API token management under Guard Standard, so confirm what your plan shows. Use them to move shared integrations onto service accounts and shorten or block personal tokens.

What to record for every non-human identity

Keep one record per service account, Agent's account agent, Forge app, and automation flow that runs as a person. Store it where your change approvals already live.

• Owner. A named person managed in Okta, plus a backup. Put the owner in the service account's description too.
• Purpose. One sentence on what it does and for which team.
• Scope. App roles, groups, spaces, token or OAuth scopes, and for agents, every tool that writes data.
• Credential. The type (API token or OAuth 2.0 client) and where the secret is stored. For agents and Forge apps, record who granted access and when.
• Expiry or rotation. The token's expiry date, or the date you will next rotate the OAuth client secret.
• Off switch. The exact control (revoke, delete, remove app access, disable the flow) and who holds it.

Where Okta and Atlassian Guard fit

Okta stays the source of truth for people: who works here, which groups they are in, and when they leave. Each person has one Atlassian account, so every owner on the record must be a person Okta manages. With Atlassian Guard user provisioning, a user you deactivate in your identity provider is automatically deactivated in your Atlassian organization. Before that happens to an owner, your leaver process should reassign what they own. After Okta deprovisions an owner, confirm the Atlassian account shows as deactivated and revoke any API tokens it still holds. Our guide to Okta and Atlassian Guard as one identity model covers that split.

Atlassian Guard supplements this on the Atlassian side. Guard Standard raises the service account limit and lets authentication policies set user token expiry. Organization audit logs need Guard Standard or Premium, or an Enterprise plan. Atlassian keeps 180 days of activity, or 365 days with Atlassian Guard from October 1, 2026, so export the logs you need to keep longer. The log records service account events (accounts created, updated, and deleted, and API tokens created and revoked) and Rovo agents created, updated, and deleted. Audit logs for user-created activity in Jira, Jira Service Management, and Confluence need Guard Premium or an Enterprise plan.

A review routine that holds up

1. Monthly, tokens. Export user API token activity and check each service account's tokens. Flag tokens that expire within 30 days, tokens unused for 90 days, and tokens held by people who have left.
2. Monthly, new identities. Search the audit log for service account and Rovo agent events, and match each new one to a record. No record, no access.
3. Quarterly, scope. Each owner confirms the purpose still exists and the scope is still the minimum. API token scopes cannot be edited, so narrowing one means issuing a new token and revoking the old one.
4. Quarterly, agent settings. Check who can create agents in Studio, the default access for future agents, and which automated agents still run on a User's account.
5. Quarterly, one off switch. Pick one identity and walk through its off switch with the person who holds it, end to end.
6. Every leaver. Before Okta deprovisions someone, list what they own and reassign it, and check whether their personal tokens feed any integration. Afterward, confirm the Atlassian account is deactivated and its tokens are revoked.

We run this as a standing routine through our access reviews service, with evidence your auditors can read.

Start with an inventory

Start with three questions: who owns each service account, which agents run on their own account, and whose personal tokens keep your integrations running. Our free Atlassian identity check starts on all three with a findings list ranked by risk and cost, covering unowned service accounts, user API tokens and their expiry, and Rovo agents. If you already know the gaps, our identity and access service designs one model for people and machine identities across Okta and Atlassian Guard.