Anomity Integrates with Atlassian and Rovo

Anomity now integrates with Atlassian, and covers Rovo from both sides. A new cloud connector reads your Atlassian organization: which products have generative AI switched on, how many Rovo agents have been created, who uses Rovo Chat, whether user content is contributed to AI, and the API keys and tokens the Rovo MCP domain allowlist does not apply to. On managed devices, the Endpoint Sensor now inventories Rovo Dev, the Teamwork Graph CLI and the Rovo browser extension. The integration is available today from Settings, under Integrations, in the Anomity console.

This post covers what the connector reads, the finding that reads like a contradiction until you see the mechanism, what changed on the endpoint, and what Atlassian does not expose.

Why Atlassian, and why now

Rovo is an agent platform now. An Atlassian admin console carries Rovo access, Rovo agents, a Rovo MCP server, Agent2Agent, Code context and Teamwork Graph connectors that index third-party content for Rovo to read. Our own coverage had not kept up: until this release, Anomity detected Rovo Dev only if a developer happened to have authored a skill for it, and saw nothing of the organization side at all.

Rovo also reads the content that matters most. Jira and Confluence hold the roadmap, the incident write-ups and the customer escalations, and an assistant that can search all of it is exactly the 'private data' leg of the lethal trifecta. That makes two questions worth answering for every product: is AI switched on here, and would anything record it if Rovo were used to pull data out?

What the connector reads

We scoped the connector by probing a live organization rather than by reading documentation. There is no Rovo inventory endpoint at any spelling we tried, and no Rovo scope on an organization API key. But Rovo is still governable through two scopes that do exist: policies, which carry generative AI activation per product, and the audit feed, which records Rovo agent creation and Rovo Chat use.

The finding that reads like a contradiction

Atlassian's Rovo MCP server lets an admin decide, by domain, which AI tools may reach the organization. It is a good control. It also has a boundary that Atlassian documents plainly: the domain allowlist applies only to tools that sign in with OAuth 2.1. A tool that authenticates with an API token does not use the domain allowlist at all, and is governed instead by the organization's IP allowlist and the scopes granted to the token.

So an admin can configure the allowlist carefully and still have a credential it does not cover. When an Atlassian API key or token holds write or delete scopes, Anomity raises a finding that names the credential and states both compensating controls, because an admin told only that a control does not apply has nothing to act on. In an organization with no IP allowlist, that credential is constrained by nothing but its own scopes. We stated this narrowly on purpose: it is a statement about the Rovo MCP domain allowlist, not a claim that Atlassian's data security policies stop working for tokens. Telling a customer that a control they configured does not work, when it does, is worse than not shipping the finding.

What it flags

Atlassian posture runs through Anomity's cloud AI posture policy type, with a template for Atlassian organization AI and credential posture.

• Write or delete scopes outside the domain allowlist. As above. No switch to turn it off.
• AI on, activity logging off. Generative AI is switched on for a product while user activity logging is off for the same site, so Rovo can read the content and there is no record of who asked for what. Raised only when Atlassian says logging is off, never inferred from silence. No switch either.
• User content contributed to Atlassian AI. Atlassian states that third-party model providers do not train on it, so this is about Atlassian's own use. Below the Enterprise plan it cannot be switched off, so the remedy is a plan decision, and the finding says so.
• Credential hygiene. Keys and tokens with no expiry, older than 90 days, unused for 90 days by their own last-activity date, or created by someone who is no longer an active member. The last one is raised only when the directory actually returned members, and a deactivated account counts as departed.
• Members outside your verified domains. Only verified domains count, so a lookalike domain cannot read as internal. An unverified domain is a note, since every member would otherwise look external.
• Off by default: generative AI switched on for a product (for an activation review), Rovo agents present, and data residency not pinned.
• Discovery gap. Anything Anomity should have been able to read but could not.

The external-member check is the same question, with the same wording, that Anomity asks of Claude Enterprise, and the credential checks use the same vocabulary as the Anthropic Console and OpenAI connectors. One question, answered once, across every AI tenant you connect.

On the endpoint and in the browser

The organization is half of Rovo. The other half runs on developer machines, and the Endpoint Sensor now covers it properly.

• Rovo Dev. Atlassian's terminal coding agent has no binary of its own; it runs as acli rovodev run, so its version comes from the Atlassian CLI. The sensor reads its configuration, its MCP server configuration (including the older default file name), its user memory file, and the project-scope MCP configuration used by Bitbucket Pipelines.
• Six autonomy settings. From Rovo Dev's configuration: the default tool permission (allow, ask or deny), the default for shell commands, whether shell commands run in a sandbox, how many paths outside the workspace the shell may reach (a count, never the paths), whether the built-in Atlassian MCP server is turned off, and whether prompt collection to Atlassian is on. They feed Anomity's existing autonomy and sandbox posture policies. A runtime 'yolo' switch leaves nothing on disk, so the configuration file is the only durable evidence.
• Teamwork Graph CLI. The CLI that indexes third-party content into the Teamwork Graph for Rovo. Its credential file stores OAuth credentials unencrypted by default, so the sensor proves the tool is installed and signed in by presence alone and never opens that file.
• Rovo browser extension. Detected on Chrome and Edge, which share one store listing. It can read and change data on every site you visit, so it is worth knowing where it is installed.
• Rovo MCP server recognised. Remote MCP servers can now be matched by host, so Atlassian's hosted Rovo MCP server is classified as official instead of tripping MCP vetting as an unknown server on every sync.

That last point matters for registries. An official vendor server and a community server for the same product are different risks: the community mcp-atlassian server has had its own serious issues, such as the HTTP auth bypass that fell back to global credentials. Telling them apart is the first step in building an MCP server registry.

One fix came out of this work that applies well beyond Atlassian. On macOS a Chrome profile is protected, and without Full Disk Access the sensor could not read it, which used to look exactly like a browser with no extensions. The sensor now tells 'not permitted to read' apart from 'empty' and records the profile as unreadable.

How setup works

1. In Atlassian Administration, go to Settings, API keys, and create an organization API key. Atlassian's key creator pre-selects every scope, including write and delete. Clear them and select read scopes only: organization, policies, events, directories, domains, keys and tokens.
2. In Anomity, add an Atlassian connector with your organization ID, which is in the admin.atlassian.com URL, and the key. A personal API token is refused before it is stored, with a message pointing at the right kind of key.
3. Test, then sync. Every call is a GET, and the key is stored encrypted.

Two notes on reach. The audit feed, which is where Rovo agents and Rovo Chat use appear, may need Atlassian Guard; several other reads are entitlement-gated too, and when the plan does not include them the organization row says so as a plan fact, not a gap. And Teamwork Graph connectors, Code context repositories, Rovo MCP server settings, Agent2Agent state and Rovo Studio agents have no public Atlassian API, so they are listed as not collected rather than implied to be governed.

How Anomity and Atlassian fit together

Atlassian owns the controls: Rovo activation, data security policies, the Rovo MCP domain allowlist, the IP allowlist and Atlassian Guard. Anomity reads whether they are in place and where a credential sits outside one of them. Atlassian is also a destination: the same findings can open issues through Anomity's Jira integration, so the team that owns the Atlassian organization gets its findings where it already works.

The connector sits next to the other places AI reaches company data, from OAuth grants in Google Workspace and GitHub, and GitLab Duo settings in GitLab, to the AI vendor tenants and the AI steps inside Zapier automations, and next to the identity side of MCP covered in our analysis of enterprise-managed MCP connectors. Around it, the Endpoint Sensor inventories agents, MCPs, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes; the Browser Sensor covers AI web services and the accounts used in them; and on agents that expose a hook, Anomity decides allow, deny or log before a tool call runs. Findings route to the SIEM, Slack or Jira. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see it against your own Atlassian organization and fleet, book a 30-minute demo.