Atlassian Scopes
You set up atlassian scopes by picking the exact API permissions your app needs. These rules tell Jira and Confluence what data an external tool can read or write. Teams often start by picking broad scopes to make a new script work fast. Those wide permissions stay in place long after the test ends. If a token leaks, an attacker can read or delete data across many projects. How atlassian scopes control API permissions Every tool that talks to Jira or Confluence needs a set of permissions. You
Scopes: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up atlassian scopes by picking the exact API permissions your app needs. These rules tell Jira and Confluence what data an external tool can read or write. Teams often start by picking broad scopes to make a new script work fast. Those wide permissions stay in place long after the test ends. If a token leaks, an attacker can read or delete data across many projects.
How atlassian scopes control API permissions
Every tool that talks to Jira or Confluence needs a set of permissions. You choose these permissions in the developer console when you build an app. Users also pick them when they make a scoped API token. The platform divides these rules into classic scopes and granular scopes. Classic scopes group many actions together under one broad label. For example, one classic scope might allow reading all project boards and issues. Granular scopes break those actions down into much smaller parts. You can grant the right to read issue comments without allowing edits. When your app sends a request, the server checks the token first. It compares the requested API path against the list of approved scopes. If the scope matches the endpoint, the server runs the request. The token also inherits the base role of the user who created it. A scope cannot give an app more power than the user already holds. Both the user role and the token scope must allow the action.
Why token permissions leave runtime gaps
Scopes do a good job of blocking API paths your app never uses. They stop a simple reporting script from deleting a project space by mistake. Still, scopes only check the general type of API call at login. They do not inspect the actual payload or query parameters in flight. A scope that allows issue updates permits changing one ticket or ten thousand tickets. The platform cannot tell if a script is fixing a bug or wiping boards. It also cannot mask sensitive fields inside the response body. If a ticket comment holds customer emails, phone numbers, or card numbers, the API returns them. Data masking is needed to rewrite matched fields in results before tools read them. Scopes also make it hard to require human approval for one risky write call. Once you grant a write scope, the token can run updates at any time. Teams often end up creating shared service accounts to hold these tokens. When five engineers share one token, the audit log shows only the bot name. You lose track of which person ran a specific script or changed a ticket.
How to keep API permissions tight
Start by auditing every active token and app in your workspace today. Replace broad classic rules with granular permissions wherever the API supports them. Give read-only scopes to reporting tools, AI agents, and search scripts. Never reuse the same token across two different scripts or teams. Set short expiration dates on all user tokens so old keys stop working. Review your app permissions whenever your team changes how a workflow runs. If a script no longer writes comments, remove that write scope right away. Check your workspace audit logs each week for failed permission checks. Failed calls often show where a script is trying to reach outside its bounds. Keep service account roles restricted to only the specific projects they must touch. Combining tight project roles with narrow scopes shrinks the blast radius of any leak.
Scopes: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between classic and granular scopes?
Classic scopes bundle many related API actions into one broad permission rule. Granular scopes split those actions apart so you can allow single endpoints.
Can a scope grant access to a private Jira project?
No, a token only works within the permissions of the user who made it. If the user cannot view a private project, the token cannot read it either.
What happens if an app requests an endpoint outside its scopes?
The server blocks the call right away and returns a forbidden status code. You must update the app permissions and reauthorize the token to use that endpoint.