Hi everyone,
More Forge apps are starting to read the Teamwork Graph and to ship their own Rovo agents, and the approval request for one of them lands on an admin's desk looking much like any other app. It isn't quite the same, though, so I'd like to go through what such an app asks for, what it can actually see, how its agent actions behave, and which limits you'll run into, and then share the checks I make before I approve one. I've linked each Atlassian page so you can read the exact wording yourself.
What the app asks for, and who approves it
A Teamwork Graph app asks for scopes in the pattern read:graph:<object>:<product>, one for each kind of object it wants to read, and the Teamwork Graph scopes page states that "All Teamwork Graph API scopes are read-only", so the graph itself can't be written to through this API. Who has to approve them is where the docs don't agree with each other. The limitations page says installing apps with these scopes "requires organization administrator permissions", while the scopes page has "The site admin grants that scope when they install or configure your app." I couldn't settle that from the docs, so my advice is to plan for the org admin to be involved and to test it on your own org before a rollout.
Scope changes later on are handled by versions. Atlassian's Forge versions page explains that changes needing consent, such as scopes, "result in a major version change", and that a new major version "won’t be applied to a site until its admin consents to the upgrade." Minor versions are different, because Forge "automatically updates all installed apps to the latest minor version of their major version (without requiring admin consent)." By default, then, a new graph scope comes back to you for approval, while code changes inside the scopes you've already granted reach your site without asking. One exception is an app on Atlassian's Rolling releases, which can roll out its new code before you approve, though it keeps the scopes you already approved until you do.
What the app can see
The reassuring part is that graph calls run as the person using the app. The curated queries page puts it as "Every row returned is permission-filtered for the authenticated user", and the requestTeamworkGraph reference adds that "Forge apps can't call the Teamwork Graph API as the app." In other words, a user only gets back what they could already see in Jira or Confluence.
You can also narrow what the app reads after it's installed. According to the scopes page, under Connected Apps, then your app, then Permissions, admins "can toggle individual scopes on or off", and the change takes about a minute to show up in results. A switched-off scope doesn't produce an error, though, because "the rows that would have contained it are not returned". If you turn a scope off and a user later tells you the app looks empty, that's the first place I'd look.
What happens when a Rovo agent acts
Atlassian's page on adding tools to Rovo agents describes it this way: "The agent will respond asking for confirmation before executing consequential tools that may mutate data across systems." The same page adds that "Tools and skills always respect the permissions of the person using the agent", and that this applies to third-party tools too. For a Forge app, though, it's the developer's code that has to make that true. Forge lets a developer call Jira or Confluence either as the user or as the app, and the Forge shared responsibility model puts it on them: "You must use asUser() whenever you are performing an operation on behalf of a user." So I'd still ask the vendor directly whether their agent actions write as the user or as the app, and I'd want that answer in writing.
The limits you'll run into
The API went into Preview on 15 October 2026, according to the changelog, and the curated queries page promises breaking changes "a minimum 1-month deprecation notice". It's only available for apps installed into Jira or Confluence, and a curated query returns at most 25 rows a page. On the Rovo side, the Rovo action module can handle data "up to 5 MB", and the Forge invocation limits give an action 55 seconds to run.
I'd raise usage with whoever owns your budget. The How Rovo credits work page explains that Rovo credits come with paid Jira, Confluence, Service Collection and Teamwork Collection cloud subscriptions, and that credit usage depends on interactions with AI features "and the Teamwork Graph API". It also says extra usage billing takes effect on 3 December 2026, that it's "enabled by default", and that admins can set spending limits.
If you'd like to see how this behaves in practice, a colleague built one on our test sites and wrote it up. For transparency, I work at LeanZero, and the write-up is on our site, with a section of behaviours they measured. They paged 25 rows at a time and saw rows keep coming back for a while after they removed a scope, which may be the documented minute at work. They also found that a call which hit a rate limit could come back with zero rows instead of an error. In Rovo chat, an action's payload arrived intact only up to about 1 MB, and Rovo gave up on an attempt after about 20 seconds, well below the documented 5 MB and 55 seconds. Those are their own measurements on their own test sites rather than published Atlassian limits, and I couldn't find a documented rate limit for these queries.
What I check before approving one
First, I read the requested read:graph scopes and ask whether each one matches what the app says it does, since every new scope later comes back to me as a major version anyway.
Second, I ask the vendor whether their agent actions write as the user or as the app, and how they check permissions when they do write as the app.
Third, I plan for agents arriving without a prompt. Atlassian's Marketplace agents page explains that if an installed app's creator adds agent capabilities, "the agent will be added to your site without any additional requirements from you." The same page says an installed app's agent is listed under Apps and in the agent directory, so that's where I'd look after a vendor update. I don't reach for AI and Rovo, then Access, for this, because the Rovo access page lists Atlassian's own apps there, such as Jira and Confluence, so blocking one turns Rovo off for the whole product rather than for one vendor's agent. For a single Marketplace app, the levers I know of are the scope toggles above and the Marketplace and custom app access controls, which with Atlassian Guard Standard let you allow or block an eligible app on chosen spaces, though Atlassian notes that not every app is eligible. Past that, it comes down to whether the app stays installed.
Fourth, for apps our own developers build, I don't rely on app access rules to cover them early, because Atlassian's app access rule coverage summary lists Forge apps installed with the Forge CLI that haven't been shared yet as not covered.
I'm curious how others are handling this. When a Marketplace app adds a Rovo agent on your site, do you find out from the vendor first, or from your users once it's already there?
