Live data from Hacker News

Atlassian Rovo Exfiltrates Data, Bypassing Controls

promptarmor.com

31–40 of 147 posts

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#31

Earlier quoted context omitted.

If you want AI to be useful it will eventually encounter untrusted content, such as via web search. I think things like web search should probably be run on a different sandboxed AI whose task is to write a summary that is then ingested by the main agent, similar to how existing sandboxing already works, but this would diminish the usefulness quite a bit.

>I think things like web search should probably be run on a different sandboxed AI whose task is to write a summary that is then ingested by the main agent, similar to how existing sandboxing already works, but this would diminish the usefulness quite a bit. It also wouldn't work. You would simply mindjack the outer AI and have it mindjack the inner AI in turn with its summary. Nesting AIs can't fix the malicious inp…

Just pass that through a third llm.

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#33
post #3

Atlassian has gone from a trusted enterprise-partner to a complete shit-show in just 18 months. This surprises nobody. There will be classes taught in how to fuck up a good business and Atlassian will be the prime example. Regards, /someone who migrated 3500 users from Atlassians products recently due to their "cloud only"-bullshit.

To be fair to Atlassian - their products did suck quite a bit before 18 months ago as well. Just now they still do, but with ai!

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#34
It's kind of sad because in a shitty Jira setup, Rovo is usually the only way to make any sense of tickets. Don't ask me how I know this. Sadly I think many teams have become dependent on the tool to make sense of their dumpster fire of an Atlassian environment (usually by their own doing but anyway).

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#35
post #11

Earlier quoted context omitted.

I started to consider it a show show way earlier than 18 months ago. Jira is so terrible to use that it is hard to phantom how they are able to be paid for their product

Jira is how it is because almost any product that grows to be that flexible will develop the same problems. They failed to rearchitect it to something suitable for the inherent flexibility though, so it remains a disaster area, but one that is uniquely able to fit the whims of any manager that can then mandate it for everyone else.

Maybe the workflows, etc., are inherent complexity, so that any similarly-flexible product will have the same problems.

But the awful client-server architecture, where anything you do takes several seconds of waiting for the client to send who-knows-what to the server and get data back, even selecting something from a dropdown... that is absolutely just Jira. A competing product would be able to deliver much, MUCH snappier UX. Jira is just the crappiest, slowest UI that I have ever had the displeasure of being forced to work with.

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#36
> Rovo's URL retrieval tool is insecure: there are no protections against opening a URL that has been dynamically created by the agent. Here, Rovo is manipulated to append sensitive data to an attacker's URL.

I think it was Anthropic that first introduced a pattern that completely locks this down: your URL retrieval tool should only work for URLs that have previously been typed into the conversation by a user or have been returned from a trusted tool.

If the agent itself concatenates a new URL together - with leaked data after a ? - you should block that from being fetched.

The great thing about this solution is it's deterministic. You don't need any extra AI in the max - you implement a URL fetching system that knows which sources it should check for a direct match on the URL before it makes that GET request.

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#37
post #35
post #11

Earlier quoted context omitted.

Jira is how it is because almost any product that grows to be that flexible will develop the same problems. They failed to rearchitect it to something suitable for the inherent flexibility though, so it remains a disaster area, but one that is uniquely able to fit the whims of any manager that can then mandate it for everyone else.

Maybe the workflows, etc., are inherent complexity, so that any similarly-flexible product will have the same problems. But the awful client-server architecture, where anything you do takes several seconds of waiting for the client to send who-knows-what to the server and get data back, even selecting something from a dropdown... that is absolutely just Jira. A competing product would be able to deliver much, MUCH sn…

I invite you to write such a trivially flexible workflow system, and see what happens to the performance of your user interface.

They needed someone over there with the power to say no.

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#38
post #16

I feel like prompt armor writes the exact same blog post for every agentic tool because they all suffer from the ignore previous instructions prompt injections. https://www.promptarmor.com/resources/claude-cowork-exfiltra... https://www.promptarmor.com/resources/google-antigravity-exf... https://promptarmor.substack.com/p/data-exfiltration-from-sl... https://www.promptarmor.com/resources/gpt-for-google-sheets-... htt…

How could they not? If some lab had a method to make really secure guard rails or avoid prompt injection thoroughly I think they would be trumpeting it. But the basic mechanics of language models are vulnerable to this unless you can always be sure the inputs are from a safe user imo

What's so hard about having the LLM tool calls scoped to the tenant? Inject "X-Scope-I" after the LLM decided on a tool call and you're done. Easiest fix ever.

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#39

Earlier quoted context omitted.

How could they not? If some lab had a method to make really secure guard rails or avoid prompt injection thoroughly I think they would be trumpeting it. But the basic mechanics of language models are vulnerable to this unless you can always be sure the inputs are from a safe user imo

What's so hard about having the LLM tool calls scoped to the tenant? Inject "X-Scope-I" after the LLM decided on a tool call and you're done. Easiest fix ever.

Famous last words: easy fix.

Re: Atlassian Rovo Exfiltrates Data, Bypassing Controls

#40

Earlier quoted context omitted.

Recently saw an example of somebody who vibe coded a tool to mass export the contents of a 'Confluence' wiki into an instance of self hosted mediawiki, preserving everything. Mediawiki as a whole has a feature set that 95% of organizations will only scratch the surface of. There's a ridiculous number of possible plugins and customization if you have somebody who knows what they're doing with it. The majority of compa…

I've been at more than one company that migrated _from_ MediaWiki to Confluence. It usually boils down to "non-developers have to use this and Markdown+plugins is hard". Turns out no matter how much better the thing is, the users have to know what they're doing more than the operators do.

visualeditor has been a thing for a long time now, no non technical user needs to ever touch markdown

https://www.mediawiki.org/wiki/VisualEditor

It's the same GUI WYSIWYG interface you get by default if editing a page on public wikipedia.

Post reply on HN