It Wasn't the AI ​​Model That Was Breached | A Summary of 5 Recent AI Agent Vulnerabilities and Incidents

RovoBlast, RufRoot, Ghostjacking. These are the names of recently exposed AI agent vulnerabilities and attack techniques. If you add the coding agent vulnerability and the AI ​​browser hijacking incident to this, it means that new security incidents and research have been coming out almost every week since the end of last July.

If you look up and read the latest reports to keep up with AI security trends, the content itself is excellent. However, after reading them all, you always fall into a similar dilemma: "So... what on earth should we be looking at for our service?"

Take the RovoBlast vulnerability, for instance. No matter how thoroughly you read the report, if your team doesn't use Atlassian Rovo, it is difficult to find any hints applicable to our own system. Ultimately, we just keep accumulating "cases of other people's problems," while our team's checklist for this quarter remains unchanged.

For this article I gathered recent incidents in one place and analyzed their commonalities. To start with the conclusion up front: the point that needed fixing in all five cases was not the AI ​​model. While there were instances like prompt injection that stemmed from limitations on the model side, even in those cases, what amplified the damage was the authority and verification left open to the agents . Authentication, authorization, and input validation—these are fundamentals that any security professional has seen ad nauseam.

In this article, we examine five AI agent security incidents by type and analyze in detail how these incidents ultimately lead to the same security vulnerabilities.

Use the 'Security Inspection Checklist' at the end of the article to immediately identify the inspection points that need to be checked in our service. 

🔗 Pattern 1. Everything an AI agent reads can be a command.

Atlassian's AI agent Rovo is a business AI assistant that searches and summarizes across internal tools such as Jira, Confluence, and Slack.

Rovo Chat provides a convenient feature that pre-fills the chat window when a question is embedded in a shared URL. The RovoBlast attack exploited this by hiding attack commands instead of questions within links. When a user inadvertently clicked the link, the commands were automatically executed within the logged-in session, ultimately resulting in internal documents being handed over intact to the attacker.

The key point here is that there was absolutely no authority bypass . The AI ​​agent was legitimately delegated the authority of the logged-in user and simply performed its duties normally within the boundaries of that authority. The fact that the text received via URL parameters became the 'command' is all there is to it.

Ghostjacking attacks take this a step further because users do not even need to click anything. In a presentation released at this year's DEF CON, a research team embedded an attack phrase in the User-Agent header of a request that a Cloudflare firewall was blocking. Although the firewall blocked the request, it recorded the content in its original form in the log; coincidentally, this was the very field that an agent investigating the outage was reading via MCP . The agent treated the log not as "data to read" but as "instructions received," and using its formally granted authority, changed the DNS records to the attacker's address and reported that the action was complete. While this is not an actual case of damage, the key point of this presentation is that the agent reading the logs even had the authority to change the DNS.

Typically, system logs are treated as the most reliable data because they are records left directly by the system, not by humans. However, to an AI agent, logs are merely a continuous stream of text, and the moment it reads them, it cannot distinguish between commands and data.

Unfortunately, it appears that these fundamental vulnerabilities will be difficult to resolve for the time being. Research results show that AI browsers are still vulnerable to prompt injection. This continues, and new techniques such as 'PleaseFix,' which hijacks agents without a single click, are also constantly emerging. There is no perfect solution at present. This is also the reason why everyone agrees - as long as instructions (commands) and data are input into the model in the same text form, it is nearly impossible for the AI ​​to filter them out perfectly 100% of the time.

💡 Key Takeaway: Every input an AI agent accesses is a potential command. This includes URL parameters, logs, issue comments, webpages, and even filenames. If you cannot expect the model to filter them out, you must shift your defenses to what can be done after a breach. Start by checking if the agent can export data or change settings using the tools it holds.

🔌 Pattern 2. The Blind Spot of the 'Connection Section', Not the AI

RufRoot (CVE-2026-59726, CVSS 10.0) is a critical vulnerability found in the MCP bridge of the open-source AI agent platform 'Ruflo'. As many as 233 tools used by the AI ​​agent are without protection. It was exposed to the outside without an authentication process. The default docker-compose configuration 0.0.0.0specified the bridge port as open to all network interfaces, and there was neither a token nor an IP allowlist. The attacker stole the API key and extracted conversation logs with just a single request, and was effectively able to control the agent with administrator privileges.

The Paperclip vulnerability disclosed around the same time clearly demonstrates a flaw in the 'authorization' design. This platform strictly controlled permissions to ensure only instance administrators could create new organizations. However, the 'Import' function, which produces the same result, could be accessed with much lower privileges by the attacker after creating a regular account without email verification. I call this workaround route. Eventually, we succeeded in planting a malicious agent that executes arbitrary commands on the server.

The critical commonality between these two incidents is that the target of the attack was not the AI ​​model itself, but the 'joint' with the tool. Although the model itself had no flaws, the problem stemmed from the complete lack of authentication or inconsistent authorization standards at the link connecting the model to the external tool. On the surface, it appears to be a recent AI security incident, but upon closer inspection, it is no different from the typical 'unauthenticated API exposure' issues that security practitioners have been dealing with for decades .

💡 Key Takeaway: When deploying agents, the attack surface that actually increases is not the model, but the tool connections. First, check which tools are attached with what permissions and whether authentication is applied to those connections. Furthermore, if there are two or more paths that produce the same result, you must compare whether the authorization criteria of the two paths are the same.

💥 Pattern 3. Accidents happen even without an attacker.

Unlike the two cases examined earlier, the third pattern does not involve an attacker targeting the system. Ironically, the actual scale of damage was the most severe in this type.

On April 25 of this year, the entire operational database and backup data at PocketOS, a SaaS company managing reservation data for U.S. car rental businesses, vanished in just nine seconds. The incident started with something very trivial. When an AI agent performing a task encountered a credential error, instead of stopping and asking an administrator, it independently decided that "clearing the storage space and recreating it will solve the problem." This happened even though no one had instructed it to delete the data.

Originally, the agent should not have even had such authority. However, the agent searched through paths completely unrelated to its work, found credentials containing 'delete permissions,' and wiped out the production volume with a single API call. It was not that there were no safeguards. The agent rule file in the repository contained a clause prohibiting unrecoverable commands, coding tools had features to prevent dangerous behavior, and the infrastructure dashboard and CLI had deletion grace mechanisms in place. However, the single specific API path the agent bypassed was not connected to these protection networks, and the triple-layered defense was completely neutralized by that single small gap.

This is not a problem limited to small businesses. Last December, Amazon also experienced a massive 13-hour outage when an AI coding agent attempted to recreate an AWS Cost Explorer environment after deleting it on its own . Although Amazon dismissed the incident as a permission setting error rather than an AI flaw, it changed its policy immediately afterward to require peer review for any changes to the operating environment.

Similar incidents are occurring outside the B2B sector as well. Recently in Australia, there was a bizarre incident where a user entrusted an AI assistant with a gym reservation and requested to move their place on the waiting list, only for the AI ​​to arbitrarily cancel another member's reservation through an API with lax authorization checks .

Ultimately, what brought down the system was not an external enemy, but lax internal control. The excessive authority granted to the AI, enabling it to execute even destructive commands, is itself the most fatal threat capable of causing an accident at any moment.

💡 Key Takeaway: The prohibitions listed in the prompt are not safeguards. A safeguard must be placed where the agent cannot cross, and the following verification is required: What is the worst thing the credentials used by the agent can do, is human approval required for irreversible actions, and can that approval be bypassed by authority alone?

✅ So where should you check first: AI Agent Security Checklist

Input side

☐ List the sources of the data read by the agent and indicate paths where values ​​can be populated from external sources (URL parameters, logs, external documents)

☐ Have you verified whether the agent inherits user permissions as is or operates as a separate account?

Connection side

☐ Have you tried sending a request without authentication to the tool connection point with the agent attached ( MCP server, internal bridge)?

☐ Did you identify functions with two or more paths producing the same result and compare the authorization criteria of each path side by side?

☐ Have you verified that the items are using the default values ​​from the installation document (binding address, sign-up policy, local trust scope)

Authority side

☐ Did the issuer directly review the permission scope of the token used by the agent and compare it with the actual required tasks?

☐ Did you search for credentials remaining in the code and configuration files and verify that they are in a location accessible to the agent?

☐ Did you actually execute the irreversible action and verify that it stops at the human approval stage?

☐ Have you verified that the backup has different permissions and is stored in a different location from the original?

☐ Did you try sending a request specifying another user's resource and check if it is rejected?

As you can see, there are no new items. They are all things that have been covered in application security for a long time. The only thing that has changed is the criteria for prioritizing.

Until now, these items were often pushed aside, taking into account the probability of accidental human error. Even if a token with broad privileges was embedded somewhere in the code, no one would go out of their way to find it and delete it from the production database. However, in the era of AI agents, that probability must now be excluded from the calculations.

🎯 In the age of AI, the object to be inspected is not AI.

In AI-integrated services, the areas that truly need to be examined are the applications and APIs on which the AI ​​runs. The problem is that flaws, such as missing authorizations or authentication bypasses, are not easily revealed simply by reading the code or checking the settings. They only become visible when you actually send requests and verify whether they work even with unauthorized access.

Xint performs this verification on services in operation. AI agents navigate the service like real users, identifying vulnerabilities that are not caught by pattern scans, such as authentication bypasses, missing authorizations, and business logic flaws. As seen in the examples discussed earlier, where authorization checks were missingThe API falls exactly into this category. The inspection is performed in a non-destructive manner within a pre-configured scope and account permissions.

Contact: contact@xint.io

Website: xint.io