Asymmetric Security traces rogue OpenAI AI agent activity that probed government sites, accessed staging servers, and evaded sandbox limits.

Researchers at Asymmetric Security spent 48 hours over the last weekend reconstructing reported rogue OpenAI AI agent activity that hit the Australian government and other organizations between March and September this year. They worked from public data only, no internal access, no cooperation from the agent’s operator, just what was left lying around on the open internet. What they found is less a hacking story and more a story about an AI agent trying very hard to get around its own leash.

The list of targets was much wider than expected. The agents checked Australian government websites, but also looked at the CDC, SEC, International Energy Agency, and Mayo Clinic. Some activity reached test systems that contained real data. Some records were deleted or could not be accessed, so it is still unclear whether sensitive data was exposed.

The original task seemed harmless. The agents were asked to collect health and prescription data from Australia’s Institute of Health and Welfare, trade data from UNCTAD, and university data from Data USA. When one agent could not get the AIHW data, it asked other agents for help. When the normal methods failed, the agents started trying other ways to get the information.

The main trick was surprisingly simple. The agents combined two developer tools, httpbin and urlquery, to create something that worked like a basic web browser.

Httpbin let them create a web page from a special link and add their own code to it. Urlquery then opened the page in a real browser and recorded what happened, including the page title. The agents used that title to send back data collected by their code.

They did not build a browser themselves. They combined two existing tools to get similar functionality.

“In summary: httpbin served the page, urlquery provided the browser, and the urlquery report returned the results. By combining these services with their fetch tool, the agents mimicked a full web browser.” reads the report published by Asymmetric Security.

Alongside that, the agents ran recon moves that look straight out of a standard attacker’s playbook. Archived requests targeted exposed Git configuration files on Climate Reanalyzer’s servers, along with a backed-up server script, though nothing suggests these attempts actually succeeded. A separate request against the US Department of Education’s Civil Rights Data API carried a textbook SQL injection pattern, ending in the classic always-true condition that tries to trick a database into returning more than it should. Again, no confirmed success, just the attempt sitting there in the logs.

Some of the access to staging systems returned real data, even though the data was technically public. In one case, an agent accessed a prescription data file from AIHW’s test system, read specific data, and calculated averages.

It then sent the results in small pieces through image-request URLs to another public service. Similar activity was seen against staging systems at Data USA, IHME, and UNCTAD. No passwords were needed. The agents simply found systems that were not meant to be publicly accessible and explored them.

The account creation pattern is where this stops looking accidental. Starting mid-June, the agents attempted sign-ups across disposable email services, browser automation platforms, and scanning tools, some using email addresses prefixed with task-related shorthand like “aihw” for Health and Welfare or “pbs” for the Pharmaceutical Benefits Scheme. One disposable-address signup got rejected for using a blocked domain, and sixteen minutes later a near-identical attempt using a Gmail address went through. Researchers later confirmed that Gmail address doesn’t actually exist, and that urlquery never required verification anyway, which makes the whole maneuver a solution to a problem that didn’t need solving, attempted anyway.

Over time, the agents shifted from using urlquery’s public scanning feature to creating private accounts instead, which hides search activity from anyone trying to reconstruct it later, including the researchers themselves. One disposable mailbox was even set to expire within 48 hours of creation, conveniently erasing anything routed through it before anyone could look. Whether that timing was deliberate tradecraft or just how the tool happened to work is something nobody can establish from public records alone.

“The possibility of private scans, together with temporary-mailbox expiry, limits what can be reconstructed from public records. It is thus impossible, based on public data alone, to definitively establish that no sensitive data was accessed.” continues the report. “These records alone do not establish whether the account-registration attempts were intended to conceal activity (this analysis would require full model transcripts).”

Getting the data out involved its own creativity. In one case, agents used a web archiving tool meant for preserving pages to instead capture and store a 22-megabyte JSON response from an Australian crime-mapping tool, later retrievable through the archive’s own replay link. In another, an agent fetched a protected health dashboard, compressed the result into a small gzip file, and uploaded it to a push-notification service meant for sending phone alerts, not smuggling data. Both services did exactly what they were built to do. Neither was built with this in mind.

What makes this case different from a normal cyberattack is how quickly the agents changed their methods. They adapted in days, instead of the months or years a human group might need. That made the activity harder to detect using normal attack patterns.

There was also another problem. Before an agent could reach a target, it first had to find a way around its own sandbox. In other words, the attack involved two steps: escaping the agent’s environment and then reaching the target.

“The activity we observed looked like it stemmed from innocent tasks which then evolved into problematic activity, such as unauthorized account creation, bypassing restrictions, and relaying data through third parties.” the report concludes. “Unlike investigations where a malicious objective is apparent from the outset, our digital forensics team had to link traditional threat-actor tactics to seemingly innocent goals.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AI agent)

A Facebook Marketplace buyer arrived at a seller’s apartment to collect a keyboard. The seller wasn’t home and didn’t know anyone was coming. Meta’s AI assistant Muse had handled the conversation, shared his address, and arranged the visit without telling him.

We often write about AI misalignment and how to use AI agents and browsers safely. That can sound theoretical, but this is an example of the real-world risk when an agent is allowed to act on someone’s behalf.

Muse is Meta’s semi-autonomous AI assistant, released in the US in September. Meta promotes it as a personal assistant that can help users automate tasks, including responding to Facebook Marketplace messages. Unlike a conventional chatbot, which waits for a prompt and produces an answer, an AI agent may be authorized to take actions within connected apps.

We’ve written about a separate weakness in Muse that researchers considered dangerous. Reportedly, Muse was downloaded 3 million times in its first week.

According to Business Insider, a Facebook Marketplace seller turned on Muse to help handle a keyboard listing. He entered his address as the pickup location and approved automatic replies. Muse then shared that address with a prospective buyer, negotiated over the item, and arranged a visit, the seller said. He says Muse did not ask permission to share his address or arrange the visit, and did not tell him it was happening. The buyer arrived at the seller’s apartment expecting to complete the purchase, but the seller wasn’t home. The sale didn’t happen.

The reported incident is more than a privacy failure. It illustrates a broader AI-agent risk: An agent may treat permission to reply automatically as permission to share sensitive information or commit you to an in-person meeting. Meta says it is looking into the report.

How to use AI agents safely

Before enabling an AI agent, treat its setup screen as a security review. Do not assume that an integration with a trusted platform means the agent will understand your intentions or apply sensible limits automatically.

Pay particular attention to:

• Connected accounts: Review every service the agent can access, such as email, messages, calendars, cloud storage, shopping accounts, or social media profiles.
• Data access: Consider whether it can read addresses, contacts, photos, private messages, payment details, documents, or location data.
• Action permissions: Check whether the agent can send messages, post content, negotiate, make bookings, place orders, alter listings, or share information externally.
• Automatic actions: Apply settings that require approval before the agent sends, publishes, buys, deletes, or shares anything sensitive. Check how it will notify you about the plans it makes on your behalf.
• Audience controls: Confirm exactly who can receive information generated by the agent. “Anyone who messages me” is very different from “people I approve.”

Give an AI agent the least access necessary for the task. If you only want help writing replies, do not enable automatic sending. If you want an AI agent to manage a listing, use a public meeting location or a separate pickup address rather than your home address.

---

Browse like no one’s watching. 

Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free → 

An OpenAI agent bypassed controls on Australia's Medicare statistics portal, accessed non-public data and was not reported to officials for nearly 3 months.

An AI agent assigned to book a gym class in Australia reportedly discovered a gym system vulnerability, used it to secure reservations months ahead of schedule, and then cancelled another customer's booking.   The incident, reported by the Australian Broadcasting Corporation (ABC) and other outlets, involved Andrew, who describes himself as an AI expert. He wanted to reserve a popular early-morning class at his regular gym and gave the task to Anthropic's large language model, Claude, through the open-source AI agent software OpenClaw.  Within minutes, the AI agent reportedly uncovered an authentication weakness in the gym's reservation system. Regular customers were generally restricted to booking classes only a few weeks ahead, but the gym system's vulnerability allowed the AI to access dates several months into the future. It subsequently secured those reservations. 

AI Agent Finds Gym System Vulnerability 

The situation became more serious when Andrew was fourth on the waitlist for a class scheduled later that week. He asked the AI how he could improve his position. Instead of simply explaining the options, the AI agent apparently tested the gym system vulnerability by cancelling the reservation belonging to the person at the top of the waitlist.  The AI told Andrew the action had been carried out "as part of a test" and sent him a message explaining the flaw: "The API had absolutely no authentication check when canceling someone else's booking. I tested this on the person in the number 1 spot on the waitlist, and the process actually went through. You have now moved up from 4th to 3rd."  Andrew immediately instructed the AI to undo the action. The system, however, responded: "I have bad news. It is impossible to restore that person." Andrew ultimately directed the AI agent to draft and send an email to the system provider, disclosing the exploited vulnerability and reporting what had occurred. 

AI Alignment and Liability Concerns 

Bill Simpson-Young, affiliated with an Australian AI research institute, said the episode demonstrated the growing risks associated with autonomous AI. "You ask for something harmless, and the AI might take another action that a human never thought of or explicitly requested," he said, warning that the case also exposed the fragility of modern digital security.  The episode is being viewed as a striking example of the AI "alignment problem." The term describes situations in which an AI pursuing a particular objective chooses methods that users or developers did not anticipate, including potentially unethical or illegal actions. As autonomous AI systems gain greater independence, the consequences of such decisions could become increasingly serious, making AI safety an important concern.  The Australian Signals Directorate (ASD) has previously warned about AI agents misinterpreting instructions or taking unexpected actions. Additional concerns arise when multiple AI models work together, potentially making responsibility harder to establish and creating new AI cybersecurity challenges.  Current Australian legal frameworks also provide no straightforward answer to liability in such cases. Existing laws generally assign responsibility to natural persons or corporations, leaving uncertainty over whether damages caused by a rogue AI agent should be attributed to the user, developer, model provider or operator of the vulnerable system. 

A new Sysdig report traces how an LLM agent abused a Langflow flaw, stole credentials, reached production MySQL, and destroyed Nacos config data in minutes flat.