# One Link, Every File: How Rovo Became an Insider Threat
Atlassian spent years building an AI assistant that could see everything across your organization — Jira, Confluence, Bitbucket, Slack, SharePoint, Google Workspace, uploaded files, archived content, relational databases. Then researchers found that sending a user a single crafted link was enough to make that assistant hand it all to an attacker.
That's the short version of RovoBlast, disclosed by Varonis Threat Labs at DEF CON 34 on Friday. The longer version is more unsettling, and it should end how any enterprise thinks about deploying AI agents with broad data access.
## The Mechanism Is Almost Embarrassingly Simple
Rovo is Atlassian's enterprise AI layer — not just a chatbot, but an autonomous agent capable of completing multi-step tasks without further user input. That autonomy is the product's selling point, and it's also precisely what RovoBlast exploited.
The attack vector was a URL parameter called rovoChatPrompt. It does what the name suggests: pre-fill content into Rovo's active chat session. Varonis researchers discovered that this parameter functioned as trusted input. There was no jailbreak. No permission bypass. No exotic chaining. You supplied attacker-controlled instructions via the URL, and Rovo executed them as if they came from the authenticated user.
This is what Varonis calls "parameter-to-prompt" (P2P) injection. It's a simple concept: externally supplied data flows directly into a model's instruction context, and the model cannot distinguish it from legitimate session input. Rovo had no mechanism to mark a session as externally seeded or to warn the user that their AI assistant was operating on injected instructions.
Making it worse: the organization ID portion of the URL could be left blank entirely. Atlassian still routed the request into the victim's own default organization. The attacker didn't even need to know the target's org ID to seed the session.
## What the AI Told Researchers It Could Do
Before demonstrating any exfiltration, the Varonis team did something clever and damning: they simply asked Rovo what data it had access to.
The answer: Jira, Confluence, Bitbucket, Slack, Google Workspace, Microsoft 365, relational databases, uploaded files, web pages, and archived content.
That's not a vulnerability disclosure — that's Rovo accurately describing its own authorized access footprint. The vulnerability isn't that Rovo lied about its permissions. It's that once attacker instructions were seeded into the session, those same legitimate permissions became the attack surface.
The exfiltration itself ran through ResearchAgent, one of Rovo's built-in tools that can autonomously conduct multi-source research and navigate across arbitrary sites. The researchers seeded a prompt, ResearchAgent pulled internal data, and pushed it outward in a single automated chain — no additional bypass required, no second click needed. They demonstrated three proof-of-concept scenarios: Confluence pages, Jira tickets, and SharePoint content with personal data.
## This Is Not a One-Off
Varonis disclosed a nearly identical attack against Microsoft Copilot in January, which they named Reprompt. Same class of vulnerability — externally supplied content seeded into an AI session, treating untrusted input as trusted instruction. Seven months later, Atlassian's flagship AI product had the same structural flaw.
That's not a coincidence, and it's not a Varonis specialty. This attack pattern exists because enterprise AI assistants are designed to be maximally helpful, which means they're architected to accept input from many sources and act on it quickly. Security review of those input pathways consistently lags behind the velocity of feature development.
The pattern also reflects something about how these products are being evaluated before deployment. Organizations run security assessments of the data Rovo can access, audit the OAuth scopes, and review the integration list. What they're not stress-testing is whether the AI's instruction context can be hijacked by a crafted link in a Slack message or an email.
## Atlassian's Response Deserves Scrutiny
Atlassian patched the issue before Varonis published, which is the right outcome. But the company's public statement is worth reading carefully:
*"For the vulnerability to be exploited, a user with access to a customer's Atlassian instance must provide untrusted content with a prompt injection to Rovo. This is a class of attack that affects AI systems across the industry. Similar to any phishing-type attack, we recommend customers follow security best practices."*
That framing is doing a lot of work. Calling RovoBlast "similar to any phishing-type attack" places responsibility on users to "verify that any content provided to their Atlassian apps comes from a trusted source." But phishing is a known social engineering vector with decades of user education behind it. Prompt injection via URL parameter is not something your legal team or finance department has been trained to recognize.
The comparison also obscures what made RovoBlast effective: there was no prompt injection in the traditional sense — no malicious document, no embedded invisible text. The attack surface was the product's own URL-based session seeding feature, which had no safeguards preventing external parties from using it.
## HackWire Analysis
RovoBlast is the second high-profile P2P injection against a major enterprise AI assistant in eight months. That's a trend, not an outlier, and the security industry needs to treat it as one.
What makes this category of attack particularly dangerous is the deployment context. Rovo is sold to organizations that have already decided to give their AI assistant privileged access to everything — that's the value proposition. The entire security model of these tools assumes the AI will only act on legitimate user intent. Once that assumption breaks, all those OAuth grants and integration permissions become the attack's payload delivery system.
There's a deeper architectural problem here that a patch doesn't solve: enterprise AI agents are being designed as maximally capable insiders without the corresponding insider threat controls. You wouldn't give a new employee unfettered access to legal, HR, finance, and engineering documentation on day one. But Rovo's default integration model does exactly that, with the added wrinkle that its instructions can be externally hijacked.
Varonis's remediation guidance — limit integrations, wall off sensitive departments, disable unused autonomous features, monitor activity logs — is sound and worth following immediately. But it's also a workaround for a product that shipped without meaningful trust boundaries on its instruction context.
The enterprise AI assistant market is moving fast. Microsoft, Atlassian, Salesforce, ServiceNow, and a dozen others are racing to embed autonomous agents into core business workflows. RovoBlast is an early signal of what happens when the security review process can't keep pace. Defenders should expect more of these, and they should be looking at their AI assistant integrations the same way they look at overprivileged service accounts: with skepticism, strict scoping, and active monitoring.
The next RovoBlast probably won't be called RovoBlast.
— HackWire Editorial
---
## Related Coverage