A Practical Atlassian MCP Pilot for ChatGPT and Codex Administrators

Start an Atlassian MCP pilot with two boundaries in view: which users can connect and what the server can read, search, or change. Atlassian offers organization-level Read, Write, and Search controls, with choices by app, while actions remain subject to the authenticated user's Atlassian permissions. Name one Jira or Confluence workflow, use only the access it needs, and test the exact ChatGPT or Codex path before expanding. Treat these as controls to configure and inspect; evaluate answer quality and misuse risk separately. (Atlassian MCP permissions; Rovo MCP overview)

Atlassian and OpenAI announced an expanded partnership on October 6, 2026. Their announcement describes ChatGPT and Codex connecting to Atlassian work context and future agent workflows that could pick up work, run tests, and coordinate around human checkpoints. This guide concerns the current administrative decision for a bounded pilot. The proposed agent behaviors remain exploratory in the announcement, so they should not be prerequisites or assumed capabilities for a current configuration. (Atlassian announcement; OpenAI announcement)

Before opening the admin console, write one sentence that describes the trial's job. For example: “A product lead can ask ChatGPT to summarize a defined set of Jira issues and Confluence decisions, then verify the answer against the source pages.” Or: “A developer can use Codex to read an assigned Jira issue and related design decision while preparing a code change.” These are hypothetical pilot goals. They describe a question to test, not a claim that either workflow has been tested here.

View image detail

A person walks one of several winding paths toward a distant colleague.

Actual size

Choose Actual size to read the graphic closely.

A good pilot has one reader, one workflow, a known source set, and a reviewer who can tell when the output is incomplete. “Let teams explore AI with company data” is too broad to evaluate. It does not say which users connect, which Atlassian apps matter, what the assistant may do, or who decides whether the result is useful. The admin and workflow owner should name those things before enabling permissions. If they cannot say what a successful answer must cite or what action must stay with a human, they need a narrower trial question.

Also decide which product surface is in scope. Atlassian describes its MCP server in ChatGPT and Codex, as well as OpenAI model selection in Rovo Agents. This pilot plan applies to a user connecting ChatGPT or Codex to Atlassian through MCP. If the actual task belongs in Rovo, validate Rovo's own agent configuration instead of treating the two control surfaces as identical. Atlassian's guide lists four paths with different setup steps. A pilot must name which one it is using so reviewers can reproduce the result. (Atlassian OpenAI guide)

Atlassian's MCP permissions page describes organization-level Read, Write, and Search controls. Read governs whether the server can view and read Atlassian app data. Write governs whether it can create and modify data. Search governs whether it can search across Atlassian apps. The page says administrators can turn these permissions on or off, review status as allowed, blocked, or partially allowed, and use Edit details to choose app-specific settings. It identifies the Permissions tab under Connectors as the primary control point for the Atlassian MCP server. (Atlassian MCP permissions)

Those org controls are one layer. Atlassian's developer overview says the MCP server authorizes with OAuth 2.1 or, for headless use, an API token. It also says server actions respect the authenticated user's existing Atlassian permissions and do not grant access beyond those permissions. That means an administrator should think about both the server's permitted action classes and the identity's access in Jira, Confluence, Bitbucket, or another connected app. The organization permission toggle is not a substitute for a carefully selected account. Likewise, user permissions alone do not answer whether the organization should permit the server to write. (Atlassian Rovo MCP overview)

View image detail

A person carries a small bundle through two nested rings.

Actual size

Choose Actual size to read the graphic closely.

For a human-operated trial, first choose the exact client and host, then follow the current setup instructions for that route. Atlassian's OpenAI guide describes OAuth in its Codex setup instructions, while its CLI-versus-MCP FAQ recommends Atlassian MCP for IDE, web, or sandboxed hosts with PAT access, and Teamwork Graph CLI for terminal or CI/CD workflows and scriptable twg commands with OAuth. Because those sections describe the Codex routes differently, verify the active instructions for the selected host before connecting; do not assume one credential method applies to every route. The separate Rovo MCP overview documents OAuth 2.1 and API-token authentication for headless use, but that general MCP guidance should not replace checking the Codex-specific route. If a headless design is necessary, document the workload owner, storage and rotation process, and revocation path. Those are operating recommendations, not a claim that Atlassian supplies a full token lifecycle policy. (Atlassian OpenAI guide; Atlassian Rovo MCP overview)

The OpenAI side has a separate workspace and app lifecycle. The current Plugins path lets an authorized user add a custom MCP server, configure its endpoint and authentication, review the available tools, and acknowledge the risk warning. Developer Mode is not universally required for this path. Some workspaces may still use the documented Apps/Create flow, which includes scanning tools and creating a draft before an administrator or owner publishes it. Who can create and test apps depends on the plan and workspace controls; Enterprise and Edu can use RBAC to grant selected members access. None of these ChatGPT settings replaces Atlassian organization permissions. Test both sides together, because a blocked operation can result from either workspace policy or Atlassian policy. (OpenAI Help Center)

A read-first pilot is easier to evaluate because it asks whether the assistant can retrieve and explain the expected records before the team permits edits. For the general question of how to scope MCP tools before sharing them, see Rise’s ChatGPT plugin access guide; the steps below focus on Atlassian’s organization-level permissions and app settings. That does not mean reading is risk-free. A user may already have access to sensitive projects, and the assistant may bring material into a context where it is easier to copy or summarize. The admin should identify the test account's Atlassian memberships and use a defined sample of records appropriate for the workflow. If the work requires searching across multiple apps, enable only the app permissions the test needs and confirm the team has reviewed what those sources contain.

Atlassian's settings let an admin inspect Read, Write, and Search separately and use Edit details to adjust by app. A useful initial design might allow Read and Search for Jira and Confluence while leaving Write blocked, if that matches the current console and the pilot's purpose. This is an example of a proposed configuration, not a universal default or a verified UI recipe for every tenant. Before saving, the administrator should inspect the actual list of permissions in the tenant and confirm which permission types map to the selected toolsets. (Atlassian MCP permissions)

Do not equate “read-only” with “safe enough for every data class.” Search may retrieve or reveal information beyond the few records an operator expects to inspect if the test identity can reach a broad organization. The important boundary is not just whether the action changes a record. It is also what context becomes available, where the assistant displays it, and who can access that conversation. An administrator should choose a test identity whose existing Atlassian permissions already fit the intended scope. If there is no clean way to limit that identity to the pilot material, choose a different test set or postpone the connection.

One detail in Atlassian's permissions guide deserves a deliberate decision: “Apply to future additions.” Atlassian says allowing an intent can automatically grant that access to new permissions that request the same permission. New permissions then do not require manual admin review and become available to users as they are added. The page describes a similar option when an admin adjusts permissions by app. This can reduce repetitive review, but it also changes how future tool additions enter the boundary. (Atlassian MCP permissions)

View image detail

An overhead figure reaches toward a new branch in a winding route.

Actual size

Choose Actual size to read the graphic closely.

For a narrow pilot, the administrator should inspect whether the setting is enabled for each permission being considered. If the goal is to approve only today's defined toolsets, the admin should decide whether future additions should remain subject to review. The exact consequences depend on the current console setting and permission catalog, so the administrator should read the active option and confirmation state before saving. Do not assume that a permission that is narrow today will remain equally narrow if future tools inherit it automatically.

Write this choice into the pilot record: which permissions were allowed, for which apps, whether new additions inherit those decisions, who approved the setting, and what change would trigger a fresh review. A simple note reduces ambiguity when another admin later sees an “Allowed” status but cannot remember whether it was a one-time decision or a standing policy. This record is a local governance practice proposed for the pilot, not a claim that Atlassian automatically creates that exact report.

Atlassian's OpenAI guide says the ChatGPT MCP path requires a Team or Enterprise plan with developer mode, access to the relevant Atlassian Cloud products, and any approval required by organizational policy. OpenAI's current Help Center lists custom MCP and full MCP support for Business and Enterprise/Edu on web, and says Pro can connect with read/fetch permissions. Its current Plugins path does not require Developer Mode first. The plan wording and setup routes differ between Atlassian's guide and OpenAI's help. Confirm the plan, available actions, setup route, and app controls in the tenant being tested instead of treating one summary as a universal eligibility rule. (Atlassian OpenAI guide; OpenAI Help Center)

On the current Plugins path, configure the MCP endpoint and authentication, review the available tools, and follow the workspace's risk acknowledgement before testing. Some organizations may still use the documented Apps/Create workflow: there, an authorized user configures the endpoint and authentication, scans the tools, creates a draft, and tests that draft before an admin or owner considers publication. For OAuth, check whether the provider must issue refresh tokens to maintain the connection. Confirm that the selected Atlassian authorization works in the actual workspace. This article does not authorize or instruct an administrator to publish an app broadly.

OpenAI also says ChatGPT can ask for confirmation based on app permissions and the action's context. That is an additional interaction control, not an organizational policy boundary by itself. Users may misunderstand what is being confirmed, and a confirmation dialog cannot verify that the selected issue is the right issue. Testers should know which actions are expected to prompt, what the target record should be, and how to cancel. If the workflow has no legitimate need to write during its first phase, keep Atlassian Write disabled rather than relying on a person to decline every write prompt. (OpenAI Help Center)

View image detail

A hand pauses over a blank slip between two possible targets inside a separate outer ring.

Actual size

Choose Actual size to read the graphic closely.

Stage one: map the intended path. Record the client (ChatGPT or Codex), Atlassian site, organization, app types in scope, test users, and one workflow. For a ChatGPT test, also record the ChatGPT workspace and app owner. For a Codex test, record where developers use the client and how they will review any code or work item result. Do not assume the partnership connection has one shared global setting that applies uniformly to every client.

Stage two: read the actual controls. In Atlassian Administration, open Connectors, choose the Atlassian MCP server, and inspect the Permissions tab. Review Read, Write, and Search as separate controls. Use Edit details if the pilot needs different app permissions, such as Jira versus Confluence. Check the future-additions behavior for every permission class. Save a screenshot or written configuration record according to the organization's policy. The vendor's support page provides these navigation steps, but labels can change; verify the live tenant rather than treating this article as a substitute for the console. (Atlassian MCP permissions)

Stage three: connect with an appropriate identity. Name the exact client, host, and Atlassian route before choosing credentials. Atlassian's guide describes OAuth in its Codex setup instructions; its CLI-versus-MCP FAQ recommends Atlassian MCP with PAT access for IDE, web, or sandboxed hosts, and Teamwork Graph CLI with OAuth for terminal or CI/CD work and scriptable twg commands. Check the live instructions for the chosen route because the guide's Codex setup and route-selection sections frame authentication differently. Record the route, host, authentication, and actions actually tested. Confirm that the user is in the intended Atlassian organization and has only the product access needed for the test. If a headless design is necessary, follow the selected route's documented method and assign credential ownership and a revocation plan before connecting. No live setup or commands are claimed. (Atlassian OpenAI guide; Atlassian Rovo MCP overview)

Stage four: run read tests with expected answers. Select a few test prompts that point to known Jira issues and Confluence pages. Include one prompt where the information is present, one where it is absent, and one where two sources disagree or have different dates. The reviewer should check whether the assistant found the expected records, cited or identified them clearly enough for verification, and acknowledged missing or conflicting evidence. These are proposed evaluation cases. Do not score the assistant only on fluency; a smooth answer that misses an important source is a failed test for a context-retrieval workflow.

View image detail

A reviewer stands over three sculpted bays: aligned forms, an empty cradle, and a mismatched pair.

Actual size

Choose Actual size to read the graphic closely.

Stage five: test a denied boundary. Ask for an Atlassian record the test identity should not be able to read or for an operation the organization has blocked. Record the actual response and verify it against the expected permission boundary. A denied response can demonstrate that a particular request was blocked in that test. It cannot prove every path is blocked, every prompt is harmless, or all data is inaccessible. If the response includes prohibited information or permits an unexpected action, stop the pilot and inspect the user identity, app settings, and organization permission state before continuing.

Stage six: make a written expansion decision. Only after the read tests meet the team's review criteria should an owner decide whether the workflow needs a write action. If it does, identify one specific task, target object type, reviewer, and acceptable result. Enable only the relevant write permissions and app scope that the current Atlassian controls support. Then test a harmless, reversible change in a designated space or project with the real reviewer present. Capture what was proposed, what was confirmed, what changed, and whether the record reflects the intended outcome. If the pilot cannot be isolated from production objects, do not improvise a test on a live record; keep the trial read-only or create an approved test area first.

A pilot should test the workflow, not try to manufacture an ROI claim. Track whether the assistant retrieved the expected source records, whether the answer preserved status and date distinctions, whether the reviewer found omissions, how much correction was needed, and whether the output could be used in the intended place. If actions are tested, track the exact object changed and whether the final state matched the reviewer-approved request. Keep duration and effort as observations from this sample, not as a generalized productivity claim.

The test set should include failure conditions. Search for a record that does not exist, ask about an out-of-scope project, and include a source conflict. The person reviewing the answer should be able to identify what the system cannot know from the connected sources. If the pilot only includes easy prompts with obvious answers, it may confirm connectivity but tell very little about whether the workflow is dependable enough to expand.

For every test, keep a compact evidence record: date, user role, client, enabled permission types, relevant Atlassian app, prompt, source record identifiers, observed response, reviewer correction, and final disposition. Avoid storing more sensitive content than necessary. Follow the organization's own retention and access policies for logs and screenshots. This is a suggested record format, not a built-in report format promised by Atlassian or OpenAI.

Set a stop condition before the first prompt. Examples include: unexpected access, a write operation during a read-only stage, inability to trace a claim to the source record, repeated confusion about which identity is connected, or the absence of an accountable reviewer. If any occurs, pause and document what happened. A pilot with a stop condition is more informative than one whose success definition is “the demo worked.”

View image detail

A hand lifts one bridge slab, leaving a gap before the source papers cross.

Actual size

Choose Actual size to read the graphic closely.

Turning on broad access to remove friction. Atlassian documents separate permission classes and app-level editing. Use those controls to fit the trial. A broad allowance may make the first demo simple but leaves the admin unable to tell which capability was actually necessary. Do not enable Write because a future phase might need it.

Treating user access as the whole policy. Atlassian says actions use the authenticated user's permissions. That is an important boundary, yet administrators still have organization-level controls for what the MCP server can read, write, and search. Verify both layers, and record the identity used during the test.

Approving future permissions by habit. If future additions inherit current permissions, a later tool or permission set may become available without a separate admin review. Decide whether that behavior matches the pilot's governance model and make the choice explicit. (Atlassian MCP permissions)

Assuming a connection means the whole product is ready. A guide can document a setup path while the account's plan, feature rollout, admin controls, or tool list differs. OpenAI's help and Atlassian's guide currently phrase availability differently. Recheck the target workspace and current app state. (Atlassian OpenAI guide; OpenAI Help Center)

Confusing a test with a security guarantee. A successful connection proves that a particular user, client, and request worked at that time. It does not establish that the connector is secure for all data, users, clients, or prompts. Atlassian and OpenAI documentation describes provider controls. An organization still has to evaluate its own threat model, data classification, policy, and usage.

Conflating today's connector with future agents. The October partnership announcement says the parties are designing or exploring deeper task assignment, test execution, session syncing, and multi-agent coordination. Until product documentation or a release makes a capability available, keep it outside the pilot's current operating procedure. (Atlassian; OpenAI)

When the trial ends, the administrator should be able to answer four questions without replaying the demo. What did the team enable? What did the identity permit? What did the test show? What is the next decision? Record the permission state, per-app choices, future-additions setting, connected client, test users, dates, and observed boundaries. Then state whether the organization will stop, repeat with narrower scope, expand to a second workflow, or consider a specific write action.

View image detail

Four tactile forms rest together in a carved niche beside one open path.

Actual size

Choose Actual size to read the graphic closely.

A result such as “read tests worked for a small, defined set of issues, but reviewers could not reliably detect missing context in cross-project questions” is more useful than “AI was helpful.” It names the scope and exposes the next question. A result like “the connector was blocked because Write remained off” may be an expected policy outcome, not a failure. The admin's task is to distinguish the decision the organization intended from a confusing setup or product issue.

If the team expands, it should do so through a new review of the next workflow rather than inheriting permission without thought. A pilot for reading release context does not establish the case for editing Confluence pages or transitioning Jira work. Each action changes the consequences of a mistake and may require a different reviewer. Atlassian's controls make those distinctions configurable, while the organization remains responsible for deciding what fits its policy.

A pilot is an experiment in configuration as well as usefulness. Before access is enabled, agree on who can turn it off, how a tester reports unexpected access, and how the team confirms that the connection has been removed or restricted after the trial. The exact revocation steps depend on the client's authentication and the current Atlassian and OpenAI controls, so the admin should follow their live documentation and tenant settings. The important operational point is that access has an owner and an end-of-test decision. An abandoned connection should not become a permanent exception simply because nobody remembers why it was enabled.

Set a review date while the pilot is being approved. At that review, compare the recorded configuration with the current permission page, inspect whether any new tool permissions appeared, and decide whether to renew, narrow, expand, or revoke. Atlassian's future-additions behavior makes this especially relevant: a setting that automatically grants newly added permissions can alter the effective scope after the first day. A periodic review does not guarantee that no change went unnoticed, but it gives the organization a defined point to revisit a choice whose consequences may evolve.

View image detail

An administrator compares an earlier carved route with a current route that has gained a branch.

Actual size

Choose Actual size to read the graphic closely.

Keep the record understandable to someone who did not configure the connector. Name the business workflow, the person accountable for its data, the administrator who approved the settings, and the reviewer who judged the outputs. If the pilot moves from a small test group to a broader user population, treat that as a new decision with its own evidence. A successful test by one knowledgeable user does not automatically establish that other users know how to spot errors or handle sensitive results.

For most teams evaluating ChatGPT or Codex with Atlassian context, begin with a named interactive user, a known Jira or Confluence workflow, and Read/Search permissions only where required. Confirm the identity's own Atlassian access, inspect app-specific settings, and check whether future permissions inherit approvals. Test expected, missing, conflicting, and denied cases. Keep Write disabled until a separately reviewed task requires it.

That approach does not guarantee safe or accurate output. It gives an administrator a concrete way to understand the current connection and decide whether a larger trial is justified. The OpenAI partnership announcement makes deeper agent work a plausible direction. A careful pilot still starts with the tools and controls the organization can inspect today.