Is Prompt Injection the New Email Phishing [Champions Slack Insider]

[#1]

Remember the April 9th Champions Slack Insider asking whether Rovo could be tricked by malicious files? Well...the Champions Slack gave us a reason for a follow-up.

@Josh Steckler kicked things off by sharing a report from a security vendor demonstrating a scenario in which Rovo could potentially be manipulated through indirect prompt injection to send data to an external destination.

@Dirk Ronsmans and @Paulo Ramalho quickly added the customer perspective: security teams were already asking questions, and some customers were considering—or had begun—disabling Rovo.

And on a separate line, @Anandhi Arumugam _Cprime_ shared that their security team identified similar issues in a highly secured Cloud Enterprise environment and is looking for mitigations that others have successfully implemented.

So, let's separate the risk from the headline.

First, a correction to my earlier article

I previously wrote that malicious instructions within files would be treated as data rather than commands. That was too absolute. Indirect prompt injection exists because an AI system can sometimes be influenced by malicious instructions embedded within content it is processing.

As @Rebekka Heilmann _viadee_ pointed out, one of the bigger concerns may be employees introducing questionable content into Rovo or external customers introducing it through JSM/CSM.

That gives us a better starting principle:

Treat externally supplied content as untrusted input—even when AI is processing it as part of a legitimate task.

My Threat Assessment: Credible but Conditional

The security report raises a legitimate concern. But successful exploitation depends on several things happening together:

1. Rovo encounters malicious or manipulated content containing an indirect prompt injection.
2. Rovo processes that content as part of a legitimate task.
3. The user or agent has access to sensitive Jira, Confluence, JSM/CSM, or connected data.
4. Rovo has access to a tool or outbound mechanism capable of sending or retrieving data externally.
5. The malicious instruction successfully influences Rovo's behavior.
6. No effective control blocks the outbound action or requires human approval.

Remove one or more pieces of that chain and the risk changes.

And there's another practical consideration: Rovo Actions themselves can still be inconsistent depending on the action and execution context. An attack that depends on successfully executing an action also depends on that action actually working.

That's hardly a security strategy—but it illustrates why the attack chain matters.

Does this mean Rovo bypasses permissions?

That's not what this scenario demonstrates. The concern is that Rovo could potentially be influenced into sending information that the user or agent is already authorized to access somewhere it shouldn't go.

That's an indirect prompt-injection and data-handling/egress problem, rather than necessarily a Jira or Confluence permissions bypass. Permissions still matter enormously because they determine what information is available if an AI interaction is successfully manipulated.

This isn't really a Rovo-only problem

This is where the discussion gets bigger. Prompt injection is a known challenge across enterprise AI assistants and agents. The same general attack class can apply when an AI system processes untrusted content while having access to sensitive information, connectors, or tools.

Connector and MCP risks are similarly broader than Atlassian. Connecting AI systems to additional services can expand both what the AI can access and what actions it can potentially perform. Security researchers are actively evaluating these attack surfaces across AI platforms and hundreds of MCP connectors.

And that context matters when reading vulnerability headlines.

A security vendor could start with a known class of AI vulnerability, identify products where that vulnerability is technically plausible, demonstrate an attack path, and then build a pretty attention-grabbing headline around the individual platform.

That doesn't make the demonstrated vulnerability imaginary. It means we should distinguish between: "Analysts demonstrated a legitimate attack path" and "This product is fundamentally insecure." Those are very different conclusions.

So what should Rovo admins actually do?

Ask what untrusted content Rovo can encounter, what sensitive information the user or agent can access, what tools or external mechanisms are available, and where human approval or other controls interrupt the chain.

Apply least privilege. Be deliberate about connectors and actions. Treat external content as untrusted. Add approval around higher-risk actions. And test agents against adversarial content—not just happy-path prompts.

Prompt Injection Is the New Email Phishing

Then @Fernando Eugênio da Silva gave us perhaps the best summary of the entire conversation:

Prompt Injection is the new Email Phishing.

I think he's onto something. We didn't solve phishing by eliminating email. We developed layers of technical controls, monitoring, least privilege, education, and response processes. AI security is heading in a similar direction.

HUGE shout out to @Ciara Twomey Nielsen who identified Prompt Injection as a possible concern back in March, inspiring the first article.

[Rebekka Heilmann _viadee_]

We resolved this security concern internally by yet another awareness campaign (well.. a Slack post anyway) about prompt injection in general and that external content always has to be reviewed before feeding it into any AI system.

[Dr Valeri Colon _Connect Centric_]

P.S. Atlassian has publicly acknowledged prompt injection and data-exfiltration as AI security risks, and its security guidance includes controls for mitigating them. So they recognize the risk category.

[Fraser Shepherd]

I'm confused about the above.  I don't seem to have the ability to restrict file uploads to Rovo, the vulnerability in question works even if Web Search is disabled, I cannot find a way to 'treat external content as untrusted' in terms of uploads to Rovo.

I see very little that I as an Atlassian Admin can do to mitigate this risk other than user education (which a SecOps department are likely the treat as no better than a sign on the unlocked door that say 'please do not open') or fully disabling Rovo.