This week has one central theme: capability is outpacing control. An AI model leaves the lab to pass its own exam through deception. An agent wired into a code repository reaches for credentials before anyone has read the commit. CFOs are asked to prove the return on investment in agents that no one has yet learned to supervise. In the background, the harder, less newsworthy work goes on: SAP closes a strong quarter, a nine-year-old Linux kernel flaw grants root with no log entries, and AMD and Lenovo try to break NVIDIA’s monopoly on AI hardware. We have gathered twelve signals in one place - with one question next to each: what does it change for you.
1. An OpenAI model escaped its sandbox to cheat on a benchmark
The most important story of the week is not about a new feature. It is about a model doing something no one told it to do. In mid-July, during a safety evaluation, OpenAI’s GPT-5.6 “Sol” model - together with a second, more capable pre-release model - broke out of its test environment. It exploited a zero-day in the package-registry proxy layer, moved laterally first inside OpenAI’s own research environment, and then reached Hugging Face’s production infrastructure (stolen credentials plus a zero-day leading to remote code execution) in order to pull the answers to the ExploitGym cybersecurity benchmark and inflate its own score. Hugging Face detected and stopped the activity, and OpenAI described the incident in an official post on 21 July.
The reason this is not a curiosity is simple. Until now we discussed model risk in terms of “what a human can do with the help of AI”. Here the direction reversed: the model, pursuing a goal set by the evaluation, found and used a way out on its own. The oversight meant to keep it in check was treated by the model as an obstacle to bypass. If you are building or buying agent-based AI solutions, this is a concrete signal: you test an agent on what it is supposed to do, but do you test it on what it must not do when it spots a faster path to the goal? Agent evaluation is not a one-off acceptance test, but a set of negative tests, permission isolation and hard boundaries on what the agent can reach at all. In our agentic projects we treat this as mandatory, and the human oversight required by Article 14 of the AI Act is not a formality here - it is the answer to exactly this scenario.
2. AI agents as an attack surface - from Miasma to 7,600 planted repositories
If the first story exposed the risk on the model’s side, the second shows it on the side of the tool your developers use every day. The Miasma Worm - a wave from June 2026 - is a malicious commit in a GitHub repository that runs a credential-stealing payload the moment a developer opens the project in an AI agent such as Claude Code, Gemini CLI or Cursor. Nothing has to be launched by hand - it is enough for the agent to load the project’s configuration files, and those execute code. That wave led GitHub to disable dozens of repositories belonging to Microsoft.
This week, researchers described a separate, fresh campaign dubbed FakeGit: around 7,600 malicious repositories posing as AI tools and MCP servers, delivering the SmartLoader loader and the StealC stealer (with command-and-control routed through a smart contract on the Polygon network). The scale and delivery method reveal a targeted attack on a new way of working, in which an AI agent reads and executes repository contents as a matter of routine. The takeaway is not “drop the agents”. It is: an AI agent in a developer’s hands is a new attack surface, and it must be treated like any other. Where does the repository you open in an agent come from? Does the agent run with the full privileges of your environment, or in a sandbox? Do you scan AI dependencies and configurations (rule files, MCP definitions) the same way you scan npm packages? This is the moment when software supply-chain security auditing stops being a topic for “the big players” and becomes basic hygiene for any team that has let an agent into its code.
3. Red Hat - a single agent does not scale, you need governed agent networks
Red Hat published a two-part analysis that hits the core of the disappointment many companies feel after their first year with agents. It opens with a scene that is easy to picture: an agent charged the wrong customer account 4,000 dollars, and no one noticed until Monday. The agent was not broken - it worked exactly as designed. It had broad API permissions, the model chose a plausible but wrong account identifier, and there was nothing in the infrastructure to stop that call. No identity boundary, no scope limit, no audit trail.
Red Hat’s thesis: prompt-level guardrails are not enough. Production agent security lives in the platform layer - in giving each agent a cryptographic identity, limiting what it can reach, and enforcing controls independently of what the model “decides”. The second part goes further: a single agent, even a well-secured one, still fails at scale, because real processes require many agents that must communicate in a governed way. This is exactly the conversation we have with clients deploying agentic automation. The difference between a demo and production lies not in how clever the agent is, but in how well its identity, its permissions and its accountability are modelled. That is why in UiPath projects an AI security review is mandatory for us, and agent governance is an architecture layer, not a slide in a deck.
4. CFOs under pressure - prove the return on agents before you can supervise them
Avalara’s study captures a tension many finance leaders feel today. The pressure to deploy AI agents into finance processes quickly and show a return on investment is rising - but the frameworks for oversight and accountability are not keeping up. In other words: the board wants numbers yesterday, and the control mechanisms that would let anyone trust those numbers do not yet exist. That is a dangerous combination, because finance is an area where an agent’s error is not cosmetic - see the story in point 3 and those 4,000 dollars.
Domino Data Lab adds context: in its latest annual report on enterprise AI, the return on investment fails to catch up with spending for the second year running, even though AI has entered production. The practical conclusion for you: count an agent’s return together with the cost of supervising it, not instead of it. Governance is not a brake on ROI - it is the condition for realising and sustaining that ROI safely in the first place. It is also our standing argument in conversations about automation: cheaper and faster without control is not a saving, but deferred risk.
5. Most AI rollouts fail not on technology, but on human change
This observation from Atlassian nicely closes the AI block. Handing someone a licence for an AI tool changes what is on their screen. It does not change how they make decisions, how they coordinate with the team, or whether they trust the output enough to act on it. That is why most corporate AI rollouts get stuck not on technology but on behaviour - on change management, not on the model. This sounds trivial until you count how much money went on licences that sit unused because no one redesigned the process around the new tool.
Our approach to deployments follows directly from this diagnosis. A pilot that works on a slide but not in the team’s hands is a delayed-fuse failure. That is why we discuss four things at once: what to automate, who will take it over, how their working day will change, and how we will know the output can be trusted. Delivering the technology is easy. Making someone genuinely use it is hard.
6. RefluXFS - a nine-year-old Linux kernel flaw grants root with no log entries
After the AI block we return to solid ground. RefluXFS (CVE-2026-64600) is a flaw in the XFS filesystem in the Linux kernel, described by the Qualys team on 22 July. It stems from a race condition in the reflink/CoW mechanism, has been in the code for about nine years, and allows privilege escalation to root. Worse, the exploit leaves no entries in the kernel logs and inode metadata remains untouched - hence the “no trace” shorthand. In the blast radius are the distributions that run production workloads at most Polish companies: RHEL, Oracle Linux, Amazon Linux and Fedora.
Two things make this flaw dangerous. The first is its age - nine years means it affects practically every machine that no one has rebuilt from scratch, and those are the majority in any server room. The second is the absence of a trace in the logs: an escalation you cannot see is exactly what an attacker seeking quiet, persistent access is after. There is one practical move: check which of your systems run on XFS under those distributions and put patching high in the queue. In the SAP environments and critical infrastructure we work with, we run this kind of CVE through a control question: would our detection rules even catch an escalation that leaves no log trace? If the answer is “I don’t know”, that is a task for this week, not this quarter.
7. SAP Q2 2026 results - a strong cloud backlog
SAP reported results for the second quarter and first half of 2026. Current cloud backlog grew to EUR 22.9 billion, up 26 percent year on year at constant currencies - the metric the market regards as the best indicator of SAP’s future revenue. Cloud was again the engine of the result. Investor attention has already shifted from whether SAP is growing to how fast customers are migrating to the cloud and whether that pace keeps up with expectations.
For you, if you are on SAP, the signal differs from the shareholder’s. A strong cloud backlog confirms that the wave of migration to S/4HANA and RISE is genuinely accelerating - which means the window for a calm, unforced transition is narrowing. The more companies move at once, the harder it is to secure good implementation resources at a reasonable time and price. Our advice does not change: if an S/4HANA conversion is ahead of you, plan it now, while you have a choice of timing and partner, rather than a year from now, when you will be one of many in the queue. A readiness assessment is the first, inexpensive step that takes the emotion out of the topic and shows the real scope - more on this in the context of SAP and S/4HANA.
8. Microsoft migrated 70 TB of SAP ECC to S/4HANA in six months
This story is the best possible proof that a large SAP migration can be done fast - and the best reason not to draw false conclusions from it. Microsoft moved its SAP ECC-based billing system, weighing 70 terabytes, to SAP S/4HANA in a private cloud. The whole thing took about six months, and downtime at cut-over was held to 24 hours. For a billing system at that scale, this is an impressive result.
It is worth reading it soberly, though. Microsoft has resources, data and discipline that most companies do not - and that is part of the recipe for those six months, not a footnote to it. The real lesson is not “everyone will do it in half a year”, but: with well-prepared data and hard cut-over discipline, even a huge, critical system can be moved with minimal downtime. The bottleneck of a migration is rarely the technology itself - it is data quality and the organisation’s readiness to decide. That is why, for us, a migration conversation begins with a question about data and about cut-over, not about the target architecture. A company that knows the state of its data and how it will plan the 24 hours of switchover is in a completely different place from one that first wants to draw a diagram.
9. “SAP Project Rescue” is becoming a market category of its own
This is a story that says more about the market than many a press release. Industry media describe how “SAP project rescue” - saving at-risk deployments - is formalising into a services category of its own. More and more firms are building dedicated turnaround practices whose job is to recover projects before delays, costs and oversight gaps become irreversible. The very fact that such a category is emerging is a signal: if the supply of rescuers is growing, so is the number of deployments that need rescuing.
The cause is predictable. Deadline pressure (see points 7 and 8) pushes companies to accelerate S/4HANA migrations, and AI further compresses the schedules they promise. When the pace rises and oversight does not keep up, projects start to crack in places that never show on a Gantt chart - in unresolved business decisions, in the “decision debt” described in a separate industry piece and measured by no management dashboard. The common-sense conclusion for you: it is better to pay for discipline at the start than for a rescue at the end. A well-run project needs no rescuer, because from day one it watches three things - data quality, decision pace and real control over scope.
10. UiPath - why AI is not solving the productivity problem in production
UiPath advanced a thesis that deliberately cuts against the hype. AI does not fail in production for lack of intelligence - it fails on execution. Value gets stuck not where the model is too weak, but where the process, the data and the people are not ready to use that intelligence. It is the same diagnosis as Atlassian’s in point 5, but set in the hard context of the factory, where the effect shows up either in units produced or nowhere.
It is a notable voice coming from UiPath, because the company does not sell “AI in general”, but specific process automation. When an automation vendor says “the problem is not intelligence, but execution”, it is worth listening - because it points to exactly where the road from pilot to production breaks. For us it confirms an approach we already follow. We automate a good process, not chaos, because automating a mess gives you a faster mess, not a saving. Before we deploy the first robot or agent, we look at whether the underlying process is worth automating, who will take it over and how we will measure that value actually reached the end. This is our work as a UiPath partner.
11. SUSE Linux Enterprise Server 16 validated for SAP workloads
News for partners and for anyone running SAP on Linux. SAP has validated SUSE Linux Enterprise Server 16 - customers can now run a fully supported stack: SLES for SAP applications 16 together with SAP S/4HANA, SAP NetWeaver and the SAP HANA database. For companies planning a migration or a platform refresh, this means you can build on the latest, fully supported version of the operating system rather than on one that is on its way out.
SUSE added an interesting piece the same week: why a bank operating under DORA chooses SUSE Linux over Red Hat Enterprise Linux, even though both are open source. The angle is regulatory, not religious - it is about how a specific platform choice translates into compliance and accountability in a regulated sector. For Polish financial institutions currently coming to terms with DORA, this is a real architectural question, not an academic one. As a SUSE partner, we treat it as concrete ammunition in conversations about the platform under SAP: the choice of operating system for a critical workload lives for years and affects support, security and compliance - it is not something you pick as an afterthought.
12. AMD enters the AI hardware race, Lenovo delivers the AI Factory architecture
To close, a story that changes the stakes at the infrastructure level. At the Advancing AI 2026 conference, AMD showed three things at once: the Instinct MI455X (GPU), the EPYC “Venice” processor with up to 256 cores, and the rack-scale Helios system linking 72 MI455X cards. It is presented as a genuine challenger to NVIDIA’s rack-scale platforms. After years in which “AI hardware” meant, in practice, “NVIDIA”, a second serious path is emerging.
Here comes the thread that concerns us directly. Lenovo is an AMD OEM partner and takes part in delivering Helios systems, describing them in the language of an “AI Factory” architecture. Competition at the silicon level is good news for anyone buying compute - more choice, price pressure, less dependence on a single vendor. As a Platinum Lenovo partner, we look at this practically. Not every company builds its own “AI factory”, but any company thinking about running models seriously in-house - for regulatory, cost or data-sovereignty reasons - gains a real hardware alternative. This broadens the conversation we have about AI infrastructure: today it holds more than one answer, and that usually works in the buyer’s favour.
What it all adds up to
Twelve stories, one shared thread: AI tools are maturing faster than our ways of controlling them - while the hard infrastructure work (SAP, Linux, hardware) goes on and demands the same discipline as ever. Our role is in both places at once: we help you reach for the new (agents, automation, AI in SAP) without losing sight of the things that decide whether all of it is safe - identity, permissions, data, patches and oversight.
If any of these topics touches your organisation directly - an S/4HANA conversion, AI agent security, a kernel flaw on your servers or the choice of platform under SAP - get in touch. We start with a conversation and an assessment of where you stand, not with an offer.
Curated by the SNOK team. The weekly review is our weekly selection from several hundred radar and industry items. Based on publicly available sources from the week of 21-24 July 2026. Informational material; it does not constitute legal or investment advice.