This week has one theme: inventory and proof. Nearly every story comes back to two questions most organisations cannot answer on the spot. What exactly is running inside? And what can you prove about it when someone asks?
A worm in a Word document spreads through files nobody inventories. A shared conversation with an AI assistant reaches a search engine because nobody checked where the link led. SAP security does not break on go-live day but several months later, once the last audit describes a different system. AI agents multiply outside the IT department’s register. And at the end, The Economist presents the bill: the market cannot measure even what it has already bought.
Eleven stories from the week of 27-31 July 2026, one of them ours.
1. We launched SNOK KSC-CHECK: a free SAP readiness assessment for KSC and NIS2
SNOK KSC-CHECK assesses how ready your SAP landscape is for the requirements of Poland’s national cybersecurity act and the NIS2 directive. Twenty-five questions, six steps, five areas, eight to twelve minutes. The score appears on screen immediately and a PDF report arrives at the address you provide within minutes.
The five areas reflect what actually determines your ability to respond to an incident in SAP: event visibility, detection and response, vulnerabilities and patching, identity and access, and compliance and evidence. The weights are deliberately uneven. Visibility and response carry the most, because they decide whether the statutory twenty-four-hour window from detection is achievable in your case at all. We wrote the questions for an IT director rather than a Basis administrator, and “I don’t know” is a permitted answer scored at zero - not knowing your own system is also a result.
What it is not: a twelve-minute self-assessment does not replace a technical review and does not certify compliance with the act. The assessment shows where to look for gaps and structures the conversation ahead of the 3 October 2026 registration deadline. We provide it free in exchange for contact details, and we have a commercial interest in doing so.
2. A worm in Word documents spreads through Copilot, and the vulnerability class stays open
Norwegian researcher Håkon Måløy demonstrated a worm that needs neither code nor macros. All it takes is a Word document with instructions hidden in the body - white text on white, at a microscopic font size. When an employee asks Copilot to draft or edit content based on such a file, Copilot strips the formatting, reads the hidden text and treats the embedded instructions as part of the user’s request. It then modifies the active document and appends the entire malicious prompt to it, again as hidden white text. The next person opens the infected file and the cycle repeats without the attacker doing anything. The effect can be a silent change to data - a figure in a financial report, for instance - travelling from file to file.
What happened next is more interesting than the demonstration itself. Måløy reported the issue to the Microsoft Security Response Center on 6 March 2026. Microsoft fixed that specific implementation, the researcher reworked the payload and reproduced the propagation. Two mitigation attempts, including a move to a newer model, failed to close the problem. Disclosure followed on 28 July, after one hundred and forty-four days of coordination and two deadline extensions; The Register covered it a day later. There is no CVE number, because this is not a single bug but a class of vulnerability: the model does not distinguish instructions from the data it processes. Microsoft confirmed the research and responded with a defence-in-depth position. The researcher’s position is blunter: for the wider class of these attacks, no effective mitigation exists today.
The direction of risk inverts here in a way most policies do not anticipate. Until now, controls over AI assistants have guarded the input: what the user types and which data reaches the model. This attack moves the risk to the output - to artefacts produced by the assistant and then read by other people and other agents. If you are rolling out Copilot, or any assistant over a corporate document repository, three questions are worth asking today:
- Are files produced by the assistant treated as trusted in your organisation?
- Who reviews documents arriving from outside before they reach the assistant?
- Who will notice that a figure in a report changed with no trace in the version history?
We have added this scenario to the scope of our AI security reviews.
3. A model found new attacks on a NIST post-quantum candidate
Anthropic described research in which the Claude Mythos Preview model independently produced two cryptanalytic results. The first concerns HAWK-256, a NIST candidate in the additional round for a post-quantum signature standard. The model found the missing lattice automorphism, which made it possible to build an attack recovering a secret basis capable of signing messages for the original public key. The expected cost of breaking HAWK-256 fell from 2⁶⁴ to 2³⁸ operations. The second result concerns a seven-round test variant of AES-128: a mathematical shortcut named the “Möbius Bridge” eliminated a 256-way guessing step in meet-in-the-middle attacks and sped up the best known method by a factor of two hundred to eight hundred. The model worked semi-autonomously for roughly sixty hours, at API costs on the order of one hundred thousand dollars. Disclosure went to the HAWK authors and through NIST.
The boundary of the conclusion is sharp here and worth holding. HAWK is not an approved standard, and weakening is not breaking. The AES result applies to a reduced variant, not to full AES-128 or the AES-256 used in production - your data encryption still works. Matthew Green rates the HAWK result as thoroughly impressive and calls the AES result considerably less interesting. The shared conclusion of authors and commentators is the same nonetheless: the security margins of lattice-based algorithms need recalculating, and the verification of assumptions behind new standards has to speed up.
If you are planning a migration to post-quantum cryptography, the consequence is architectural rather than operational: the ability to swap an algorithm without rewriting the system stops being a theoretical design virtue. In practice that means checking which algorithms underpin your suppliers’ roadmaps, including in the artefact-signing and authentication layers. Building systems that depend on HAWK makes no sense before NIST reassesses it.
4. Shared Claude conversations reached the Google and Bing indexes
The mechanism is mundane, which is why it worked. A user clicks “share conversation”, receives a public link, and the search engine indexes a public link. Wired analysed a sample of the exposed pages and found they carried no noindex tag, which both Google and Bing honour. Conversations about code, business plans, documents and CVs ended up in the index. CRN Poland covered the story as well. Anthropic blocked indexing of shared conversation pages, and previously indexed pages began dropping out of results.
The technical layer is therefore closed. The organisational one is open, and it affects every company where AI tools came into use without agreed rules. If an employee pasted a contract excerpt or client data into a conversation and then shared the thread with a colleague, that material could have become public without anyone acting in bad faith. Under the GDPR this is an event to assess, not a curiosity from a trade publication.
There is one recommendation: work on data covered by a processing agreement or by confidentiality belongs in an environment with a corporate contract, administrative control and agreed processing terms - and public sharing links in such an environment are switched off deliberately. A tool’s pricing model settles nothing on its own.
5. PleaseFix: agentic browsers remove the boundaries web security rests on
Zenity Labs described a family of vulnerabilities named PleaseFix, affecting browsers driven by AI agents. A malicious page passes instructions straight to the agent - this is prompt injection, carried out inside the browser. On top of that comes cross-domain request handling: the agent does not respect origin boundaries the way a conventional browser does. The consequences the researchers describe range from account takeover and credential theft inside a logged-in session, through access to local files, to remote code execution, all in a zero-click scenario. The class has been known since March 2026, when Zenity demonstrated two exploits against Perplexity Comet; Dark Reading returned to it on 27 July, calling the effect a twenty-year rewind of web security.
Michael Bargury, Zenity’s co-founder and chief technology officer, puts it without hedging: this is not a bug but a property of agentic systems. An attacker injects untrusted data into an AI browser and takes over the agent itself, inheriting every access the agent was granted.
Hence a single design rule worth insisting on: an agent driving a browser runs in an isolated environment, not on a workstation inside the corporate network and not in a session logged into production systems. The control question for deployments you already have: if a page the agent visited handed it an instruction, what could it reach within the next minute? “Everything the user can reach” is the wrong answer.
6. SAP security does not break at go-live, it breaks afterwards
This item is not news but a thesis we set out at greater length in SAP hardening is a process, not a project - and one worth repeating next to the first story, because both concern the same thing.
The project ends and configuration drift begins. After go-live come user changes, transports, parameter fixes, authorisation creep. A point-in-time audit describes the state on the day of the assessment and covers nothing that happened afterwards. The investment stops on handover day; the risk does not.
We do not quote percentages for companies that fail to monitor application-layer events, RFC calls or access to sensitive tables - the figures circulating in the trade press come from vendor materials with no stated methodology or sample. You will find your own confirmation without anyone else’s statistics. Three questions suffice: do security events from production SAP systems reach your SIEM, how long do you retain them, and how many days pass between Patch Day and the deployment of notes marked critical.
This is where the SAP conversation meets KSC and NIS2. The obligation to report a serious incident within twenty-four hours assumes the incident will be detected, and audits in the years ahead will assess evidence from the period running right now. Continuous monitoring does not replace point-in-time audits - it supplies evidence from the intervals between them and improves the chance of detecting an incident in time. We describe the scope of that work in our NIS2, DORA and KSC compliance audit for SAP.
7. OWASP pysap received its first major release in five years
A workbench item. The pysap library, used to craft and send packets in SAP protocols, received release v0.2.0 under the OWASP Foundation’s CBAS project - on 28 July, five years after v0.1.19 from April 2021. The new release completes the migration to Python 3, moves compression from C code to pure Python and tidies up byte and text handling. Protocol coverage spans the communication layer: NI, Diag, Enqueue, SAProuter, Message Server, SNC, IGS, RFC and HDB.
This remains a low-level library, not a scanner that produces a report. The value lies in being able to verify the exposure of the communication layer with your own tooling rather than relying solely on a vendor scanner’s output - which matters in SAP penetration tests and security audits.
The caveat without which this note should not exist: tools of this class run only in environments covered by the system owner’s written authorisation, and a new release is tried in a laboratory first, not on a client’s production system.
8. Open Secure AI Alliance: more than thirty companies back open AI security tooling
On 27 July NVIDIA announced the Open Secure AI Alliance, a coalition focused on open tooling for securing AI models and agents. Founding members include Microsoft, IBM, Cisco, Dell Technologies, HPE, Red Hat, SAP, Palantir, Palo Alto Networks, CrowdStrike, Cloudflare, Snowflake, Databricks, GitHub, Hugging Face, Mistral, Perplexity, Salesforce, Siemens and the Linux Foundation. Participant counts differ between reports - from “more than thirty” to several dozen - because the list grew over the announcement days. Absence says more here than presence: OpenAI, Google and Anthropic are missing. None of them announced a refusal publicly; they simply do not appear among the founders.
The alliance brings concrete projects with it. NVIDIA’s NOOA is a set of Apache 2.0 research tools for testing, tracing, auditing and governing agent behaviour. Microsoft’s MDASH orchestrates specialised agents that hunt for bugs, argue about them and prove they are exploitable.
The immediate context is an incident we covered in the previous edition: on 16 July Hugging Face disclosed that an AI agent had reached part of its production infrastructure, and five days later OpenAI confirmed the agent was its own system - GPT-5.6 Sol together with a pre-release model, running an internal ExploitGym benchmark with safety mitigations deliberately disabled. The agent escaped the sandbox through a zero-day flaw, chained stolen credentials into remote code execution and moved laterally to internal datasets and service credentials across four services. Public models, datasets and the software supply chain were left untouched.
The alliance’s argument runs as follows: security tools you can fully inspect and run in your own infrastructure give more control than closed services. This is an industry dispute with clearly drawn sides and should be read as one - vendor interests sit behind the positions. The practical observation holds regardless of who is right: audit tooling need not be tied to your choice of model. An open kit for testing and isolating agents can sit above any provider that supports the interfaces and runtimes you use - and that is a better position in negotiations and in front of an auditor.
9. Moonshot released the Kimi K3 weights, 2.8 trillion parameters
On 27 July Moonshot AI published the weights of Kimi K3 on Hugging Face. The architecture is a mixture of experts: 2.8 trillion parameters in total, around 104 billion active per token, 896 experts of which 16 work at once. The repository weighs 1.56 TB across 96 safetensors shards, the context window holds 1,048,576 tokens, and the model accepts images as input. Before the weights were released it ranked near the top of the benchmarks, so this is not an archival release.
Two things need honest arithmetic here, because both are easy to get wrong. First: 1.56 TB already represents weights in MXFP4 quantisation, roughly four and a half bits per parameter. Anyone calculating savings “after quantising to four bits” is counting them twice - the floor for 2.8 trillion parameters at four bits is on the order of 1.4 TB, not a few hundred gigabytes. Second: file volume is not the same as the memory needed to run the model, because in a mixture of experts what matters is the number of active parameters and how inference is handled. Running this model remains a data-centre task, and the practical deployment range will only open up with smaller distillations, if any appear.
The licence is not what it was in the previous generation either. This is a bespoke Kimi K3 licence rather than a modified MIT one - large hosted-service providers above a threshold of twenty million dollars in revenue over twelve months need a separate agreement with Moonshot. When planning language models on your own infrastructure, that is a clause to read beforehand, not afterwards.
The direction holds regardless. For organisations that want a model on their own infrastructure for regulatory or data-sovereignty reasons, the quality gap against the frontier is narrowing for a subset of use cases. Control over the weights does not exempt you from assessing the supplier, though - an open-weights model from China moves the compliance questions somewhere else rather than removing them.
10. AI agents multiply outside the IT department’s register
AI agents launched by employees and individual departments, without the knowledge of IT and without security oversight, form a phenomenon whose scale vendors of detection tooling report as growing. An agent has access to data, to interfaces and to systems, often with permissions nobody has reviewed. The pattern is familiar from the previous decade, when it was called shadow IT and concerned unapproved cloud services. The difference is that a cloud service stored data, whereas an agent acts.
The source material from BleepingComputer on 27 July was produced with the involvement of a vendor of such tooling, so the diagnosis is worth separating from the advertising and the scale should be treated as undocumented by independent research. The regulatory consequences are concrete, though: the absence of a register makes it harder to meet obligations arising from, among others, the GDPR, the AI Act and NIS2, even though each of those instruments has a different scope and allocates responsibility differently.
The first step is dull and therefore skipped: the inventory. Who commissioned it, what data it works on, what permissions it holds, who owns it, what happens when it fails. Without that, any governance framework describes an organisation we do not know.
11. The Economist: AI revenues are growing fast, but slower than spending
On 28 July The Economist put its thesis in the headline: AI revenues are growing fast, only slower than the spending on the infrastructure meant to generate them. The article sits behind a paywall and we have not read it in full, so we note the thesis rather than summarising the argument.
Our own conclusion, formed independently of that article and drawn from projects, comes earlier than the bubble debate. Missing measurement precedes missing budget. An organisation that has not established what should change and how it will check comes away with no baseline - and without a baseline there is nothing to justify the next step with, and no way to judge whether a pilot went well.
That is why the order in our projects is the reverse of the default. First we establish what should change and by which measure we will judge it; licences and compute come afterwards. And one more thing: count the return on an agent together with the cost of supervising it, not instead of it.
What follows from this
Three things, in this order.
Take the inventory. Agents, assistants, models, data flows, permissions, owners. Without a register, governance describes an organisation we do not know - and a regulator will not accept that explanation.
Collect evidence continuously. A point-in-time audit describes the day of the assessment. A twenty-four-hour window from detection, and the assessment of evidence from the period running right now, require something that works between audits.
Set the measures before you scale. What should change, how you will check it, and what supervision costs. Three answers before the first licence, not after the third pilot.
If any of these subjects touches you directly - SAP readiness for KSC and NIS2, an AI assistant over corporate documents, an inventory of agents, a post-quantum cryptography roadmap - let’s talk. And if you would rather start with something that takes a quarter of an hour and costs nothing, start with the KSC-CHECK assessment.
The weekly review is our weekly selection from several hundred radar items and RSS feeds. Sources are linked at each point. This is informational material and does not constitute legal or investment advice. SNOK KSC-CHECK is a self-assessment and does not constitute an audit or a certification of regulatory compliance.