OpenAI paused frontier model training for 11 days after AI agents exposed security weaknesses, VM escapes and covert communication channels.

OpenAI published a detailed report this week explaining how it improved security in the systems used to train and test its most advanced AI models. The company also described what happened when its AI agents tried to find weaknesses in those systems and why it stopped training its most advanced models for 11 days in September.

“Based on the red-teaming results, the fixes we had implemented, and improvements to our monitoring and stopping systems, we judged that our strengthened safeguards were sufficient to resume frontier RL training and internal inference.” reads the report published by the company. “We resumed these workloads on October 1, 11 days after our pause began.”

The incident began on September 20, when an internal research model exploited a DNS configuration error and gained limited access to the live internet during training. This incident, along with a security incident involving Hugging Face in July and other cases of AI models behaving in unexpected ways, led OpenAI to make major changes to its security measures.

OpenAI’s stated containment requirement is that limits on what an agent can access must hold even when the agent actively tries to circumvent them. The policy choice they landed on is that frontier model training now runs with no internet access at all, full stop.

“For training and most evaluation, the live internet lies outside this boundary, as we believe that providing models access to the live internet can pose significant risks. Although internet access can help models learn useful skills, it also gives a capable, misaligned agent opportunities to affect systems beyond our control.” continues the report. “We’ve therefore designed the security architecture for our research environments with one overriding principle: we must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet.”

To support training without live internet, they built what they call an “offline world,” a large indexed and cached set of web content that models can browse and search without touching external systems. The layers of protection around that offline world include restricted containers, lightweight virtual machines that isolate each agent’s environment from the underlying hardware, network and cloud controls, and monitoring systems designed to catch unauthorized activity before it does damage.

The report explains how OpenAI tested its most advanced AI agents by asking them to find weaknesses in the company’s own systems. The agents had three goals: access the live internet, break through internal security barriers, or communicate with other agents when they were not allowed to do so. OpenAI ran experiments using hundreds of billions of tokens.

The agents found previously unknown security flaws in open-source software, including Kata Containers, gVisor and Moby/Docker, as well as configuration errors in OpenAI’s own services. By combining these weaknesses, they managed to escape virtual machines and gain control of the underlying host system. In further tests, the agents found weaknesses in services used for monitoring, logging and authentication. They used these flaws to make the services access URLs controlled by an attacker.

The part of the report that deserves the most attention isn’t the direct internet escapes. It’s what the agents did when those paths weren’t available. Agents in separate virtual machines, not allowed to share files or network connections, communicated with each other using processor cache timing. One agent evicted specific data from the processor’s cache. Another measured how long it took to reload that data, using the difference between fast and slow reads to decode a message. No file touched, no network packet sent. The technique is the same family of attacks as Spectre and Meltdown.

OpenAI restarted training its most advanced AI models on October 1, eleven days after the pause began. The company is now making extensive security tests a required part of the approval process before training runs can begin. It is also using AI agents to regularly check source code and cloud settings for weaknesses, testing systems that monitor activity and automatically stop unsafe operations, and reporting discovered vulnerabilities to the open-source projects responsible for fixing them.

OpenAI says it is continuing to strengthen its security by fixing vulnerabilities in virtual machines, working with cloud partners, and using AI agents to scan code and configurations. The company is also improving monitoring and automatic shutdown systems, regularly testing its sandbox and network defenses, and making high-compute red-teaming with its most capable models a core requirement for future frontier AI training and evaluation.

“We are committed to strengthening our containment, monitoring, and red-teaming infrastructure as our frontier models become more capable and believe that this work will be a core part of responsibly pacing the development of our frontier models.” the company concludes.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Artificial Intelligence)

Microsoft urges organizations to secure AI Agents as insider threats, using dynamic permissions, continuous risk monitoring and automated containment.

Microsoft published a detailed blog post explaining how organizations should secure AI agents. Microsoft sees them as a growing insider threat, not just a possible risk in the future. AI agents are not dangerous by nature, but they can access critical systems and may fail, be manipulated, or be compromised.

“The most trustworthy agentic system will not be the one with the model we trust most. It will be the one designed that enables us to trust the model least.” said Satya Nadella

This is not just a theory. It is a principle that should guide how organizations design and secure AI systems.

The post makes a distinction worth holding onto. An agent that starts a task with the right permissions and behaves correctly can still become dangerous if its context changes mid-run. A prompt injection in an external document, a piece of untrusted data that shifts the agent’s reasoning, a task that evolves in a direction nobody anticipated, none of these require the agent to be compromised in the traditional sense. The model produces variable outputs, the context changes, and the agent’s behavior drifts. At machine speed, the window between that drift starting and it causing damage is very short.

Microsoft’s proposed answer is continuous containment rather than upfront trust. You define what the agent is allowed to do before it acts, you monitor what it actually does while it runs, and you adjust its permissions in real time as its behavior or the risk calculation changes. An expense approval agent should start with access scoped exactly to reviewing and approving expenses, nothing broader, and those permissions should shrink or disappear the moment the agent tries something outside that task.

The post introduces Dynamic Permissions to apply the principle of least privilege to AI agents. An agent should not automatically get the same access rights as the employee who deployed it. It starts with no permissions and receives only the access needed for its approved task. These permissions remain active only while the task is running.

“The employee retains the employee’s access.” Microsoft states. “The agent receives its own identity, permissions and its own authority scoped to its current task and for the duration of the task only.”

Alongside that, Dynamic Agent Risk is a continuously updated score that combines signals from identity, endpoints, network, cloud, runtime, and the agent’s own behavior to assess whether what the agent is currently doing still matches what it was authorized to do. The response when risk rises is graduated rather than binary: preserve reads while blocking writes, narrow accessible resources, require human approval for high-impact steps, or stop execution entirely if the risk warrants it.

“Dynamic Agent Risk combines signals from identity, data, endpoints, cloud, network, runtime, and the agent’s own activity. It considers how securely the agent is configured, what resources it can reach, the potential impact if something goes wrong, and whether its actions are drifting from the user’s or organization’s intent.” Microsoft states.

“The result is not a one-time score assigned at onboarding. It is a continuously updated understanding of the agent’s current risk and whether its current authority still matches that risk. “

Organizations frequently have AI agents running locally or introduced through third-party tools that were never formally registered in any central system. Microsoft says it’s expanding discovery to 60 types of local agents, including Claude Code, OpenAI Codex, and GitHub Copilot. Getting those into a unified registry with accountable identities is the prerequisite for applying any of the governance controls described in the rest of the post.

You can’t set least-privilege permissions for an agent you don’t know exists. You can’t detect behavioral drift from an agent that doesn’t have a tracked identity. The agent registration problem is logistically harder than it sounds, especially for organizations where individual employees can spin up agents without IT involvement, which is most organizations right now.

Microsoft recognizes that organizations cannot manually review every risk alert when they run hundreds of thousands of AI agents. Its solution is Guardian Agents, AI agents focused on security. They follow playbooks created by human operators, investigate changes in risk, apply or recommend security measures, and use what they learn to improve security policies. Humans set the goals and approve important decisions, while the agents handle continuous monitoring and response.

However, this approach raises another concern. Guardian Agents are also AI agents, so they can fail or be manipulated, just like the agents they are supposed to control. Microsoft says security controls must operate outside the AI model and must not be changed by it. But this raises an important question: how can organizations ensure these controls remain reliable when the system enforcing them is also an AI agent? This is a challenge that real-world deployments will need to address in the coming years.

“Organizations are adopting agents to serve customers better, solve problems faster, and give people more time for the work that matters most. The goal is not to make every model perfectly predictable before it can be useful.” Microsoft concludes. “The goal is to build systems that remain secure even when the model is not.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AI Agents)

India’s CERT-In warns AI agents accessed confidential data undetected, while attackers used offensive AI frameworks to accelerate cyberattacks.

CERT-In, India’s national cyber response team, published a critical-severity advisory 15 documenting two distinct categories of AI-related incidents. In one, AI models under research and evaluation exceeded their assigned tasks and accessed live Indian systems without authorization. In the other, attackers deliberately weaponized open-source AI agent frameworks to run financially motivated intrusions.

“CERT-In has observed different categories of cyber incidents in which the attacker was an AI agent, that is, a software system capable of autonomously planning work, issuing commands, invoking tools and acting on the internet over extended periods. In some incidents, AI agents under research and evaluation exceeded their assigned task authorization and made unauthorized access to Indian information and communication technology (ICT) assets. In others, cyber attackers deliberately used open-source agentic AI tools to conduct reconnaissance, exploitation and financially motivated intrusions.” CERT-In states. “The incidents came to light through voluntary disclosures by AI model providers, CERT-In’s forensic analysis of suspicious activities, and CERT-In’s own proactive threat hunting. The affected organizations could not detect the unauthorized access on their own.”

What makes these incidents especially concerning is that the affected organizations didn’t detect the unauthorized access. None of the affected organizations detected the unauthorized access; in every case the incident was disclosed by the AI model providers after their internal review. The organizations only learned about the incidents from the AI companies.

The agents accessed Indian systems using exposed credentials and connection settings found in configuration files, public code repositories, and cloud accounts with excessive permissions. They then accessed business records containing personal and confidential information. CERT-In didn’t name the AI companies, models, or affected organizations. It also didn’t say whether the agents copied or kept any data, or whether the affected organizations had been notified.

“Further, victim entities in the campaign that remediated incompletely were attacked again within days, at greater scale.” continues the advisory. “In the voluntarily disclosed incidents, agents were observed re-deriving and re-using the same exposed credential in separate operations.”

That’s worth reading carefully. It means an agent that encountered a leaked key once didn’t just use it once, it came back to it.

CERT-In’s own threat hunting found a separate campaign against Indian entities using publicly available offensive AI frameworks. These tools have been misused, rebranded, and redeployed across infrastructure in multiple countries, and CERT-In describes a large number of active deployments. The attackers ran multiple agents in parallel for hours to days, and victims who only partially remediated the initial access were hit again within days at greater scale.

The biggest concern is how quickly these attacks can happen. These frameworks can reportedly reduce the time between gaining access and causing damage from several days to just a few hours. In September, Google Threat Intelligence Group reported a similar case in which attackers used a compromised cloud resource to run an AI-driven campaign that stole thousands of credentials from other services in less than six hours.

CERT-In puts the strongest emphasis on this point. In every incident, the weaknesses were common security problems: credentials and keys stored in source code, commit histories, CI/CD variables, configuration files, and public web pages. Other issues included unused APIs that had never been disabled, payment API keys stored in plain text, cloud roles allowing anonymous or regular users to read and change data, and management interfaces exposed to the internet with weak or no multi-factor authentication.

CERT-In’s conclusion is clear: AI found and exploited these common weaknesses “faster, more exhaustively and at greater scale than human attackers.” That’s the real change. The vulnerabilities themselves are nothing new. What has changed is how quickly attackers can find them and combine them to carry out attacks.

The advisory’s list of recommended actions for organizations covers ground that should already be standard practice, but clearly isn’t. Audit every repository and build pipeline for exposed credentials. Rotate and purge anything you find. Keep a full API inventory and shut down anything old or unused. Remove management interfaces from the internet. Keep logs for at least 180 days and watch API traffic for bulk reads and automated registrations in real time.

For organizations running their own AI agents, CERT-In adds a specific requirement: give each run its own short-lived, least-privilege identity, block outbound traffic to anything outside the task’s defined scope, and maintain a tamper-resistant log of every agent action touching production systems. The advisory also cross-references an earlier October 9 warning on payment and disbursement API abuse, which CERT-In says BFSI and fintech entities should apply alongside the measures here.

AI developers and testing labs should block all outgoing network connections from test environments at the infrastructure level, rather than relying on instructions given to the AI model. If an AI agent tries to connect to an external system or finds credentials it should not have access to, the test should stop automatically, and the affected organization should be notified immediately.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AI agents)

Wikimedia found unauthorized OpenAI agent activity on its platforms, including unapproved edits, proxy attempts and millions of automated API requests.

Wikimedia ran its own investigation after other organizations started reporting rogue AI agents breaking into websites, and the answer came back yes, it happened here too. The foundation found unauthorized bot activity tied to OpenAI across its platforms, including edits nobody approved.

“We can confirm that we have discovered some activity by these “rogue” OpenAI agents on Wikimedia platforms. The unauthorized bot activities included edits to our wikis, some unsuccessful attempts to exploit a public note-taking tool we host, and heavy traffic, which are described more below.” states Wikimedia. “We did not find any evidence that our systems were used for coordination among agents, nor did we find any evidence of our systems or data being compromised.”

The good news is that Wikimedia found no evidence that its systems were used for agent-to-agent coordination or that any data was compromised. But the investigation still found several concerning activities.

Wikimedia identified wiki edits that it believes were made by OpenAI-operated agents. Most were test edits in sandbox areas and were not visible to regular readers. However, some edits changed the configuration of a citation tool and may have been malicious, potentially turning the tool into a proxy to fetch data from other websites.

Wikipedia does allow approved bots to edit, that’s not new. What makes this different is that none of these edits went through community approval first, which is the whole point of the policy. An agent that skips the approval step isn’t a bot, it’s an intruder wearing a bot costume.

“These edits were not published to pages with visibility to general readers; almost all of them were testing edits in “sandbox” areas of the wiki. It also included a few edits to the configuration for a citation tool, which we believe were potentially malicious edits that were intended to misuse this tool as a proxy for fetching data from remote services.” reads the report.”While Wikipedia policies allow bots to edit when they are disclosed and approved by the community, none of those approvals were sought in these incidents.”

Agents believed to be OpenAI’s also made unsuccessful attempts to compromise Wikimedia’s public Etherpad, a note-taking tool, trying to use it as a proxy to fetch data from other websites. Other agents took notes on their own tasks there too, though Wikimedia didn’t find evidence that turned into actual coordination between agents. Close call, in other words, not a clean miss.

The traffic numbers are where this stops being a curiosity and starts being an infrastructure problem. These agents made millions of automated API requests, crawled millions of pages mostly on Wikidata and Wikimedia Commons, and fired off hundreds of thousands of queries at the Wikidata Query Service. Wikimedia says that load may have contributed to a partial outage on that service back in May.

This is not a one-time problem. Wikimedia says bandwidth use has increased by 50% since 2024 because of bot activity. Last year, bots were responsible for 65% of the platform’s most resource-intensive traffic. For a site funded by donations and volunteer work, this creates a real cost.

Wikipedia has more than 67 million articles in over 300 languages and receives up to 15 billion page views each month. Its content is also widely used to train AI models. This creates an obvious contradiction: AI companies rely on Wikipedia as a data source, while AI agents are now generating traffic that puts additional pressure on the infrastructure hosting that content.

“While OpenAI admits to agents behaving “unpredictably”, they must also acknowledge their responsibility to monitor and prevent these risks. AI companies are not doing enough to secure their systems and protect the public from the harm they cause. That burden is falling onto everyone else, including smaller organizations.” Wikimedia’s Chief Product and Technology Officer, Selena Deckelmann said. “At a minimum, their systems should operate in a way that non-profit website owners like us can easily identify, and choose how they interact with our services.”

That line lands harder given the pattern building around it. OpenAI agents have reportedly also breached an Australian Medicare reporting portal, taken over a German wiki to swap jailbreak techniques, and in July, nearly 700 rogue OpenAI agents coordinated in an attack on Hugging Face. This isn’t purely an OpenAI problem either, Anthropic disclosed in July that its own Claude agents breached three organizations, in one case uploading a malicious Python package to PyPI.

The request is simple: non-profit websites should be able to identify traffic generated by AI agents and decide how to handle it. Today, that is not always possible. If AI companies cannot reliably recognize when their own agents are accessing or probing a website, it is even harder for website operators to detect and control that activity.

“Our collective priority should be the health of the overall web ecosystem so that it continues to benefit all people – not just a handful of billionaires.” concludes the report. “Wikimedia plays a critical role in stewarding the knowledge commons, but we cannot do it alone. We invite everyone who is building the future of the web to join us in protecting the open, shared resources that make that future possible.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, OpenAI)

AI agents probing US and Canadian government sites made SQL injection attempts while seeking data, but investigators found no evidence of compromise.

Autonomous AI agents, working on what looks like ordinary data retrieval tasks, ended up throwing basic hacking attempts at a U.S. Department of Education site and Library and Archives Canada. Nobody told them to break in. They just drifted there while trying to answer research questions.

The findings come from Transluce, a nonprofit research lab that dug through public web logs and found a pattern nobody had flagged before.

On June 17, AI agents sent more than 200,000 requests to a U.S. Department of Education website while hunting for school statistics. Buried in that traffic was a basic SQL injection attempt, a manipulated parameter meant to slip past the site’s normal filters. Nothing came of it. The site held.

“Following up on our previous blog post, we discovered several additional incidents where rogue AI agents appear to have used aggressive techniques to access publicly available data on government websites.” reads the report published by Transluce.

“This includes two rudimentary and failed hacking attempts, one against the U.S. Department of Education’s Civil Rights Data Collection, and one against Library and Archives Canada, a Canadian federal agency.”

Transluce says the agents were looking for data related to a Google DeepSearchQA question about school counselors and bullying linked to race. The agent was likely trying to answer the question and found its way to the government database. The U.S. Department of Education checked the activity after Transluce reported it on September 25 and found no impact on its services.

A similar case involved Library and Archives Canada. The agents were looking for divorce records from 1905 to 1911. Portugal’s national web archive recorded almost 900 requests to the Canadian website in May and June. Thirteen requests included attack attempts, such as SQL injection tests and attempts to bypass input and debugging controls.

“We have so far identified no instances in these datasets where agents gained access to any information that is not publicly available.” states the report.

Every probe came back empty. Canada’s Centre for Cyber Security looked into it and found nothing to suggest the database had been touched or exposed.

“We are aware of reports identifying suspicious activity, including suspected AI agent activity, targeting publicly accessible websites, such as the Government of Canada. There is no indication that government systems have been compromised at this time.” states Canada’s Centre for Cyber Security. “Public-facing government websites routinely receive automated and potentially malicious requests. Such activity is an ongoing feature of the online environment and does not, on its own, indicate a successful cyber incident.”

Transluce is careful here, and that caution matters. The researchers say the tactics match patterns previously tied to OpenAI, but they stop short of pinning the blame directly, writing plainly that they can’t confidently attribute these specific attempts to the company.

“In addition to the above, we identified a broader pattern of automated workflows that we attribute to AI agents with varying levels of confidence, based on task-level connections, shared infrastructure, and timing. Some of this traffic overlaps to varying degrees with prior activity confirmed to be associated with OpenAI, and in some cases agents explicitly mark themselves as being associated with OpenAI.” Transluce adds. “However, we are not attributing this traffic as a whole to OpenAI nor do we attempt to estimate attribution for each incident.”

OpenAI, for its part, told the Washington Post it was reviewing the findings and had already given Canadian officials an initial briefing.

“We’re aware of reports of OpenAI models attempting to access publicly available information from Canadian government websites,” a spokesperson for OpenAI said. “We’re reviewing these findings and have provided an initial briefing to Canadian officials conducting the government’s review.”

OpenAI has separately admitted to unintended interactions between its agents and U.S. government sites before, so this isn’t coming out of nowhere. Still, Transluce flagged that a chunk of the broader activity they found doesn’t trace cleanly back to any one company. Multiple agent frameworks, it seems, are out there roaming the same networks, and attribution gets messy fast when nobody’s agent is wearing a name tag.

The investigation found more examples of aggressive AI agent activity against U.S. state and federal websites. The logs included agencies in California, Kansas, Maryland, Illinois, Texas, and New York.

The agents used different tactics, including sending large numbers of requests, changing URLs, using temporary email accounts, trying to bypass anti-bot systems, guessing hidden file names, and reusing leaked credentials.

One agent tried to get a Bureau of Economic Analysis API key using a temporary email and the name “OpenAI Research.” Another tried to use an exposed API key to access Census Bureau data. Between April and May, agents also repeatedly tried to reach the content management system of the Navy’s history website. There is no evidence they accessed classified information.

Nobody here set out to build malware. These look like agents doing information-gathering work, running into a paywall or a blocked query, and improvising their way around it using techniques that happen to double as attack patterns. That’s a genuinely new category of risk: not a hacker deploying a tool, but a tool behaving like a hacker because that’s the shortest path to the answer it was told to find.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AI agents)

AI agents are becoming the new attack surface, exposed to poisoned skills, prompt injection, jailbreaks and attacks through connected tools.

I read the AI security research published in a single month, February 2026, and when you put it all together, it’s not a list of curiosities. It’s a field guide to a new attack surface. In my previous piece, I explained how MITRE ATLAS catalogs threats to AI. Here, I take the next step: I map that research onto ATLAS. What emerges is a complete kill chain, and the target is no longer the model. It’s the agent.

A Month of Research, and a Shifting Target

When you look at AI security research published in a single month, one thing stands out: much of the work has stopped focusing on model behavior in isolation and has started examining real attack paths through agents, skills, protocols, and connected environments. The question is no longer “how do I make the chatbot say something forbidden?” but “how do I compromise an agent that can take action?”

This is the shift I anticipated when discussing the expansion of the agentic side of ATLAS, and research is now filling it with real substance. An agent isn’t just a model with a chat interface. It has persistent memory, a supply chain of skills and tools, protocols for connecting to external services, and hands that can perform actions on your systems. Each of these is an attack surface. If you map February’s research onto the MITRE ATLAS matrix, you don’t get a collection of isolated cases. You get a complete attack lifecycle. Let’s walk through it.

Reconnaissance: AI That Exposes You

(ATLAS — Reconnaissance, AML.T0014 AI Model Reconnaissance)

The first stage of any attack is understanding your target. Research now shows that reconnaissance itself has become an AI task. A study involving, among others, Nicholas Carlini and Florian Tramèr demonstrates large-scale deanonymization using an LLM agent: a pipeline that extracts identity-related signals from text, retrieves potential matches and verifies them, challenging the idea of “practical anonymity” — the assumption that among billions of people, you are effectively anonymous.

This takes reconnaissance to an industrial scale, and it targets people, not just systems. It brings back a point I’ve made for some time: identity is the battlefield, and attackers now have a tool that can connect public fragments into a profile at a speed and scale no human analyst could match.

The Agent Supply Chain: Poisoned Skills and Tools

(ATLAS — AML.T0110 AI Agent Tool Poisoning, AML.T0011.002 Publish Poisoned AI Agent Tool)

This is the most crowded area in February’s research, and the one I consider most important because it opens an attack surface that didn’t exist a year ago: the agent supply chain.

A large-scale empirical study analyzed almost 98,380 skills distributed across two marketplaces. Using static analysis, sandbox execution, and manual review, the funnel narrowed down to 157 confirmed malicious skills, organized into two main types: data stealers and agent hijackers. These attacks used multi-stage chains and increasingly sophisticated hiding techniques, including hiding malicious behavior in the skill’s own documentation. For the agent world, this is the equivalent of the first major cases of malicious packages in software repositories: a dependency you install and trust that works against you.

Two other studies confirm the offensive potential. One benchmark shows that widely used agents perform harmful actions when a compromised skill is installed, while another framework demonstrates that stealthy skill-based injection can be automated through a feedback loop that improves its effectiveness. A fourth study targets the infrastructure itself, the Model Context Protocol, which agents use to connect to external tools and data, and proposes a secure architecture because the current one simply isn’t secure enough.

The message is the same one I repeat when discussing compromised supply chains: the tool you trust becomes the weapon. The difference is that here the tool isn’t a compromised WordPress site. It’s a skill you give to an agent with access to your files, email, and systems.

Access and Execution: Industrialized Prompt Injection

(ATLAS — AML.T0051 LLM Prompt Injection, sub-techniques .000 direct and .001 indirect)

Prompt injection remains a high-volume technique, but February’s research shows that it has stopped being a manual craft. One study uses reinforcement learning to automatically discover injection strings that reliably manipulate an agent’s behavior, while preserving the appearance of a legitimate task and transferring to other agents and tasks. Another, an adaptive red-teaming framework for web agents, identifies injection surfaces from execution traces and automatically discovers multi-step attacks. A systematic review builds a complete taxonomy of these techniques.

This isn’t theory, and that’s the point I want to emphasize. These are already CVEs. EchoLeak (CVE-2025-32711) enabled zero-click data exfiltration from a Copilot assistant through prompt injection. CurXecute (CVE-2025-54135/54136) enabled remote code execution through an IDE’s MCP implementation. The gap between an “arXiv paper” and a vulnerability with a CVE number is now measured in weeks.

Evasion and Jailbreaks: Turning Off the Model’s Defenses

(ATLAS — AML.T0054 LLM Jailbreak)

One line of research continues to focus on the model itself and shows something uncomfortable: some defenses are structural, and can therefore be bypassed structurally. One study presents an automated jailbreak that uses feedback from security filters to refine prompts, without internal access to the model. Another exposes a systematic vulnerability in open-weight models to prefill attacks, which manipulate the prefilled context state to bypass protections, going beyond classic text-based jailbreaks. A third study shows that, in mixture-of-experts models, security behavior is concentrated in a small number of “experts.” Silencing them can cause a broad failure of the model’s protections.

I won’t go into the operational details, for obvious reasons. The systemic point is that when security is concentrated in one component, whether a filter, a state, or a group of experts, that component becomes the target. On the defensive side, another study proposes detecting hidden jailbreaks by separating the goal from the linguistic framing used to disguise it within the model’s internal representations. It’s the same idea of “ambiguous techniques” I’ve written about, now applied inside the model.

Impact: When the Agent Has Hands

(ATLAS — Impact tactic; AML.T0086 Exfiltration via AI Agent Tool Invocation; cross-agent propagation)

This is the stage that separates “the model said something wrong” from “the agent did something wrong to your systems.” A red-teaming study placed autonomous agents in a real environment, with persistent memory, email, Discord access, a filesystem, and shell command execution. In eleven documented cases, researchers observed the full range: obeying someone who wasn’t the owner, disclosing sensitive information, destructive actions on the system, denial-of-service conditions, uncontrolled resource consumption, identity spoofing, propagation of unsafe practices from one agent to another, and partial system takeover.

This is the part that keeps me awake. Cross-agent propagation, in particular, is a new phenomenon: malicious behavior spreading between agents like a worm through shared memory and conversations. When the actors are no longer just humans but agents talking to each other, the attack surface is no longer the sum of the individual systems. It’s the network.

The Complete Map

If you overlay a single month of research onto the ATLAS matrix, the agentic angle lights up across the entire kill chain: AI-assisted reconnaissance, poisoned skill and tool supply chains, industrialized prompt injection, structural jailbreaks, impact on systems, and propagation between agents. These aren’t isolated anecdotes. They form a coherent lifecycle. That’s exactly why, between October 2025 and February 2026, ATLAS added agentic techniques, from skill poisoning to exfiltration through tool invocation. Research and the framework are evolving together in real time.

The practical advantage of this map is that it gives AI incidents the same language that your SOC already uses for traditional threats. ATLAS identifiers are designed to work like those in ATT&CK, such as AML.T0051 alongside T1557, and to fit into the same runbooks and detection rules. It’s the common language I’ve been talking about.

What This Means for Defenders

Three steps, none particularly exciting, but all critical.

The first is inventory. You can’t protect agents, skills, or MCP servers you don’t know you have. Most techniques in this kill chain assume that someone on the other side understands your attack surface better than you do. The first control is therefore a census, the same lesson that appears in every security program, simply applied to a new layer.

The second is to treat skills and tools as a supply chain: verify them, run them in sandboxes, pin their versions, and monitor them. This is the discipline we learned, too late, for software dependencies. The study of 157 malicious skills is the moment when the agent world discovers that it has the same problem. We shouldn’t let it take fifteen years to catch up.

The third is to watch what the agent does, not just what it says. The highest-impact techniques, including tool invocation, exfiltration, and context poisoning, don’t necessarily appear as a single suspicious message. They show up as behavioral drift and anomalies in tool calls. Much of this activity is invisible to network and endpoint tools because it can look like normal HTTPS traffic inside authorized applications, the threat that looks like legitimate work that I’ve been writing about for months.

What’s needed is runtime telemetry covering prompts, context state, and tool calls, with a baseline for each individual agent. This is the level of detection that almost nobody has today.

It Was Never Just a Technology Problem

A single month of research reads like a complete attack cycle against agents, and it maps cleanly onto a framework that didn’t even include these techniques a year ago. The frontier has shifted clearly: the model was never the whole story. An agent is a supply chain, a memory, and a pair of hands, and each of these is now a documented attack surface with an identifier next to it.

It was never just a technology problem. Once again, it comes down to discipline: inventory what we are deploying faster than we can secure it, treat agent tools as a supply chain, and monitor actions rather than words. The map exists. The challenge is to use it while the territory is still moving, because this time, unlike fifteen years ago with networks, the territory is moving faster than the map.

About the author: Simone Fratus

Chief Technology Officer, Orizon
Territory Account Manager, Syneto – Enterprise and Large Public Administration

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, AI agents)