Security concerns regarding Rovo Outlook Connector: Delegated Permissions & PoLP

[김도형]

Hello Atlassian Community,

I am an Atlassian Engineer at Open Source Consulting. Currently, I am working on integrating the Atlassian Rovo Outlook Connector for an enterprise environment, but our client's security team has raised critical concerns and blocked the integration.

I would appreciate any official guidance, documentation, or best practices regarding the following security issues:

1. Violation of the Principle of Least Privilege (PoLP)
The security team pointed out that granting the Mail.Read Application Permission in Microsoft Entra ID provides the app with read access to the entire organization's mailboxes (including sensitive departments like HR, Finance, and C-level). They consider this an excessive scope that violates PoLP.

Question: Does the Rovo Outlook Connector support Delegated Permissions so it only acts on behalf of the logged-in user?

Question: If Application Permission is strictly required by design, does Atlassian officially recommend using Microsoft Exchange's ApplicationAccessPolicy to restrict the app's access to a specific Mail-enabled Security Group?

2. Concerns about Generative AI & Sensitive Data Exposure
The security team is also concerned that because Rovo uses Generative AI, it might index or search beyond what a user would normally query, potentially exposing highly sensitive data that shouldn't be easily surfaced.

Question: How exactly does Rovo inherit and verify the user's M365 permissions during a search?

Question: Could you provide any official architecture documents or security whitepapers detailing how Rovo ensures data isolation and prevents unauthorized data access (No Data Ingestion) during AI processing?

Thank you in advance for your insights. Getting clarification on these specific points will greatly help us coordinate with the strict enterprise security policies.

Best regards,

[Peter_DevSamurai · Accepted solution]

Hi @김도형 , 

1) PoLP & Outlook Mail permissions

a) Does the Rovo Outlook Connector support Delegated Permissions?

• The official setup for the Outlook Mail connector uses Microsoft Graph Application permissions, including Mail.Read, Mail.ReadBasic.All, Domain.Read.All, User.Read.All, Group.Read.All, GroupMember.Read.All.

• Delegated permissions are not documented as a supported option for this connector today.

b) Is ApplicationAccessPolicy recommended to restrict Mail.Read?

• Atlassian doesn’t explicitly call out Exchange ApplicationAccessPolicy in their docs.

• What they do state for Outlook Mail is:

  • It’s a Direct connector that uses Outlook search.

  • Your email content (subject, body, etc) is never ingested or stored within Atlassian.

  • ->  Quoted: "Rovo will always respect permissions. Users will only ever see emails that they have sent or received."

• You can refer to: Connect Outlook Mail to Rovo

=> Application permissions are required as documented; further mailbox‑scoping with ApplicationAccessPolicy is something you can add on the Microsoft side if your security team wants additional PoLP controls.

2) Generative AI, permissions inheritance, and data exposure

a) How does Rovo respect M365 / source permissions?

• Rovo synchronizes and enforces source‑system permissions.
• Users only see content they already have access to in the underlying system.
• You can refer: Rovo data, privacy, usage guidelines

  • “Rovo synchronises with access controls and permission settings from connected third-party apps and your Atlassian apps. This helps ensure that users only see content they have access to.”

  • It “listens” for permission and deletion changes and updates its index accordingly.

b) For Outlook Mail specifically (same connector doc as above):

• “Rovo returns emails using Outlook Mail’s search capabilities.”

• “Your email content (subject, body, etc) is never ingested or stored within Atlassian.”

• “Users will only ever see emails that they have sent or received.”

c) Any security / architecture or “no data ingestion” documentation?

Relevant official docs you can share with the security team:

• Rovo data, privacy, and usage guidelines (permissions, indexing, data residency, SOC2/ISO27001) -> How Rovo respects existing permissions across M365 and Atlassian
  Rovo data, privacy, and usage guidelines

• Customer data is not used to train models (Rovo & Atlassian Intelligence) -> Outlook Mail is a Direct connector and does not ingest email content into Atlassian.
  Rovo and Atlassian Intelligence customer data is not used for AI model training

• Atlassian‑hosted LLMs (Cloud Enterprise): ensures no AI prompts/context leave Atlassian’s cloud boundary when enabled ->  customer data is not used to train AI models.
  Atlassian-hosted LLMs

• Atlassian Trust Center (overall security, compliance, architecture high‑level) -> on Cloud Enterprise, you can enable Atlassian‑hosted LLMs so data stays within Atlassian’s Cloud boundary.
  Trust Center

I hope the above answers are helpful for you :)

Bestest regards, 

Peter