Approving Matico for your Atlassian org

Matico is a SaaS product for engineering managers and tech leads. It sits on top of JIRA and automates routine coordination work — flagging blocked tickets, tracking release milestones, surfacing scope changes, capturing action items, and routing nudges through Slack. It does not replace JIRA; it reads the work that is already there and adds a layer of management workflow on top.

Matico connects to JIRA Cloud using Atlassian’s standard OAuth 2.0 (3LO) flow. No API tokens, no service accounts, no password-based access. The connecting user authorizes Matico from inside JIRA’s own consent screen, and Matico only ever sees the projects and issues that user already has permission to see.

The exact OAuth scopes Matico requests are listed below. These are the strings Atlassian will display on the consent screen when a user connects.

• read:jira-workRead

  Read projects, issues, sprints, boards, comments, and issue history for the projects the connecting user can already see in JIRA.

• read:jira-userRead

  Read user profile information (display name, email, avatar) for assignees, reporters, and team members surfaced in the connecting user's projects.

• write:jira-workWrite

  Create and update issues on behalf of the connecting user — used only for explicit user actions, such as converting a Matico action item into a JIRA ticket or pushing a status change initiated from the Matico UI.

• manage:jira-webhookWrite

  Register and remove webhooks against the connected JIRA site so Matico can receive real-time issue updates without polling. Matico only creates webhooks scoped to the events it needs.

• offline_accessSession

  Issue a refresh token so Matico can continue syncing in the background without forcing the user to re-authenticate every hour. Standard for any JIRA OAuth app that runs scheduled work.

A note on write access. Matico does request the write:jira-work scope. This is used only when a user takes an explicit write action inside Matico — for example, converting a Matico action item into a JIRA ticket, or updating a ticket’s status from a Matico view. Matico does not perform background writes, does not modify ticket bodies on a schedule, and does not push Matico-generated content into existing tickets without a user action.

• Atlassian organization or site administration
• Billing, licensing, or user provisioning
• Confluence, Bitbucket, Jira Service Management, Compass, or any non-JIRA Atlassian product
• Projects the connecting user does not have permission to see
• Atlassian account passwords or API tokens (Matico never receives these)

Matico uses Clerk for user authentication. Sign-in is JWT-based and supports the standard identity providers an enterprise expects (email, Google, and SSO options Clerk surfaces). Matico never stores a user’s Atlassian password or API token; the JIRA connection is held purely as an OAuth refresh token, scoped to the user who consented and revocable at any time.

If your organization restricts third-party apps in Atlassian, the user’s OAuth attempt will be blocked until an org admin approves Matico. The exact navigation path in the Atlassian admin console may vary slightly by plan and rollout, but the high-level steps are:

1. 1

   Sign in to admin.atlassian.com as an Atlassian organization admin.

2. 2

   Open Settings → Connected apps (the exact label may read “Apps” or “Connected third-party apps” depending on your organization’s plan).

3. 3

   Locate Matico in the list of third-party apps that have requested access, or — if your policy blocks unknown apps by default — add Matico to the allow list.

4. 4

   Approve Matico for the relevant site(s). Once approved, the requesting user can finish OAuth from inside Matico; they will be asked to consent to the scopes listed above, and only the projects they personally can see in JIRA become visible to Matico.

• In transit. All traffic between Matico and Atlassian, between Matico and the browser, and between Matico services is over TLS.
• At rest. JIRA OAuth access and refresh tokens are encrypted at rest using AES-256-GCM before being persisted, with the encryption key held outside the application database.
• Scoped per user. Matico stores one refresh token per connecting user, scoped to that user’s JIRA permissions. There is no shared service account.
• Revocable. The connecting user can disconnect at any time from inside Matico, which immediately wipes stored tokens. An Atlassian org admin can additionally revoke Matico’s access for the whole organization from the Connected apps surface.
• Tenant isolation. Matico is multi-tenant; every record is scoped to a single workspace at the data-access layer, so a user in one workspace cannot read data from another.

Matico is in private beta and does not currently claim formal compliance certifications (SOC 2, ISO 27001, etc.). If your procurement process requires a specific certification or a security questionnaire, please reach out using the contact below and we will share what we have.

For security questions, a security questionnaire, or to request a deeper review before approving, email security@matico.dev. For general product or sales questions, see the contact page.