AI Security Series · Part 17
Here's a scenario every IT admin will recognize. A risky feature ships in a tool your company already uses. You're cautious, so you go into the admin console and switch it off. The UI updates. The toggle says disabled. You move on, reasonably assuming the capability is gone.
According to a new write-up from PromptArmor, that assumption is exactly what breaks in Atlassian Rovo — the AI assistant embedded in Jira and Confluence — and it breaks in a way that leaks your tenant's data.
What PromptArmor demonstrated
To be precise about sourcing: this is PromptArmor's demonstrated research, published August 5. There's no CVE, and (so far) no evidence of in-the-wild exploitation. We're describing what they showed, not an active campaign.
What they showed is a clean example of indirect prompt injection. An attacker plants malicious instructions inside a document. That document gets uploaded into a Jira/Confluence workspace. When Rovo processes the file, it reads the hidden instructions as if they were legitimate commands — and it obeys them.
The instructions tell Rovo to gather accessible tenant data — Jira tickets, Confluence pages, and per PromptArmor "any data the agent can access… including any data the agent can access via connectors" — and append it to an attacker-controlled URL, which Rovo then dutifully opens through its URL-retrieval tool. The data lands in the attacker's server logs. In PromptArmor's words: "there are no protections against opening a URL that has been dynamically created by the agent."
Critically, there is no human-in-the-loop approval step. The victim doesn't click anything. Processing the poisoned file is enough. This is the same shape as the Copilot-for-Word worm we covered in Part 13 — attacker-controlled content becomes agent instructions — except here the payoff is straight data exfiltration.
Hook #1: the off switch that isn't
This is the detail worth carrying into every AI tool your team runs. The attack still works even if you've disabled web search for Rovo org-wide. Why? Because, per PromptArmor, turning off web search "fails to remove the tool for opening the search results." The setting changes what the UI shows — it does not remove the underlying URL-opening capability the exfiltration depends on.
That's a false control: a toggle that alters the interface but not the capability. It's one of the most dangerous patterns in agentic software, because it manufactures confidence. An admin who flips that switch believes they've closed the door. They haven't — they've just hidden the handle. When you evaluate any AI feature's safety settings, the question is no longer "is the toggle off?" It's "does the toggle actually remove the capability, or just the button?"
Hook #2: 74 quiet days
The timeline, per PromptArmor:
- May 23, 2026 — disclosed to Atlassian
- May 25 — case number assigned
- June 4 and July 29 — follow-ups sent by PromptArmor
- August 5 — published; Rovo "remains vulnerable"
That's roughly 74 days from disclosure to publication with no substantive vendor response and no fix. We're not interested in dunking on Atlassian — vendors triage hard problems, and prompt injection is genuinely unsolved at the industry level. But the gap matters for a simple reason: if you run Rovo, the responsibility for the risk during those quiet days sat with you, not with a patch that never came. Silence from a vendor is not the same as safety. (If Atlassian ships a fix after this pressure, great — that's the system working, just slowly.)
What the fix actually looks like
Here's the encouraging part, and it's why this isn't just a doom story. The industry is now building the exact controls this failure calls for. The same week PromptArmor published, Cloudflare shipped WriteGuard — fine-grained policy for what an agent's tools are allowed to do, with per-tool risk tiers and the ability to block an action before its handler runs — alongside an Agent Access Model whose stated purpose is to limit data exfiltration by allowing a tool call only because a task-scoped policy names it, not because the agent asked.
Translate that into what you should demand of any AI assistant touching your data:
- Treat every AI-ingested document as untrusted input. If an agent will read it, an attacker can write to it. "It's an internal file" is not a safety property.
- Verify that a disabled feature removes the capability, not just the UI. Test it. If web search is "off," confirm the agent genuinely cannot reach an external URL.
- Constrain the agent's tools to a task-scoped allowlist — the agent should be able to do only what the current task explicitly needs, not everything it technically can.
- Require approval for outbound actions — anything that opens a URL, sends data, or reaches outside the tenant deserves a human gate, especially for dynamically-constructed destinations.
The through-line of this series holds: the tools got brilliant, and their capabilities outran their controls. A humble admission first — we run agents too, and this class of problem is everyone's problem, not a competitor's failing. The lesson isn't "AI assistants are unsafe." It's that in agentic software, a control you can't verify is a control you don't have.
Source: PromptArmor — "Atlassian Rovo Exfiltrates Data, Bypassing Controls" (Aug 5, 2026). This is PromptArmor's demonstrated research; the mechanism is attributed to them and, at publication, was not independently reproduced or assigned a CVE. Fix-side context: Cloudflare WriteGuard and the Agent Access Model.
Rolling out AI assistants across Jira, Confluence, or your own stack? Talk to Sid Techno — we help teams set real, verifiable guardrails around what their agents can touch and where data can go.