nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Getting MS-Teams transcripts with Rovo-Agents

Jan Pfeifer

Hello,

we would like to add some Microsoft Teams Skills to our Rovo Agents, specifically the "Get meeting transcript".

But we have some security concerns regarding the needed permissons. When connecting Rovo with Microsoft via the from Rovo provided link (where a Admin Request is created):

Is our whole company´s Teams then connected to Rovo, so all transcripts are exposed or just the available chats from the user chatting with the Agent?

King Regards

Jan

Accepted answers

Sami Shaik

Hello @Jan Pfeifer ,

@Jean Horn has given you the right runtime model, so let me add the layer your security team will actually ask about, because your question contains a distinction worth making explicit.

Consent scope and access scope are two different things, and the admin request is about the first. When your Microsoft admin approves that request, they grant the integration its capabilities at the tenant level, which is exactly what makes security reviews nervous, it reads as "the app can touch Teams." What bounds actual access at runtime is the layer Jean described: each user authenticates individually, and the agent retrieves only what that user's own Microsoft permissions reach. So the honest answer to "is our whole company's Teams connected": the capability is tenant-approved, the access is per-user. Both halves are true, and a security review should be shown both rather than either alone.

And you can shrink the blast radius at the capability layer too. The Microsoft-side prerequisite Jean mentioned (the application access policy for meeting artifacts) does not have to be tenant-wide: have your Entra admin confirm against current Microsoft documentation, but these policies can be granted to a specific set of users. Which means a clean rollout shape exists: scope the policy to a pilot security group first, run the integration for that group, widen when comfortable.

Finally, do not take any of this on faith, ours included: test it. After connecting, run a two-account check: user A attends a meeting, user B does not; have B ask the agent for that transcript. The expected result is a refusal, and that one screenshot will do more for your security sign-off than every documentation link in this thread combined. If B gets the transcript, stop the rollout and raise it with Atlassian support immediately.

Good question to ask before connecting rather than after, that instinct is the whole job.

All comments

Jean Horn

Hi Jan, welcome to the Atlassian Community! 👋

It is completely understandable to have security concerns when connecting third-party integrations with your company's communication tools, especially when dealing with sensitive data like meeting transcripts.

Quick Answer

No, your entire company's Teams transcripts will not be exposed to everyone. Rovo respects native Microsoft Teams permissions at runtime, meaning a user can only access transcripts that they already have permission to view within Teams.

How Rovo & Microsoft Teams Permissions Work

User-Level Permissions Standard:
- When someone interacts with a Rovo Agent using Microsoft Teams skills, Rovo acts on behalf of that specific user. It uses their personal Microsoft Teams access rights to retrieve information.
Mandatory Individual Authentication:
- In order to search or retrieve transcripts via Rovo, each individual user must authenticate their own Microsoft account with the Atlassian platform. Rovo does not index transcripts globally or bypass user access controls.
Who Can Access Transcripts?
- Only the meeting organizer and the invited participants (listed in the Outlook Calendar event) can query that specific transcript through Rovo.
Admin-Level Prerequisites:
- Transcripts are not automatically ingested by default. A Microsoft Administrator must explicitly configure an Application Access Policy in Azure/Entra ID to enable access. Even after this setup, access remains strictly individualized.

Important Notes & Requirements

Permissions & Setup Required:
Microsoft Azure/Entra ID Admin: Required to approve the initial integration request and configure the Application Access Policy.
Atlassian Organization Admin: Required to link Microsoft Teams to the Atlassian Teamwork Graph in Organization Administration > Settings > Integrations.

For full details on data boundaries, you can review the official Atlassian documentation:

Connect Microsoft Teams to Teamwork Graph

I hope this helps ease your team's security concerns! Please feel free to reply if you need any additional clarification on setting up Rovo Agents.

If this response answered your question, please consider marking it as "Accept Answer" to help other community members facing similar security queries!

Sami Shaik

Hello @Jan Pfeifer ,

@Jean Horn has given you the right runtime model, so let me add the layer your security team will actually ask about, because your question contains a distinction worth making explicit.

Good question to ask before connecting rather than after, that instinct is the whole job.

Jean Horn

Thank you for the contribution. 😉

Jan Pfeifer

Thank you very much. I think this brings some clarification and calmness to our IT departement.

I also think you are right that a test will return the best results, but besides the docu Link provided by Jean, is there many any other source to support your statement in any way?

In Jeans link "Teamwork Graph" got mentioned which seems to be again some new technology introduced into the pool?

Sorry for this question bombardement but we really want to make sure to check everything before trying something

BR
Jan

Sami Shaik

Hello @Jan Pfeifer , glad it brought some calm to the IT department, that is exactly what these threads are for 🙂 Two answers to your two questions.

On sources beyond Jean's link: yes, Atlassian documents the permission model in a few places, and they all say the same thing. The Teamwork Graph connector types page states that synced connectors "require an admin to set up within admin.atlassian.com, and sometimes also require end users to authenticate to ensure they only see content they already have access to." The Manage your Teamwork Graph connectors page states plainly: "The Teamwork Graph relies on and respects the permissions that are set in your third-party apps." And there is a dedicated page, linked from that second one, titled "How Teamwork Graph connector permissions are kept in sync," which is the one to hand your security team, since it explains the mechanism rather than just asserting the outcome.

On Teamwork Graph being new: it is new as a public thing, but not as a mechanism. It is Atlassian's internal data layer, the map of how work items, pages, people and connected-tool content relate to each other, and it has powered Rovo search and agents since Rovo launched. What changed in May this year (Team '26) is that Atlassian opened it up externally: MCP tools, a CLI, and Forge connectors that let you bring your own systems into it. So for your specific question, Teams transcripts flowing through a connector, the permission behaviour is the long-standing one, not a fresh experiment. The runtime still does a last-mile permission check against the source system before returning anything.

And your instinct to test before trusting is the right one. The two-account check I described above remains the fastest way to prove it on your own tenant rather than take any of our words for it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

agent

addon-microsoft-teams

ms-teams

teams

rovo-atlassian-intelligence

rovo

agents