Non-human identities in Atlassian Cloud are the service accounts, API tokens, apps, and agents that act without a person signing in. Govern them the way you govern people: every one gets an owner, a scope, an expiry date, and a place in the access review.
For years, most Atlassian estates had a handful of these, usually an "integration user" someone created for a script. That is changing fast. Rovo agents, Forge apps, outside assistants connected through the Rovo MCP server, and service accounts for automation all add identities that nobody hires and nobody offboards. This guide covers what each type is, how Atlassian handles it today, and a simple model to keep them under control. It reflects how Atlas Bench runs the non-human side of an identity engagement.
The five kinds you will find
1. Service accounts
Atlassian Administration now has service accounts: identities for automation that are not tied to a person and cannot sign in through the web. According to Atlassian's documentation, every organization gets 5 free, Atlassian Guard Standard allows up to 250, and Enterprise allows up to 1,000. They do not count toward your user limit, and they cannot be provisioned from your identity provider.
Service accounts use one of two credentials:
- Scoped API tokens, limited to specific permissions and valid for 1 to 365 days. They are used through api.atlassian.com.
- OAuth 2.0 client credentials, which issue access tokens valid for 60 minutes. These need the centralized user management experience in Atlassian Administration.
For most new integrations, a service account is the right home. It has no person behind it to leave, and its access is scoped by design.
2. Integration users
These are ordinary managed accounts created for a script or tool before service accounts existed. They take a seat, they often have admin rights "to be safe," and the person who created them has often left. In most estates we review, they are the biggest non-human risk and the easiest one to fix: move the integration to a service account, then deactivate the old user.
3. Personal API tokens
People create API tokens on their own accounts to connect scripts and tools. Since December 15, 2024, new tokens expire after one year by default, and 365 days is the maximum. Tokens created before that date were set to expire between March 14 and May 12, 2026, so integrations built on older tokens may have stopped working this spring. On any plan, org admins can see token counts, creation, expiry, and last-used dates for tokens created by managed accounts, and revoke them centrally.
A personal token acts with that person's permissions and keeps working until it expires, is revoked, or the person's account is deactivated. That is fine for a person's own tools. It is the wrong choice for anything the business depends on.
4. Apps
Forge apps can call Jira and Confluence in two ways. With asApp, the request runs as the app user with the app's own permissions, whoever is using the app. With asUser, it runs with the permissions of the person using the app, after that person grants the app access. When you review an app, ask which mode it uses for what, because asApp access does not shrink when a person's access does. Connect apps and OAuth 2.0 integrations also act on your data, so include them in the review too.
5. Agents
A Rovo agent uses one of two identities, chosen when it is built. With a user's account, it takes on the identity and permissions of the person using it, and can only see or change what that person can. With its own agent account, it has only the access granted by org admins, app and space admins, and users who share their content with it, and anything it creates or edits is credited to the agent. With Atlassian Guard Premium, org admins manage an agent's app access and group membership in Atlassian Administration.
Agents can also run inside automation rules. An automated agent that uses a user's account runs with the permissions of whoever set up the rule. Outside assistants can connect through the Rovo MCP server, and when they use an API token, activity is logged under the account that owns the token, whether a person or a service account, rather than under each person using the tool.
How the types compare
| Type | Where it lives | Credential | How long it lasts |
|---|
| Service account | Atlassian Administration | Scoped API token or OAuth 2.0 client credentials | Token 1 to 365 days; OAuth access token 60 minutes |
| Integration user | A regular managed account | Password, single sign-on, or personal API token | Until someone deactivates it |
| Personal API token | A person's Atlassian account | API token | Up to 365 days |
| Forge app | Installed on the site | App identity (asApp) or the user's (asUser) | Until uninstalled |
| Rovo agent | Rovo Studio and Atlassian Administration | The person's account, or its own agent account | Until retired |
A governance model that holds
Every non-human identity needs four attributes. If you can fill them in for each one, you are in good shape. If you cannot, that is your backlog.
- Owner. A named person accountable for what the identity does. Not a team, not the person who created it three years ago.
- Scope. The projects, spaces, and actions it needs, and nothing else. Prefer scoped tokens over broad ones and service accounts over integration users.
- Expiry. A date when the credential ends or the identity is reviewed. Atlassian's token limits give you a maximum; set a shorter one where you can.
- Review. A place in your regular access review, next to the human accounts, with the same evidence.
Where to start this week
- Export users and look for accounts whose names suggest a system: "jira-bot," "integration," "svc." List each with its last active date and group membership.
- Pull the API token report from Atlassian Administration. Find tokens with no recent use and tokens owned by people who have left.
- List installed apps and, for your in-house Forge apps, note which calls use asApp.
- List Rovo agents, whether each uses a person's account or its own, their owners, and any automation rules that call them.
- Pick the riskiest integration user and move it to a service account with a scoped token.
The audit log helps you keep this current. Atlassian lists events for creating and deleting service accounts, creating and revoking API tokens, creating, updating, and deleting Rovo agents, and installing and uninstalling apps. Organization audit logs need Atlassian Guard or an Enterprise plan, so confirm those events appear in your organization's log and that someone reviews them.
Why this matters more with agents
Every new agent, connector, and automation adds identities. None of them are hired through HR, so none of them leave through HR. If the human side of your estate is already hard to explain, the non-human side will get harder faster. Atlas Bench, an Atlassian Platinum Solution Partner, builds non-human identities into the same joiner, mover, and leaver process as people in its identity and access work, and our agent readiness assessment starts here: human and non-human access, the accounts nobody owns, and what has to be true before an agent gets one.
For related reading, see what identity debt is in an Atlassian Cloud migration and Okta SSO and SCIM for Atlassian Cloud.
Find the accounts nobody owns
Our agent readiness assessment starts at the identity layer: human and non-human access, the accounts nobody owns, and what has to be true before an agent gets one. Fixed scope, with the findings and the order to close them in.
Get an agent readiness assessment Or talk to an architect
Questions we get
Do service accounts cost extra?
Atlassian's documentation says service accounts do not count toward your user limit. Every organization gets 5, and the number available goes up with Atlassian Guard Standard and Enterprise. Check your own plan before you plan a large move.
Can we provision service accounts from Okta or Entra ID?
No. Atlassian's documentation says service accounts cannot be provisioned from an identity provider. They are created and managed in Atlassian Administration, so they need their own owner and review.
Why did our integrations stop working this year?
Likely token expiry. API tokens created before December 15, 2024 were set to expire between March 14 and May 12, 2026, and new tokens last at most 365 days. Move business integrations to service accounts and track expiry dates.
Are Rovo agents non-human identities?
It depends on the setup. An agent that uses a person's account acts with that person's permissions. An agent with its own account holds access of its own, just like a user. Treat both as identities: each needs an owner, a purpose, and a review date, and any automation that calls one needs an owner too.
What is the first thing to fix?
Integration users with admin rights and no owner. They take seats, they carry the most access, and moving them to scoped service accounts is usually quick work.
