Enhancement for Rovo for Teams add-in

Question

Hi all,

We're using the Rovo for Microsoft Teams add-in and want to know whether the following is supported, planned, or possible through a workaround.

What we're trying to do

We want to connect several service accounts to Rovo agents in Teams, each tied to a specific scope such as IT support, HR policies, or a project team. Each agent should only be able to see the Jira projects and Confluence spaces that match its job.

Specific questions

* Service accounts for agents.

Can service accounts be connected to specific agents?

Can several service accounts be used separately within the Teams add-in?

Right now, the service account connected to the add-in can see too much and will return unscoped data when asked.
* Scoped access.

Can each agent or service account be limited to specific Confluence spaces and Jira projects, so it can't find or show anything outside that scope?
* Knowledge source controls.

If we connect a service account to an agent and set that agent's knowledge sources, is the agent strictly limited to those sources? Or can it still reach other content the service account has access to?
* Teams-specific behavior.

When someone chats with an agent in a Teams channel or group chat, whose permissions does it use: the person asking, or the service account?
* Admin controls.

Are there admin settings, audit logs, or policies to enforce and check these scopes across agents?

Why it matters

We want agents in shared Teams spaces to show only the information they're meant for, so anyone in the chat can safely ask questions without relying on each user's individual permissions. Separate, least-privilege identities for each agent would make this much easier to manage and audit.

Thanks!

Matthew Sinclair · Answer

I can't answer all of these but I can give a little bit of insight on access.

* A Service Account is just like an User Account - only difference is they are not billed (The Service Account) - this is also dependent on your current Plan in terms of what your Org is paying for.

https://support.atlassian.com/user-management/docs/understand-service-accounts/

You only get 5 to start with - after that you need Atlassian Guard Standard or an Enterprise Plan (it comes baked in at that level). Reach out to your Org Admin for details.
* Service Accounts can be scoped (Should be!) to specific Applications and Roles - and further more to Groups.
* Rovo is always scoped to the User/Actor its sending instructions too. If you can't see it - It can't see it. If you can see it - It can see it. Then there's whatever additional contexts you provide. (Rabbit hole warning)
* Rovo is restricted by User/Account Access scope - and the Site wide allow list specified by the Org in terms of availability. It has to be turned on for the App you want it to relay info from. How that happens in Agent terms im a little fuzzy on details for me.
* Beta Test - Group Access lists are being explored - not much info to offer there.
* Future Tools - "Agent sprawl" is a major concern to Atlassian - we should be seeing more tools in our future. No ETA/details as of yet. Teams26 Might illuminate this!

Warning - Rovo and "Service Accounts" appear to not be a thing - this makes sense as Rovo's mandate is to always scope down to the Users Permissions at the time they interact. A combination of MCP/API use perhaps - but you may find this is currently not a thing for what you're doing. Way over my head expertise at the moment.

This may not provide all the pieces of the puzzle - but it may be enough to get you started.

Suggestion - Build something in the Sandbox and start experimentation - see what happens when you tie an Agent in for communication and run some tests. You will learn very quickly on what you can do.

This is something my Org will be researching very soon - after we're done putting some fires out (Not Atlassian related)

Anwesha Pan · Answer

Hi @Kaden Poland 👋🏻

To answer your questions:

1.Service Accounts for Agents

* Current Status: Not natively supported per agent.
* How it works: The Rovo for Microsoft Teams app connects at the tenant level. You cannot assign separate, individual Atlassian service accounts to distinct Rovo agents within the same Teams add-in.
* Workaround: If you require strict identity separation, configure dedicated custom integrations (e.g., via Azure Bot Framework or Teams webhook middleware calling specific Jira/Confluence API tokens) rather than the standard multi-agent Rovo Teams app.

2. Scoped Access (Limiting Jira Projects & Confluence Spaces)

* Agent-Level Knowledge Scoping: Supported via Agent Knowledge Configuration.

When creating or configuring a custom Rovo agent, you can explicitly define its Knowledge Sources (specific Confluence spaces/pages or Jira JQL queries).
* Hard Enforcement vs. Soft Scoping: Specifying knowledge sources focuses the agent’s retrieval on those spaces. To prevent it from falling back to general search across other spaces, include strict prompt boundaries (e.g., "Only answer using the provided knowledge sources; do not retrieve or reference projects outside X").

3. Knowledge Source Controls

* Is it strictly limited? Partially.* The agent prioritizes the explicitly attached knowledge sources.
* However, because Rovo operates on top of the broader Teamwork Graph, if an agent is equipped with general search tools, it can theoretically access other data permitted to the executing identity unless explicitly constrained in the agent instructions or if general search tools are disabled.

4. Teams-Specific Behavior (Whose Permissions Apply?)

* Permission Model: The Requesting User’s Permissions (User-Delegated).
* In Microsoft Teams, Rovo requires users to authenticate with their Atlassian account.
* When someone asks a question in a 1:1, group chat, or channel:* Rovo performs security trimming based on the individual user asking the question, not an elevated bot service account.
* If User A does not have access to a confidential Jira project or private Confluence space, the agent will not reveal that data to User A, even in a shared Teams channel.

5. Admin Controls & Governance

* Atlassian Admin Governance:* Agent Access Policies: Admins can manage agent discovery and restrict which users or groups can see and invoke specific custom agents.
* Approval Workflows: Enterprise governance policies can require security review (e.g., vetting data access scopes) before an agent is enabled org-wide.

* Audit Logging: Atlassian Guard / Org Admin audit logs track agent creation, modifications, and access changes.
* Teams Admin Center: Teams administrators can use App Permission Policies to control which specific Teams channels, security groups, or departments have access to install and interact with the Rovo app.

I hope this answers your question. 🙂

Thanks,

Anwesha