Two ways to connect Jira to ChatGPT for our product team
A product manager asks for Jira inside ChatGPT, and IT gets a week to answer. There are two ways to connect Jira to ChatGPT for our product team. The difference is who holds the rules.
The first is Atlassian's own route. OpenAI added the Atlassian Rovo MCP connector to ChatGPT on 3 December 2025. OpenAI documents it for Enterprise, Edu, Business, Pro and Plus workspaces with connectors enabled (OpenAI, ChatGPT Enterprise and Edu release notes, checked October 2026). MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Atlassian builds and runs that server, and Atlassian's admin settings decide what it may do.
The second is one governed endpoint in front of Jira and everything else the team touches. Elaichi serves MCP at one address, https://api.elaichi.ai/mcp, the same string for every organization. Jira is one connector in a catalog of 650+ connectors, with its own Jira connector page. The setup is a one-time admin step plus a sign-in per person, covered in adding Elaichi to ChatGPT.
When Atlassian's own connector is enough
If Jira is the only system the product team needs in ChatGPT, stop at Atlassian's route. It adds no second vendor. Atlassian says every action through its MCP server respects the user's existing access controls (Atlassian, Rovo MCP Server, checked October 2026).
The controls are real. Organization admins manage the server under Atlassian Administration, then Rovo, then Rovo MCP server. They grant or revoke access per permission group, such as read, write and search. Per-product detail sits behind Edit details (Atlassian, Control Atlassian MCP server settings, checked October 2026). Two Jira permission groups, delete_jira and manage_jira, are off by default and need an admin to enable them. Atlassian records an event in the organization's audit log each time a tool is used through the server (Atlassian MCP server repository, checked October 2026).
Two things to check before planning around it. Atlassian's default list of supported client domains is allowed or blocked as one list. Atlassian says individual domains on it are not blockable one by one. chatgpt.com, claude.ai and claude.com all sit on that default list (Atlassian, Available Atlassian MCP server domains, checked October 2026). The server also has site-level hourly call limits by plan. Atlassian lists 500 calls per hour on Free and 1,000 on Standard. Premium and Enterprise get 1,000 plus 20 per user, up to 10,000 per hour (Atlassian, Rovo MCP, checked October 2026).
The case for one endpoint starts when the list grows past Jira. A product team that also wants Notion, Slack and a dashboard ends up with four vendors' consent screens, four permission models and four audit logs. That is the problem an MCP control plane exists to collapse.
The failure this playbook is written against
The failure is not ChatGPT reading too much Jira. It is ChatGPT changing Jira: closing or deleting issues during a tidy-up, or editing a project's configuration while answering a question about it.
ChatGPT's own app permission choices do not fix that for a gateway. A plugin settings page on ChatGPT Pro, checked October 2026, offered Always ask and Allow read-only tools. It also offered Allow low-risk tools by default and Allow all tools. OpenAI documents the same family of settings (OpenAI, Managing app permissions in ChatGPT, checked October 2026). Elaichi never lists connected tools one by one, however few there are. A client finds them with search_tools and runs them with execute_tool. Elaichi annotates execute_tool as destructive rather than read-only, because the tool it runs is not knowable before the call. So a setting that lets read-only tools run unprompted still prompts on every Jira call, reads included. It never makes Jira read-only.
Elaichi's own consent screen does not do it either. "Run your connected tools" covers every tier of connected tool, deletes included. No checkbox holds a client to reading a connected app. That leaves two places to make Jira read-ish: the toolboxes the person picks at consent, or a restriction on their role. The restriction is the durable one.
The three restrictions to write for the product role
In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So the first move is to give the product team a role of its own. Write the rules on that role.
Read the Jira connector's tool list before writing anything. The console returns every tool on a connector you can read. Each one is flagged with whether it is restricted for you and why. Elaichi looks each named connector and tool up in the organization's catalog when a rule is saved. A name it cannot find fails the save, rather than quietly doing nothing.
One: block the deletes. Write a block rule on the product role naming Jira's delete tools. A block rule matches a tool by its name or by the operation it performs. Renaming a tool later cannot slip it past the block. Allow rules work the other way round and match only the pinned operation, which is why a block catches a rename and an allow does not.
Two: block project configuration. The tools that change a project's own setup rather than its issues belong with whoever administers Jira. Put them in the same rule or a second one. A single rule can name whole connectors and single tools, up to 1,000 of each.
Three: decide about writes out loud. A layer with only block rules has no allowlist. Every write tool you did not name stays reachable. If the product team should only read and comment, there are two shapes. The first is block rules naming every tool on Jira that is not a read, which you re-check when the connector gains tools. The second is an allow rule naming the read tools. That turns the whole layer into an allowlist across all connectors, so the role then needs whole-connector allow rules for every other app it uses. Watch the edge case: an allow rule that names nothing blocks everything for its target.
Writing or editing restrictions needs the restriction:manage permission plus the restrictions feature, which Gold and Black both include. A rule aimed at one member also needs restriction:override. A role or restriction change takes about two minutes to reach every surface.
A blocked tool is not hidden from the person. It still appears in the client's tool search by name, flagged restricted, with no schema and no way to call it. The refusal says whether the block comes from their role or their own account. From the chat they can file an access request for an admin to decide in the console.
Whose Jira account the calls run on
Every call through a connection uses that connection's own credential, whoever makes the call. A Jira connection that one person shares with the team acts in Jira as its owner. Jira's own permissions apply to that single account.
If each product manager should have their own Jira reach, each of them connects Jira themselves. The repeatable way is a template. Build the tool list once and share the template at use. Each person then stamps their own toolbox, picking their own Jira connection for each app as they go. Sharing one finished toolbox with the team does the opposite, because a stored toolbox's entries only ever run on the connections pinned in them. There is more on that split in AI agents with employee permissions.
The audit query that proves the restrictions hold
In Elaichi's audit log, search jira, set the date range, and filter the category to Assistant. Connected-tool calls are recorded as assistant.toolbox_tool and sit in the assistant category, ChatGPT's calls included. The MCP category holds grant events such as a client connecting, not tool calls.
Each row carries the person, the tool's advertised and catalog names, the connector and the connection the call actually reached. It also carries the toolbox, the tool's classification, how approval was given, the surface, the MCP client's id, the outcome and what the call touched. Over the API the same view is GET /audit-log, newest first, 50 per page and at most 200. It filters on free text, category, actor, action kind and a start time. The console exports the current view as CSV, up to 10,000 entries. An MCP client reads it with elaichi__audit__list. That operation takes a page size, a cursor and a connection id, and cannot filter by actor or action.
Two honest limits. A call that a restriction refused writes no audit row, because the refusal happens before any executor runs. Absence in the log is the only trace of a working block. Elaichi also keeps 90 days of audit history. For a longer trail you forward it to your own log service, and export to your own Datadog comes with the Black plan, which is launching soon.
So prove the two halves differently. Have one person on the product role ask ChatGPT to run a blocked Jira tool, and read the refusal, which names role or account. Then prove the allowed half from the log. Filter to that person, read the Jira rows, and check that every classification is one you meant to allow. What an AI audit log must capture goes field by field. Reading the whole organization's log needs audit:view, held by Org Owner, Org Admin and Auditor. Auditor is a free seat, so adding a compliance reviewer adds no billable seat.
The first two weeks
Order matters. Create the product role, write the rules, have one person connect ChatGPT and test, then invite the rest.
Then watch three things. Which Jira tools actually get called, because the ones nobody calls can come out of the toolbox. How often access requests arrive for the same tool, which usually means the role is one tool short. And whether anyone is reaching Jira by a second path. That could be a personal MCP server on a laptop or a direct vendor connector, and either sits outside the rules you just wrote.
If after two weeks the team only ever reads two Jira tools, pin those into a toolbox. Have people pick that toolbox at consent, so the rest of the catalog stays out of the conversation. The same shape, aimed at engineers rather than product, is in the Cursor and Jira rollout. The choice between naming tools and naming apps is in per-tool versus per-app restrictions. The full list of apps is in the connector catalog.
