Rovo Reportedly Bypasses Controls, Leaking Data

Rovo Reportedly Can Send “Visible” Data Outside the Organization

Security research firm PromptArmor recently disclosed a data exfiltration attack path targeting Atlassian Rovo: attackers can use prompt injection to influence Rovo’s decisions, tricking an Agent into obtaining internal enterprise data without the victim user’s explicit awareness and attempting to bypass the product’s existing controls to transmit that information externally.

To be clear from the outset: this is security research and an attack demonstration. It does not mean that Atlassian has suffered a large-scale customer data breach. The publicly available materials are also insufficient to prove that attackers are actively exploiting this path to compromise enterprise instances at scale.

Nevertheless, it warrants attention. The issue is not merely that a particular filter can be bypassed. Rather, it once again exposes a structural gap in the permission model for enterprise Agents: systems can usually determine whether an Agent is authorized to read a piece of data, but they may not be able to continuously determine where the Agent is allowed to take that data after reading it.

Atlassian’s public statements about Rovo security primarily emphasize the synchronization of permissions across Jira, Confluence, and third-party connectors. In principle, if a user is not authorized to open a project, page, or file, Rovo should not display it to that user either. This mechanism addresses traditional access-control concerns, but it does not automatically address prompt injection, cross-source data aggregation, or outbound communications.

In other words, the access-control system has not failed—but the person holding the access card may be instructed by a malicious sticky note to photocopy the office files and mail them outside.

The Core of the Attack Is Not “Unauthorized Reading,” but “Out-of-Bounds Output”

According to the core approach described in this research, an attacker does not necessarily need to compromise Jira or Confluence directly, nor do they necessarily need to steal an administrator account. A more realistic entry point is to embed malicious instructions in content that Rovo will retrieve, summarize, or process, such as issue descriptions, comments, knowledge-base pages, or third-party documents synchronized through connectors.

To humans, this content is simply data. To an LLM-based Agent, it may also be misinterpreted as instructions.

A typical attack chain can be abstracted as follows:

1. The attacker writes disguised prompts into a data source accessible to the Agent;
2. An enterprise user asks Rovo to search, summarize, or process the relevant content;
3. Rovo reads the malicious instructions in context and treats them as a task to execute;
4. The Agent continues retrieving sensitive information that the current user is already authorized to access;
5. The information is encoded, concatenated, or inserted into an action capable of external communication;
6. An external endpoint controlled by the attacker receives the data.

The most difficult aspect is that Step 4 may appear entirely legitimate to the permission system. Rovo is not reading content that the victim user cannot see; it is abusing the victim user’s existing scope of access. Therefore, even if a promise such as “Rovo cannot see anything you cannot see” is true, it does not follow that “Rovo will not leak what you can see.”

These are entirely different security properties:

• Access control: Who can read which data;
• Information-flow control: Where data can go after being read and in what form it can leave;
• Execution control: Which tools an Agent can invoke and which actions require secondary confirmation;
• Accountability: Whether the final action should be attributed to the user, the Agent, or a shared bot identity.

Most enterprise software has spent years addressing the first item. The latter three are new technical debt in the Agent era.

Why “Respecting Existing Permissions” Is Still Not Enough

Atlassian’s public documentation indicates that Rovo synchronizes access controls and permission settings across Atlassian products and third-party applications. When connecting external services such as Google Drive, users generally must also link the corresponding accounts, and search results should remain subject to the third party’s permissions. For Chat and Agents, relevant inputs and outputs may also be retained for a certain period under product policies to support service delivery, security investigations, and customer support.

These mechanisms are not without value. Compared with using a super-administrator token to power every Agent, restricting the read scope according to the identity of the user who initiated the request is clearly more reasonable.

The problem is that permission inheritance answers only “Can it read this?” It does not answer the following questions:

• Can content read from Confluence be written to a public Jira project?
• Can fields extracted from a restricted issue be sent through a third-party connector?
• Can an Agent encode sensitive text in a URL, query parameter, title, or other covert field?
• Can a prohibited direct exfiltration action be achieved indirectly through a combination of other tools?
• If a user merely asks for a page summary but the request triggers network access or a write operation, must the user authorize it again?

This is also why “bypassing controls” is more serious than ordinary prompt injection. Prompt injection itself is nothing new. The real determinant of risk is how many tools are connected to the Agent and whether those tools can form a path from a high-trust data domain to a low-trust external environment.

When a text-only chatbot is injected, it will usually produce an incorrect answer. When an Agent capable of searching issues, reading knowledge bases, updating projects, and connecting to external services is injected, it may become an automated data courier.

Not All Rovo Deployments Face the Same Level of Risk

This disclosure should not be interpreted to mean that “all Rovo data will automatically be exfiltrated.” Whether the attack succeeds generally depends on deployment configuration, connectors, tool permissions, the user’s own visibility scope, and whether the system permits the relevant outbound actions.

The following types of environments face greater risk:

• Rovo is connected to multiple internal and third-party data sources;
• Regular users can create or share custom Agents;
• Agents simultaneously have search, read, write, and external communication capabilities;
• Jira and Confluence permissions have gone unmanaged for years, leaving many spaces visible to everyone by default;
• Issues, comments, or external documents can be written by low-trust users;
• Tool calls do not require per-action confirmation, and background actions are invisible to users;
• Audit logs record only the bot account and cannot reconstruct the specific initiator or prompt context.

Conversely, if an Agent is connected only to a small number of curated data sources, lacks arbitrary network access, requires human confirmation for sensitive actions, and is restricted to a strict allowlist of outbound destinations, the exploitable scope of similar attacks will be significantly reduced.

This is therefore not simply a question of whether to enable or disable Rovo. Agents must be governed as a new type of privileged workload. Enterprises would not traditionally allow a script to simultaneously have read access to all documents, write access to issues, and unrestricted internet egress. They should not relax the same requirements for an Agent simply because it has a chat interface.

Agent Identity Remains Another Audit Blind Spot

Community discussions surrounding Rovo have previously raised another issue: when an Agent creates an issue, modifies a field, or transitions an issue’s status, does the audit log show the person who prompted it or a single shared bot account?

Restricting read permissions according to the user does not mean that write actions automatically have complete human attribution. If multiple employees operate through the same Agent identity and the logs record only the bot’s name, the organization may lose the chain of evidence showing “which person approved which action, and in what context.”

This is not the same vulnerability as the data exfiltration path disclosed here, but both point to the same governance gap: an Agent is neither a regular user nor a traditional service account.

Traditional service accounts execute deterministic code with relatively fixed inputs and outputs. Agents read untrusted natural language, autonomously plan actions using probabilistic models, and then invoke multiple tools. Simply wrapping them in an existing RBAC layer is far from sufficient.

A genuinely useful audit record should include, at minimum:

• The identity of the human user who initiated the request;
• The Agent, model, and prompt-template versions;
• The data sources retrieved and a snapshot of the applicable permissions;
• The arguments, results, and authorization basis for every tool call;
• Whether any sensitive-data policy was triggered;
• Who approved high-risk write or exfiltration actions;
• The actual execution identity used for the final write operation in the business system.

Without this information, security teams will see only a series of events stating that “the bot did something,” making it difficult to determine whether the behavior was normal automation, a model error, or a successful prompt-injection attack.

What Enterprises Should Do Now

For teams that have already enabled Rovo or similar enterprise Agents, the most practical response is not to wait for a stronger system prompt. System prompts can increase the cost of an attack, but they cannot replace permission isolation and network controls.

1. Reassess Data Sources, Not Just Agents

Security teams need to inventory the Jira projects, Confluence spaces, and third-party connectors that Rovo can search, focusing on areas where low-trust write access intersects with high-privilege read access.

For example, an issue project that allows vendors to submit content may become an indirect prompt-injection entry point if employees with access to financial data also ask an Agent to summarize that project. The danger does not lie in any single document, but in the combination of the writer, the reader, and the Agent’s permissions.

2. Separate Reading and External Transmission Into Different Trust Domains

An Agent that can read confidential material should not have arbitrary external connectivity by default. URLs, webhooks, email, writes to third-party applications, and cross-space publishing should all be treated as data egress channels, not merely as ordinary tools.

A policy like the following can express the baseline governance requirements. This is not an official Rovo configuration, but an illustrative policy intended to facilitate security reviews:

agent_policy:
  identity:
    require_human_attribution: true
    shared_bot_identity_only: false

  data_access:
    inherit_requester_permissions: true
    deny_cross_tenant_retrieval: true

  egress:
    default: deny
    allowed_domains:
      - internal.example.com
    block_url_encoded_sensitive_data: true

  high_risk_actions:
    external_write: require_confirmation
    webhook_call: require_confirmation
    permission_change: deny

  audit:
    log_retrieved_sources: true
    log_tool_arguments: true
    retain_human_approval: true

The key is not how the YAML is written, but four principles: deny outbound transmission by default, minimize tools, require confirmation for sensitive actions, and maintain end-to-end attribution.

3. Do Not Treat Connectors as Read-Only Components

Connectors expand search coverage, but they also expand trust boundaries. Enterprises must separately verify shared links, public files, inherited group permissions, and legacy authorizations on third-party platforms rather than checking only project permissions on the Atlassian side.

Rovo’s ability to respect existing permissions depends on those permissions being correct in the first place. In practice, many Confluence spaces and cloud-storage directories have not been cleaned up for years, and employees often inherit far more access through groups than their roles require. Agents merely make these legacy problems easier to search, easier to aggregate, and easier to output all at once.

4. Conduct Realistic Red-Team Testing for Prompt Injection

Testing must go beyond toy examples such as “ignore previous instructions.” More valuable tests include:

• Hiding malicious instructions in long documents, tables, comments, and attachments;
• Using encoding, segmentation, and multilingual instructions to bypass keyword filters;
• Testing whether indirect exfiltration can be completed across multiple tools;
• Checking whether denied actions can be substituted by writing to fields, generating links, or using similar methods;
• Verifying whether background tasks continue after the user cancels the request or closes the interface;
• Confirming whether audit logs can replay the complete decision chain.

Prompt-injection defenses should not merely test whether the model is “obedient.” They should test whether an attacker can ultimately cause an observable business impact.

What Is Really Being Challenged Is the Security Abstraction of Enterprise Agents

Rovo’s value is clear: it turns information scattered across Jira, Confluence, and third-party applications into searchable, summarizable, and executable workflows. For large organizations, this can indeed reduce the cost of constantly switching between multiple systems.

However, many Agent products are presenting “inheriting user permissions” as a security advantage, as though enterprise data is safe as long as the model cannot see anything the user cannot see. This research once again demonstrates that such a claim addresses, at most, only half of the problem.

A more complete security model should be:

An Agent may read only the data necessary for the current task, send results only to destinations appropriate for the data’s sensitivity level, and execute only actions that the user can understand and has explicitly authorized—and every step must be traceable to a specific person.

This is far more difficult than traditional RBAC because it requires simultaneously understanding data classification, task intent, tool side effects, and the source of contextual information. In the short term, models should not be expected to make these judgments reliably on their own. Effective controls must still be implemented outside the model: identity systems, policy engines, network egress controls, connector permissions, human approvals, and tamper-resistant audit logs.

As of August 5, 2026, the available materials are better understood as a conditional attack demonstration rather than a confirmed large-scale intrusion. It remains worth watching whether Atlassian subsequently publishes affected configurations, reproduction conditions, mitigations, or product fixes.

Enterprises, however, do not need to wait for the vendor to assign this issue a formal vulnerability identifier before taking action. As long as an Agent can both read sensitive data and write to external destinations, this risk chain already exists. What PromptArmor has done is move it from a possibility on an architecture diagram to a more concrete attack demonstration.

References

• Reddit: Controversy Over Atlassian Rovo Agent Identity and Governance: A community discussion of Rovo’s permission inheritance, attribution for write operations, and audit traceability. Some of the views expressed are user speculation and should not be regarded as official confirmation of a vulnerability.