How is Jira/Confluence data handled when using the Gamma MCP integration?

Question

I’m trying to understand the data-handling implications of the new Atlassian × Gamma integration, particularly for organizations where Jira and Confluence contain confidential or regulated information.

The integration is quite interesting from a productivity perspective — Gamma can use Jira and Confluence context to create presentations, and Atlassian describes this as being enabled through the Atlassian MCP Server and Teamwork Graph.

However, I’m looking for some clarification around what happens to the Atlassian data once it is passed to Gamma.

From the current Atlassian documentation, I understand that:

* The Gamma integration uses a third-party MCP server.
* Data may be sent from the Atlassian environment to the third-party MCP.
* Atlassian’s own data-handling commitments do not apply while that data is being processed or stored in the third-party environment.

This raises a few questions for me:

1. What exactly is sent to Gamma?

When a user asks Gamma to create a presentation based on Jira issues or Confluence pages, is the relevant Jira/Confluence content sent to Gamma in full, or is only the minimum required context/content transferred?

2. What does Gamma retain?

Does Atlassian have any visibility or contractual requirements around how long Gamma retains the Jira/Confluence content received through the MCP integration?

3. Is the data used for AI model training?

Does Gamma use any Jira/Confluence data received through the Atlassian MCP integration to train, fine-tune, or improve its models or services?

4. Does Atlassian Enterprise/ZDR coverage extend to this integration?

Atlassian's own Rovo documentation describes strong data-handling protections, including ZDR arrangements with its third-party LLM providers. Does any equivalent protection apply when data is sent to Gamma through the third-party MCP integration?

5. What should enterprise customers do with confidential data?

For an organization with sensitive IP, customer information, security information, or regulated data in Jira/Confluence, is the recommended approach to avoid using the Gamma integration for those projects/content areas, unless the organization has separately reviewed and approved Gamma's data-handling terms?

To clarify, I am not questioning the value of the integration — I think the use case is genuinely interesting. I am mainly trying to understand the security and data-governance boundary between Atlassian and Gamma before recommending this capability in an enterprise environment.

If someone from Atlassian or Gamma can point to the relevant documentation, contractual terms, security documentation, or data-flow documentation, that would be very helpful.

In particular, I would be interested in an official answer to:

What happens to Jira/Confluence data after it leaves Atlassian through the Gamma MCP integration, and what protections apply to that data while it is in Gamma's environment?

Sami Shaik · Answer

@Nagarajan Balasubramanian ,

@Matthew Sinclair is right that questions 2 and 3 are Gamma's to answer, and only their terms, security documentation and your own vendor review can answer them; nothing on the Atlassian side can tell you what a third party retains or trains on. But questions 1, 4 and 5 have an Atlassian-side answer, and that half is what an enterprise admin actually controls. Here it is, as of today.

1. What is sent. The Rovo MCP server is a proxy, not a model and not a store. Atlassian's own statement is that it "does not store or cache your Jira or Confluence content" and operates "within the permissions of the signed-in user and only accessing data they are allowed to see" (Atlassian MCP overview). So what leaves is whatever the client asks for and the user could read anyway: the search results and the fetched pages or work items that Gamma's tools request to build the deck, in full for each item fetched. Minimum-necessary is the client's behaviour, not the server's guarantee; if Gamma fetches a page, it gets the page.

4. Does ZDR extend to it. No. Atlassian's zero-data-retention arrangements are between Atlassian and the LLM providers behind Rovo. A third-party MCP client sits outside that boundary by definition; the data is transmitted under the Privacy Policy and DPA up to the point it leaves, and from there Gamma's terms govern. Your reading of the documentation is correct.

5. What to do about confidential content, which is the part nobody has written yet. Three controls, all in Atlassian Administration, and the third is new:

* Which tools can connect at all: Rovo → Rovo MCP server → Domains. Gamma connects only if its domain is allowed; if your org has turned off "Allow Atlassian supported domains" and allowlists explicitly, nothing reaches Gamma until you add it (control MCP server settings).
* What any tool can do: the Permissions tab on the same page governs read, write, search, delete and manage toolsets per org. A deck builder needs read and search; it does not need write, and it should not have it.
* Which content is in scope, by sensitivity: since 29 September, Data Security Policies have an Atlassian Rovo MCP server control (Security → Data protection → Data security policies), with org-wide defaults and overrides scoped by app, space and classification level (Rovo MCP changelog, 29 September). That is the answer to "avoid it for regulated projects": classify the regulated spaces and projects, then block MCP access for that classification, and the integration keeps working for everything else without anyone having to remember a rule.

So the enterprise posture is: allowlist Gamma deliberately rather than inheriting it; grant read and search only; classify what must never leave and exclude it at the policy layer; and run Gamma through the same vendor review as any SaaS that receives customer data, because for retention and training that review is the only answer there is. One caveat worth stating in your note to clients: the DSP control is days old, so verify its scope on your own org before relying on it, and do not assume it covers API-token connections the same way it covers OAuth ones until the documentation says so.

Arkadiusz Wroblewski · Answer

Hello

Gamma accessing Atlassian’s MCP server and Rovo calling Gamma’s MCP server are different flows.

For the Rovo partner agent, Atlassian’s guidelines explicitly exclude processing/storage in third-party environments from Atlassian’s data-handling commitments. You shouldn’t assume Rovo’s ZDR arrangements extend to Gamma.

your security/privacy team should review Gamma’s applicable terms and request written confirmation of those remaining details before approving this data flow.

Best,

Arek🤠

Nagarajan Balasubramanian · Answer

Thanks @Matthew Sinclair for your response.

Since I love Gamma, I want to clarify these areas before recommending to enterprise.