Your Rovo agents are allowed to send and permanently delete email. That default is yours to change.

[#1]

Last Friday the Forge changelog moved the rovo:mcp module from EAP to Preview: installed apps can now expose their actions as tools you add to custom agents in Rovo Studio, appearing under Connected Apps. Most coverage will file that under developer news. I read it as an admin question, because it means an app install can extend what agents in your org are able to do.

So I spent this morning in Rovo Studio on a live Enterprise org, clicking every gate I could find. What I found is worth ten minutes of any admin's time: two paths sit side by side in the same dialog with completely different levels of ceremony, and the control that governs the quieter one lives somewhere almost nobody would look.

Observed in-product on 18 August 2026, one org, Enterprise plan. Documentation quoted below was read the same day. Your site may differ, and checking yours is rather the point.

1. The vocabulary has already drifted 📖

The changelog says the module exposes tools. The product calls them Skills. If you followed the workflow editor renames, you know the pattern: docs and interface speaking different dialects while the admin translates. Same thing, two words.

Open an agent, add skills, and the picker presents two lists that read as one:

• Connected apps: Azure DevOps, GitHub, GitLab, Google Workspace, Microsoft Teams, Outlook, Salesforce, SharePoint, Slack, and more.
• MCP (Model Context Protocol): external servers, each entry labelled read-only.

One list carries a capability label. The other does not. Hold that thought.

2. The skills that write 🖊️

Select Salesforce (example) and read the catalogue: Create sales opportunity. Create contact. Create sales case. Create task. Execute Salesforce Query. Elsewhere in the same picker: add a comment to a Confluence page, add a user to a Slack channel, add reviewers to a pull request.

These are not read-only. They write into systems outside Atlassian.

I selected one and added it. Nothing asked me anything at build time: no scope screen, no consent step, no summary of what the agent could now do in another company's system of record. One click, skill added. (The runtime is different, and to its credit: the person triggering the agent authenticates before an action runs, as section 4 shows. But nobody building the agent is told any of that here.)

Two honest qualifications. The skill still runs against a connection that already exists, and Atlassian's model is that an agent acts with the permissions of the person who triggers it. So this is not an escape hatch around access control. But build time is when a governance conversation is cheap, and at build time nothing was said.

3. The MCP door has a doorman 🛡️

Now click the plus beside MCP, and the ceremony is completely different. Before anything else, a page titled "Before you add an external MCP server" which states, in the product's own words: installing the source may authorize Atlassian to access sensitive data; you must be an Atlassian organization admin with an account on that server; Atlassian will respect permissions so users only see what they already can; and installing a server also publishes any out-of-the-box third-party MCP agents for it to your whole organization. Then a beta acknowledgment you must expand and accept.

Next, server selection (a curated list plus Custom MCP server), then configuration requiring a public HTTPS URL, streamable HTTP transport, and OAuth 2.1 with authorization_code grant plus Dynamic Client Registration, with users authenticating their own account when first invoking a tool. Beneath it, plainly: Atlassian does not guarantee any third-party MCP server, and you are responsible for reviewing it.

That is a well-built door. Admin-gated, consent-gated, per-user authentication, honest about liability. Ten centimetres to its left, a write-capable Salesforce skill goes in with one click.

Same panel. Two governance models.

4. The screen almost nobody has opened 🔌

Here is where this stops being a complaint and becomes useful, because the control exists, it is more granular than I expected, and it is nowhere near Rovo.

Go to Atlassian Admin, Apps, Sites, Connected Apps, open any connected app, and select the Actions tab. The page explains the model in its own words: these are actions taken from Atlassian apps "using Rovo, automation rules, and Agent Studio," people "are asked to authenticate before actions can run, and they only see data they already have permission to access in this app," and, crucially, "As an admin, you can activate or deactivate these actions for people in your organization."

That is a per-action switchboard, one row per capability, and it answers the runtime question honestly: for connected apps, the acting identity is the authenticating user, not a shared robot.

Now the part worth sitting with. On my site, opening Microsoft Outlook Mail, every action was ticked. Among them: Send email. Reply to email. Move email to folder. Create Teams meeting. Delete contact (the description says permanently, cannot be undone). Delete task list (cannot be undone). Delete email, whose own description reads: permanently delete an Outlook email, this action cannot be undone, and if you meant to move it to Deleted Items, use the move action instead.

Nothing is broken here. Atlassian built a granular, documented, admin-owned control surface, and the runtime model is sound. But the defaults are permissive, and the screen lives under Apps rather than under Rovo, which is not where anyone hunting for agent settings would think to look. There is also a broader lever, documented separately and which I have not screenshotted here: an Org Admin can globally disable default third-party actions for a site from Connected Apps settings, where the documentation defines a third-party action as one that "interacts directly with a non-Atlassian service" (its examples: sending email through a connected Gmail account, creating documents in a connected third-party workspace). Note the requirement: Org Admin, not site admin.

So the honest summary of the whole picture: the gate is not absent, it is upstream and pre-approved. Someone decided, probably by default, that agents may send and delete email in your organization. If that someone was not you, this is the screen where you become that someone.

One note on ownership, because admins should not carry this alone: which third-party actions your organization permits is a data-sharing decision, not a tooling preference. It belongs with whoever owns third-party data-sharing policy, security, risk or legal depending on your structure. Your job is to show them this screen and record the answer.

5. Who is allowed to build all of this 👥

This is where I had to correct my own assumptions, so what follows is quoted from Atlassian's documentation rather than observed on my site. In the new Studio experience, app admins in Jira, JSM or Confluence were also granted app admin in Studio, and Studio app admins "receive full creation permissions within Studio." The doc then says the quiet part out loud: "This means someone can create agents even if an organization admin has previously restricted their permissions to create agents in other products." Defaults differ by artifact too: automations and apps are open to all Studio users, while agents keep your existing configuration. The control is Studio, then Studio settings, and if your org was upgraded into the new Studio, that screen deserves a fresh look rather than an assumption.

Per agent there is also a User access toggle (mine defaulted to open to all users on the site) and two collaborator roles: Manager, who can edit, delete and invite others, and Editor. Managers inviting Managers is how a small circle quietly widens. At org level, Manage default access for future agents decides what tomorrow's agents inherit.

6. Where the agent ends up 📡

The Surfaces tab is what I would show a security reviewer first. An agent can be activated in Rovo Chat, the editor, automation flows and Jira work items, then extended to the Rovo browser extension, Slack, a JSM portal and a help center.

Read that last pair again. The same object that gained a write-capable third-party skill can be placed on a customer-facing service desk surface. Every step is individually reasonable. End to end on defaults, the path runs: someone builds an agent, adds a writing skill with no prompt, leaves access open, and publishes it where customers are.

7. The fair counterweight ⚖️

This is not a product without oversight. In the same navigation sit Insights, Conversation review and Evaluation (marked New), and at org level Atlassian documents pages for managing agents, default access for future agents, external MCP tools, read-only MCP integrations, and the third-party action switch above. The MCP flow proves the company knows exactly what a serious gate looks like. The gap is not philosophy: it is that these controls are spread across Studio settings, Atlassian Admin under Apps, and per-agent screens, while the person clicking Add skills sees none of them.

Your ten minutes 📋

1. Atlassian Admin, Apps, Sites, Connected Apps. Open each connected app's Actions tab and read what is enabled. Turn off what your organization would not approve in writing, starting with anything whose description says cannot be undone. Then check Settings for the global default third-party actions switch (Org Admin required).
2. Studio, then Studio settings. Check who can create agents, automations and apps, especially if your org was upgraded into the new Studio.
3. Open one existing agent and read its Skills. Sort them mentally into read and write. Most admins have never looked.
4. Check User access on your most capable agents, and who holds Manager.
5. Check Surfaces for anything customer-facing. A portal or help center agent deserves a named owner.
6. Check Manage default access for future agents so tomorrow's agents inherit what you intended.
7. Confirm the audit trail: the acting identity is the authenticating user, so the evidence lives in that third-party system's own log. Check you can retrieve it before you need it.

If your site behaves differently, especially if your Connected apps flow does prompt for scopes, please say so in the comments 🙏 One org is one data point, and this surface is moving quickly.

Sources, all read 18 August 2026: the Atlassian developer changelog entry of 14 August moving rovo:mcp to Preview; How to disable third-party actions in Atlassian Admin; Use Rovo Studio in your organization; Manage who can create in Studio; Manage external MCP servers and Understand read-only MCP integrations; Manage default access for future agents; plus the in-product screens above.