.webp)
Atlassian Agents Enforce Your Permissions Exactly As You Wrote Them
There is a sentence in Atlassian’s documentation that reads like reassurance and behaves like a warning. Agents only surface data the authenticated user is already authorized to see. No new access is granted.
Atlassian repeats that promise consistently, and it is the right design decision. When Teamwork Graph tools arrived in the Rovo Model Context Protocol server, the documentation stated that those tools respect existing Atlassian permissions and that connecting an artificial intelligence client grants no additional access. The Teamwork Graph Command Line Interface documentation says the same thing in nearly the same words. Atlassian’s guidance on Teamwork Graph connectors adds the third-party half: the graph relies on and respects the permissions set in the applications it connects to. Access controls travel with the data instead of being reinvented at the artificial intelligence layer, which is architecturally correct and genuinely reassuring.
Now read the promise again and notice what it does not say. It says nothing about whether your permission model is correct. It guarantees faithful reproduction of every access decision your organization has accumulated since somebody created the first Jira project. If those decisions were sound, agents inherit sound boundaries. If your Confluence space permissions have drifted through six years and three reorganizations, agents inherit that too, with no editorial judgment and considerably more stamina.
Why identical permissions behave differently once an agent is holding them
Deploying agents changes nothing about who can see what. It changes how completely that access gets used.
A product manager with overly broad Confluence access has always been technically able to open the compensation planning space nobody remembered to restrict. In practice they never did. They did not know it existed, they would not have stumbled onto it, and reading forty thousand pages is not a realistic Tuesday. Latent over-permissioning has been protected for two decades by obscurity and effort.
An agent grounded in a context graph removes both protections. It does not browse, it retrieves. It does not need to know the space exists; it only needs the question to be relevant. And it will read all forty thousand pages in the time it takes to refill a coffee. The access was always there. The friction that made it harmless was never actually a control.
That is the sentence worth carrying into a leadership conversation. Agent adoption is not a new permissions risk. It is an existing permissions risk with the latency removed, which also makes it the most persuasive business case anyone has had in years for the access review that keeps getting deferred.
Five places Atlassian permissions quietly drift
None of this is exotic. It is the ordinary sediment of a platform that has been useful for a long time, and most of it accumulated for defensible reasons at the time.
Permission schemes that stopped being shared
A scheme gets created for one project, reused for eleven more because it was close enough, then modified for the twelfth. Now a grant that made sense for an internal tooling project applies to a project handling customer contracts. The most common offender is a browse grant given to Any logged-in user during a migration, when the priority was making sure nobody got locked out. That grant tends to outlive the migration by several years. The structural version of this problem is worth understanding alongside the governance and category model behind Jira spaces, because scheme sprawl and container sprawl feed each other.
Work item security levels nobody ever applied
Jira’s work item security schemes, renamed from issue security as Atlassian moved its terminology from issue to work item, are the only mechanism that hides an individual work item from someone who can otherwise browse the project. Plenty of organizations configure a scheme, apply it to a handful of items during one incident, and never revisit it. One query settles the question. Run Level is EMPTY in Jira Query Language against any project where you believe sensitive work is protected, and count what comes back. The number is usually larger than the person who configured the scheme expects.
Space permissions versus page restrictions in Confluence
These are two different mechanisms and they are routinely confused. Space permissions decide who gets in the room. Page restrictions decide who sees one document inside it. Teams that rely on page restrictions for confidentiality are protecting individual pages while leaving the space open, which works until content gets moved, copied, or summarized into a new page that inherits nothing. Personal spaces are the other blind spot: they are where sensitive drafts go to live permanently, and almost nobody audits them.
Groups you inherited from the identity provider
Nested groups synchronized from an identity provider are the most reliable source of accidental breadth in a large estate. Somebody adds the engineering group to a Confluence space, the engineering group contains contractors-all, and contractors-all was populated by a synchronization rule written by an administrator who left in 2023. Default product access groups do the same thing more quietly: every new user gets a membership that grants more than anyone intended, one hire at a time.
Content that is not yours
Once Rovo is reading Google Drive and SharePoint through Teamwork Graph connectors, an Atlassian access review is only half of the review. Atlassian is explicit that the graph respects the permissions configured in the third-party application, which means the weakest access model in your connected estate sets the floor for everything. The moment the Teamwork Graph opened to outside tools is the moment this stopped being an Atlassian-only question, and most organizations have not updated their review scope to match.
The controls that are new, and when they actually arrive
On September 10, 2026, Atlassian announced a set of governed agent capabilities across Jira and DX, including Agent Context Controls, which let platform teams govern which agents operate in a space and what those agents are permitted to see. Release state matters here. According to Atlassian’s availability note, Agent Context Controls are slated to become generally available to paid Jira customers in the coming months, Code Context is rolling out through open beta, and agent loops, Standards, and AI Review are in private early access. That is a roadmap, not a switch you can flip this week, and it is worth being precise about the difference. The operational prerequisites are covered in our look at the backlog hygiene agent loops actually run on.
Two things you can examine today rather than waiting. Atlassian Administration exposes permission categories for the Teamwork Graph Command Line Interface — read, write and manage, and delete — configurable per connected toolset, with Atlassian’s own guidance being to enable write and delete only for the toolsets an organization genuinely needs. Saving those changes also offers the option to revoke existing sessions, which matters when you are tightening rather than loosening. Administrators can similarly enable or disable the Rovo Model Context Protocol server. The pattern is the same one visible in the administrative lock that shipped alongside Trello’s artificial intelligence front door: the door and the lock arrive together, and the lock is reliably the less-demonstrated half.
Who should start now, and who can reasonably wait
Start now if any of these describe you: regulated or contractual data lives in Jira or Confluence; you have more than a few thousand users; your groups arrive from an identity provider with nesting you cannot draw on a whiteboard; you run a Jira Service Management portal with external customers; or you have told anyone that agents are on the 2027 plan.
You can reasonably wait if you run a single site under a few hundred users, have no third-party connectors attached, and your permissions were configured within the last eighteen months by people who still work there. Your exposure is genuinely small, and the review will be short whenever you get to it.
The encouraging part is the timing. The gap between now and general availability is the cheapest window this work will ever have. Permission cleanup requires no waitlist, no additional license, and no vendor.
The Avaratak Take
The interesting governance question is not whether agents respect permissions. Atlassian has answered that clearly, consistently, and correctly. The question is whether anyone in your organization can produce a defensible answer to “who can currently see this?” for the ten most sensitive spaces and projects you own, without convening a meeting.
In most estates of any age, that answer requires several people, a spreadsheet, and a week. That is not a criticism of the platform. It is what happens when a system is genuinely useful for a decade and permissions get granted by whoever was unblocking someone on a Friday afternoon. It was survivable when the only consumers were humans with limited attention. It is worth revisiting now that the consumers have neither limits nor attention spans.
Our recommendation is narrow. Assign one named owner to the permission model, the same way you would assign an owner to a production service. Put a date on a read-side review before you touch anything on the write side, because read exposure is what agents amplify first and it is the half you can fix without breaking anyone’s workflow. Scope the review to include connected third-party sources, not just Atlassian. And resist solving this with a purchase. Permissions drift is a governance problem wearing a technical costume, and no product fixes an access model that nobody owns.
The unglamorous version of agent readiness is a list of permission schemes, an inventory of spaces whose owners have left the company, and a Jira Query Language query that returns an uncomfortable number. None of it demonstrates well in a keynote. All of it determines whether the keynote demonstration is safe to run against your data.
If you are trying to work out what your own permission model would hand an agent on day one, Avaratak is happy to talk it through.