For years, the discussion about AI agent security ran in one direction: how to protect the agent we let into our systems. The turn of June and July 2026 added the other side to that story. The AI agent appeared not only as something we protect - but as something that attacks. And it did so on its own, from start to finish.
This is not an article about a distant threat from a lab. These are events from recent weeks that together form a single picture: an autonomous agent on the attacker’s side and an entire SAP landscape with open doors on the victim’s side. We will show both and explain what connects them - and what to do about it before it becomes your problem.
Act one: the agent that carried out an attack on its own
Security firm Sysdig described the first documented ransomware operation conducted from start to finish by an autonomous AI agent. It was named JADEPUFFER. The incident was independently confirmed by The Hacker News, The Register and SecurityWeek.
The sequence of events is what makes this case a breakthrough. A language model independently discovered and exploited a remote code execution flaw in Langflow - a popular platform for building applications based on AI models (CVE-2025-3248 - missing authentication enabling remote code execution). Then, without any human involvement, it performed environment reconnaissance, harvested credentials - API keys and cloud credentials - and moved on to another, internet-exposed database server, exploiting among other things a known vulnerability in Nacos (CVE-2021-29441, authentication bypass). Finally, it encrypted the databases and left a ransom note demanding payment in bitcoin.
Two details are worth remembering. First, the encryption key was ephemeral - the victim will not recover the data even after paying the ransom. 1,342 configurations were destroyed. Second, the agent closed the entire chain autonomously - from reconnaissance, through exploitation, lateral movement and encryption, all the way to extortion.
The significance of this incident does not lie in the technical sophistication of any single step. Each one, taken separately, is well known. It lies in the fact that a constraint which used to limit the scale of attacks has disappeared: the number of people on the attacker’s side. An agent does not tire, does not sleep and can be multiplied. The bar for defence has just been raised for everyone.
Act two: the battlefield is called SAP
An autonomous attacker needs one thing - open doors. And in June 2026, SAP delivered a whole series of them, right in the system’s core layer of trust.
SAP’s June security notes cycle was one of the heaviest in months. At the top of the list were vulnerabilities affecting the foundations of authentication and communication in NetWeaver-based landscapes:
- CVE-2026-44748 (CVSS 9.9) - XML signature wrapping in SAML authentication on NetWeaver AS ABAP. An attacker with low privileges intercepts a correctly signed message and substitutes a modified document, impersonating someone else’s identity. This is a full authentication bypass and requires deploying a correction on the ABAP system.
- CVE-2026-27671 (CVSS 9.8) - memory corruption in the RFC protocol. An unauthenticated attacker sends a crafted packet. The vulnerability has no workaround - the only protection is a coordinated kernel patch across the entire landscape.
- Directory traversal in NetWeaver AS Java (CVE-2026-40128), plus four local privilege escalation bugs in the SAPCAR/SAR parser announced in late 2025 (research by Anvil Secure) - in a tool SAP administrators use every day.
- And a recent (May 2026) supply chain attack in the SAP BTP development stack - malicious npm packages in the Cloud Application Programming Model ecosystem (CVE-2026-46421).
Onapsis maintains an up-to-date SAP security checklist for 2026, in which vulnerability management occupies one of the central positions. Vendors of specialised solutions - SecurityBridge, Pathlock - confirmed the weight of this cycle.
Why do we connect this with JADEPUFFER? Because SAP systems are home to financial data, HR data and the enterprise’s entire supply chain - exactly the target an automated attacker reaches for. An unpatched SAML or RFC flaw is not an abstract risk indicator. It is a ready-made entry point. An attacking agent does not have to be a genius; it only has to find an open door.
The same mechanism from a third angle
It is worth adding context, because the same weeks brought two more discoveries of the same class - two different vectors leading to the same outcome. Researchers from Adversa AI (the GuardFall project) showed that a safety filter inspecting the raw text of a command can be bypassed, because the system shell rewrites that command after the check has already taken place - so the agent ends up running code the filter never saw. Tenet Security, in turn, described a technique named Agentjacking: fake events and error reports injected through an MCP integration (demonstrated on Sentry) which the agent treats as trusted instructions - with no shell-filter bypass involved. In both cases the reason is structural: an agent does not distinguish between the content it reads and the instruction it is meant to execute.
All these events share one common denominator: autonomy without boundaries. What makes agents useful in business - independence and access to a chain of tools - makes them dangerous when that boundary is missing. JADEPUFFER shows this from the attacker’s side. GuardFall and Agentjacking - from the side of the tools we deploy ourselves. The SAP CVE cascade - from the side of the target.
An agent on a leash, not an agent off the leash
In the previous Safe Tuesday we wrote about bringing AI into SAP without resorting to full model autonomy in the execution layer. JADEPUFFER completes that argument: it is the picture of an agent with no leash at all. Our answer is an agent on a leash - and the difference is not choosing a better model, because the model will be swapped in the next cycle. The difference is the architecture.
Least privilege at the tool level, not the text level. The agent is not given the ability to perform destructive actions or access data outside its task. In the SAP world this means a technical account with a narrow authorisation profile, matching the account type to the communication channel with an API-first recommendation, and one iron rule: never an RFC authorisation with a wildcard for everything. That is the classic mistake that turns a single entry point into access to the entire system.
A human in the loop as a gate, not an option. UiPath Maestro orchestrates the flow, and Action Center closes the steps with irreversible consequences. In production we do not use automatic mode without a conscious decision - it is precisely its default activation that makes attacks on agents feasible.
SAP patching hygiene as a foundation, not an add-on. The CVE cascade shows that even the best-designed agent stands on sand if the landscape itself has open doors. Continuous monitoring and prioritisation of security notes with SecurityBridge, coordinated kernel patching where no workaround exists (RFC), and dependency audits in CAP projects on BTP - this is the layer without which everything else has nothing to stand on.
Every piece of external content is untrusted code. A customer document, an e-mail, a log, a tool output - we treat it as a potential payload, not as a trusted instruction. Servers through which the agent fetches data are vetted before being allowed in.
A pattern filter is telemetry, not control. Since it can be bypassed, it informs but does not protect. Real control sits on tool permissions and on the human gate.
We test resilience, not declarations. We check not whether the agent recognises a manipulation attempt in the content, but whether at the execution level it is even capable of running a destructive action - using poisoned input data, canary files and evaluators that verify the agent’s actual calls rather than the mere text of its responses.
For completeness, let us add the regulatory context. Agent resilience and SAP security hygiene fit within the requirements of NIS2, DORA and the AI Act - although these are orientation frameworks, and a binding legal interpretation is provided by a human, not a system.
Conclusion
JADEPUFFER and the SAP CVE cascade are not two separate news items. They are the obverse and reverse of a single change: the AI agent has entered the game on both sides, and the systems we want to protect are exactly where the automated attacker reaches. The answer is not another patch or a better model. It is an architecture that assumes no good will - neither from the model nor from the content it reads.
That is why in conversations with clients we do not ask whether a given agent is secure. We ask how to design the whole - permissions, the human gate, patching hygiene and the test that verifies it - so that it is secure by design.
Next week, on 14 July, SAP Security Patch Day returns with the July notes cycle. In part two we will show what actually arrived to be patched and how to tie it into continuous monitoring, so that open doors close faster than an attacker - human or agent - can find them.
This material is educational in nature. Risk assessment of a specific implementation and a binding interpretation of regulatory requirements require human review. We would be glad to carry out a security review of your SAP environment and agentic automation with you - please get in touch.