Mac Souverain (English)

A fake Zoom update empties your iCloud Keychain

Mac Souverain — Tue, 28 Jul 2026 09:15:00 GMT

A contact you know invites you to a video call on Telegram, except their account has been hijacked. During the call, a fake "Zoom SDK Update" pops up, you click to fix your mic, and **a stealer siphons your browser keys** out of your iCloud Keychain. BlueNoroff, North Korea, zero flaw exploited, 100% social engineering. It's the third ClickFix on macOS in six weeks.

What you need to do

1. An install prompt in the middle of a meeting, you refuse. No video call ships you an "SDK Update" mid-call.

2. A meeting link, even from a real contact, verify it through another channel. The Telegram account on the other end may be compromised.

3. An outbound firewall, Little Snitch or LuLu, sees the exfil leave for Telegram while the stealer empties your keychain.

What’s really happening mid-call

BlueNoroff, the North Korean banner that targets crypto professionals, exploits no flaw. Zero exploit, zero CVE. Just social engineering, scaled into an industrial chain. The research comes from JUMPSEC, the “ClickFake Interview” cluster is tracked by Sekoia, and The Hacker News picked it up on July 24, 2026.

Here’s how it goes. A contact you’ve met in person messages you on Telegram, except their account has been hijacked. They send you a Calendly link in their name, which redirects you to a typosquatted Zoom or Teams domain, us.zoom.06webin.us. You type your name, you allow the camera, and the kit gets to work behind your back. It captures your video stream via mediasoup WebRTC and profiles the crypto wallet extensions installed in your browser. Then a fake message, “your mic isn’t working”, followed by a “Zoom SDK Update” prompt. You click to fix your mic, you install the payload.

On macOS, the rest unfolds without you. A shell script downloads a fake Teams or Zoom installer, a stealer extracts Chrome’s master keys from your macOS login keychain, where Chrome stores its encryption key, the ones that unlock your crypto wallet extensions, and exfiltrates everything through a Telegram channel named “Aurora”, before dropping further payloads. On the Windows side, the variant disables Defender via a PowerShell loader and hunts for Telegram sessions in Chrome, Edge, Brave and Firefox. Same actor, two chains.

Two details change the scale. The video calls are faked with deepfakes, AI-generated faces layered over real body language, captured from earlier victims. And the mechanism self-propagates, each compromised Telegram account becomes the trusted sender for the next one. Five versions of the kit have been spotted between May 31 and July 14, 2026, the operator is tied to the Telegram bot @alchemy_john_mac. This is no one-off, it’s a factory that iterates.

The technique has a name, ClickFix, and it already drags a trail of victims behind it.

Read next: ClickFix, the fake fix that makes you launch the malware yourself

The third ClickFix on macOS in six weeks

Do the math. CrashStealer in July, ClickLock before it, now BlueNoroff. Three times in six weeks the same pattern has hit macOS, one harmless gesture that triggers the install. The vector is going industrial, and this version aims straight at your keychain, where macOS stores your browser’s keys.

Read next: An Apple-notarized malware slips past Gatekeeper

What protects you here is neither antivirus nor notarization. It’s a behavioral rule, simple and absolute, never install a binary offered to you during a meeting. Zoom doesn’t ship you an “SDK Update” mid-call. Neither does Teams. An update that surfaces during a video call is not an update, it’s the payload.

There’s a stack angle, provided you’re honest about its reach. Proton Meet is end-to-end encrypted and runs in your browser, with no native client to install. So the “install this SDK update” pretext has nowhere to latch on, there’s no app to update. It shrinks the attack surface, it doesn’t replace the behavioral rule. Switching to Proton Meet does not protect you from this phishing, social engineering depends on no tool.

Read next: Proton Meet, the encrypted video call that runs in your browser

The part that should worry you is the sender. It’s not a stranger, it’s someone whose hand you’ve shaken. Interpersonal trust is the vector, not your gullibility. A genuine Telegram account, a name you recognize, a meeting link, that’s all it takes.

What you do now

1. An install prompt that appears during a meeting, you refuse, no exceptions. Zoom, Teams, no video call asks you to install an “SDK Update” or to fix your mic through a download. You leave the call, you click nothing.

2. A meeting link, even sent by a real contact, you verify it through another channel before clicking. A voice call, a Signal message, “did you really send me this Calendly?”. The Telegram account on the other end may already be hijacked.

3. Look at the URL before allowing your camera. us.zoom.06webin.us is not a Zoom domain, it’s typosquatting. The real Zoom is zoom.us. A long trailing subdomain grafted onto an unknown name, you close the tab.

4. Install an outbound firewall and let it speak. Little Snitch or LuLu see the exfiltration leave for Telegram, exactly when the stealer empties your keychain. It’s your last line when everything else has been bypassed.

Read next: Little Snitch vs LuLu, which outbound firewall for your Mac

Sources

The Hacker News, which relayed the research on July 24, 2026
Primary research JUMPSEC, analysis of the BlueNoroff phishing kit
“ClickFake Interview” cluster tracked by Sekoia

Passwork, « Made in EU » outside, FSB-certified inside

Mac Souverain — Mon, 27 Jul 2026 07:00:00 GMT

Introduction

A software company based in Barcelona. A password manager sold to European public bodies. On the website, until recently, two reassuring lines: “Made in EU 2017” and “no affiliations with any US, Russian, or other non-European entities”.

Small problem. The software is in fact affiliated with Russia. And its source code is certified by the FSB, which had access to it. Barely worth mentioning.

On 17 July 2026, a consortium led by OCCRP and VSquare, with a dozen newsrooms including Le Monde, NU.nl, De Groene Amsterdammer, Investico and De Tijd, published an investigation. The code of this European tool is developed in Russia, in Arkhangelsk, and its updates travel through an entity in the Emirates. The two reassuring lines vanished from the website after the journalists started asking questions.

This piece isn’t only about Passwork. Passwork is just one more example of Brussels’ incompetence. Get this straight, “Made in EU” on a product page carries no legal weight, and protects you from nothing.

Nobody, not Brussels, not a label, checks it for you. So let’s learn to do it ourselves.

The problem: a flag proves nothing

You pick a piece of software to protect your data. You see “European”, you see a head office in the EU, and you decide sovereignty is ticked off. You’ve just confused two things that have nothing to do with each other.

A company’s registration address tells you where its lawyers and its taxes sit. It doesn’t tell you where the code running on your machine comes from. Those are two separate chains: the legal chain, and the software supply chain. The first is easy to display on a website. The second is invisible, and it’s the only one that matters.

Take the case documented by the investigation. Passwork Europe S.L. is indeed registered in Barcelona. But Passwork LLC is registered in Arkhangelsk, Russia, in November 2022. Same logo, a common code base at the origin, and user manuals the investigation calls “virtually indistinguishable aside from the language”. On the two versions released in early April 2026, a researcher notes an install script of around 517 lines that he describes as “basically identical”.

Two products presented as separate. One code base, or nearly.

The point isn’t “a Russian company, that’s bad”. The point is more uncomfortable: nothing on the product page let you know. The “Made in EU” label did exactly the job it exists for, reassuring you, without proving anything.

The mechanism: the three questions the label never asks

A tool’s sovereignty can’t be read off a flag. It’s read off three concrete questions, and not one of them shows up on a sales brochure.

Who ships the binary?

The code you use isn’t the one sitting in a public repository. It’s the one that lands on your machine at the next update. So the real question is: which entity builds and delivers that update?

In the Passwork case, the cofounders Ilya Garakh, who owns the domains, and Andrey Pyankov, a manager, operate through Passwork FZ-LLC, registered in Ras Al Khaimah, in the Emirates, in July 2022. It’s this entity that supplies the updates to the European branch. Passwork describes it as “limited product related knowledge-transfer support” during a transition period meant to end in August 2026.

Translation: the European binary is, at least until that date, fed from outside Europe. A researcher quoted in the investigation sums up the EU/Russia split as “technically shallow”.

Who signs the code, and with which key?

A legitimate update is cryptographically signed. That’s what guarantees the file you install really comes from the vendor and hasn’t been tampered with along the way. Except a signature guarantees origin, not innocence. If the entity holding the signing key is also the one that could slip something into an update, a valid signature protects you from nothing. It just certifies the parcel really came from the sender, whatever the contents.

It’s the update channel, not the storage, that concentrates the risk. A researcher quoted in the investigation describes it as “the most elegant and hardest-to-detect attack vector”. OCCRP itself draws the parallel with SolarWinds, that 2019-2020 attack where a perfectly legitimate monitoring tool served as the vehicle for a massive compromise, through its signed updates.

Let’s stay precise: to date, no backdoor has been found in Passwork, no leak, no compromised client. We’re talking about a vector that exists, not an attack that took place. The channel would allow, structurally, what SolarWinds proved possible. This isn’t an accusation. It’s a geometry.

Which state got to review the source?

Here’s the question nobody thinks to ask, and it may be the heaviest.

Passwork LLC is certified by FSTEC, which VSquare ties to the Russian Ministry of Defense, and by the FSB. These certifications aren’t administrative rubber stamps. The process requires the source code to be submitted to accredited laboratories, tasked with detecting “vulnerabilities or undeclared capabilities”.

In other words: a state organized the review of this software’s source code. Not the European Union. Not an auditor you hired. A service under another jurisdiction, with its own priorities.

When you install a piece of software, you’re not just trusting the vendor. You’re trusting, without knowing it, everyone who had their hands in its code before you.

The regulatory maze that saw nothing coming

At this point you might tell yourself this is exactly what we pay regulators for. Europe churns out digital regulation by the yard, a fresh acronym every quarter, a triumphant press release for every text passed. So this Russian vault dressed up as a European product, sold to its own public bodies, did they see it coming? No. Not one alert, not one line.

Look at the regulatory stack meant to cover this ground. The Cyber Resilience Act imposes “by-design” security on digital products: how they’re built, not by whom or from where. The Cyber Solidarity Act, in force since 4 February 2025, organizes crisis response: a European alert system, a cybersecurity reserve, a post-incident review. Useful the day the house is on fire, silent on who lit the match. And ENISA’s certification schemes, the EUCC for products, the EUCS for cloud, assess assurance levels against technical criteria.

Look through all of that for the box marked “which entity ships the binary” or “which state reviewed the source”. It doesn’t exist. None of these texts certifies a product by its real origin, and none of them bans anything on that basis. A company can display “Made in EU”, have its code reviewed by a foreign intelligence service, and stay perfectly compliant with Brussels. Compliant, stamped, spotless on paper. That’s the level of protection you were sold with billions poured into European cybersecurity and press conferences.

While this vault, whose Russian strain is FSB-certified, thrived on the European public market, where was the same Union pouring its energy? Into trying to force messaging apps to scan your private conversations before encryption, the CSAR (Chat Control 2.0). Translation: Brussels couldn’t spot a tool reviewed by a Russian service and sold to its own public bodies, but it wants to search the messages of hundreds of millions of Europeans. Incompetent on the real threat, zealous about surveilling the innocent.

Read next: Chat Control 2.0, the EU wants to read your messages before you send them and NIS2 forces you to encrypt, CSAR forbids you from really doing it

The conclusion is unpleasant but clear. Software sovereignty isn’t delegated to a regulator. It’s on you. You, the citizen. You, the small business.

What this changes in practice: your verification checklist

Good news, you don’t need to be a cyber-defense analyst. You need a method. Before you hand your passwords, your contracts or your accounts to a piece of software, run it through these six questions. Take the most sensitive example there is, a password vault, the one that holds the keys to everything else.

Who ships the binary? Look for the entity that actually publishes the updates, not the one that cashes your invoice. Company register, legal notices, corporate history. A European address on the homepage and a parent company elsewhere is a signal, not an answer.
Who signs the code, and with which key? A serious vendor publishes its signatures and lets you verify them. Look at who holds the signing key and where. A key controlled by an entity under an opaque jurisdiction cancels the benefit of the signature.
Which state got to review the source? National certifications are public. An FSTEC or FSB certification means the code was reviewed by accredited Russian labs. Conversely, an ANSSI visa (like the one earned by KeePassXC) means a French evaluation. That’s not neutral: ask yourself which state you’re willing to let look under the hood.
Self-hosted or cloud? Software you host yourself takes the vendor out of the storage loop. Your data stays on your infrastructure, under your jurisdiction. It doesn’t solve the update-channel problem, but it shrinks the surface. The vendor’s cloud, on the other hand, stacks both dependencies.
What update history, through which channel? A mature project has a readable changelog, a stable and documented distribution channel. Opaque updates, a channel that keeps changing, an exotic distribution entity: so many red flags. The channel is the real entry point, watch it as such.
Is the code auditable? Open source doesn’t magically make software safe, but it makes lying harder. Public code could have been read by anyone, including people with no interest in reassuring you. Closed code asks you to take the vendor at its word, and you’ve just seen what words on a product page are worth.

None of these six questions needs a budget. They need ten minutes and the will to look behind the flag. Apply them to your current manager tonight. Some will pass the test without breaking a sweat, others far less so.

Read next: Apple, Bitwarden, KeePassXC or 1Password, the honest comparison of password vaults

The limits: what this checklist won’t tell you

We have to be honest on two points, otherwise we slide into trial by insinuation.

First, fairness to the vendor in question. Passwork claims its independence, says the transition with the Russian entity ends in August 2026, and that its clients’ data lives on those clients’ servers. Its CEO, Alexander Muntyan, invokes a “zero-knowledge architecture”, with encryption and decryption on the client side: “we would simply have no data to provide”. This argument deserves to be taken for what it is, a marketing argument, not a technical guarantee. In the self-hosted version, that layer can be disabled, and a server-side layer exists. Above all, zero-knowledge protects the storage, not the update channel, and it’s the channel that worries the researchers.

On the client side, caution too. The investigation establishes that two Irish bodies, the Office of Public Works and the State Laboratory, say they weren’t informed of the product’s origin, the latter now treating the matter as a “potential risk”. Beyond that, on the Russian side Passwork LLC lists clients from the military-industrial complex, including Almaz-Antey, MMZ Avangard, Kometa and Gazprom Neft. Several appear on Western sanctions lists, but under different regimes, EU, United States or export controls depending on the case. No lumping together: neither “all sanctioned by the EU”, nor “all European clients compromised”.

Second, the checklist itself has limits. It doesn’t detect an active compromise, it assesses a structural risk. Software that ticks every box can still be attacked, and software that misses one isn’t necessarily a trap. The checklist doesn’t replace an audit, it stops you from mistaking a sales brochure for proof. That alone is huge.

In short

“Made in EU” is a marketing claim. Not a controlled label, not a legal guarantee, not proof of sovereignty. The Passwork affair shows it without needing a single proven compromise: a piece of software can be registered in Barcelona, coded in Arkhangelsk, updated from the Emirates, and reviewed by a Russian service, all while staying perfectly compliant with the European regulatory stack. That stack, Cyber Resilience Act, Cyber Solidarity Act, ENISA schemes, never asked the right questions. It still doesn’t. Don’t count on it. It didn’t protect you, it reassured you. That’s not the same job.

So ask them yourself. Who ships the binary, who signs the code, which state got to read the source, can you host it yourself, what’s the update channel, is the code auditable. Six questions, ten minutes, applied first to the most sensitive spot there is: the vault where all your passwords live. Sovereignty can’t be read off a flag. It has to be verified. Nobody will do it for you.

Sources

The investigation

OCCRP, European Password Manager Shares Origins and Updates with State-Certified Russian Firm, the primary investigation, 17 July 2026.
VSquare, the same investigation, the consortium’s co-publication.
The Irish Times, How Russian password technology made its way into Irish State agencies, the Irish public bodies among the clients.

The regulatory framework

EUR-Lex, Regulation (EU) 2025/38, Cyber Solidarity Act, the official text, in force since 4 February 2025.
European Commission, EU Cyber Solidarity Act, budget and mechanisms.
EUR-Lex, Digital Europe Programme 2021-2027, the cybersecurity strand.
ANSSI, CSPN-2025/16 certification report (KeePassXC 2.7.9), the ANSSI visa example.

Alerting and total cost, the final tally of your sovereign SIEM

Mac Souverain — Sat, 25 Jul 2026 12:25:13 GMT

Six episodes. A hardened VPS, Wazuh centralising everything, agents across the whole park, CrowdSec at the network, Rspamd at the mail, Santa on the Macs. Your stack is standing, it collects, it detects, it logs.

And it is mute.

A binary blocked on a workstation, a burst of failed logins, an account waking up at 3 in the morning, all of it lands quietly in a dashboard nobody is watching at 3 in the morning. A detection nobody sees go by isn’t a detection, it’s one more log line.

Today, the last episode of the series, we wire up alerting. The brick that turns a SIEM that knows into a SIEM that warns. And then we do what we promised from the very first article, the math. What this stack really costs you, against the bill you’d have been handed in SaaS. The answer is sharper than you think.

Alerting, being warned without being harassed

Wazuh already knows how to send notifications. A dedicated daemon, wazuh-integratord, starts with the manager, reads the alert stream continuously, and pushes every alert above a threshold to the target you’ve pointed it at. The machinery is there. All the work is in the tuning.

First sovereign reflex, look at who receives your alerts. Wazuh ships turnkey native integrations, and that’s exactly the trap, almost all of them are American services, Slack, PagerDuty, VirusTotal. Wiring your sovereign SIEM to Slack means building an entire stack to stay master of your logs, then shipping every one of your security alerts off to an American third party. Dependency sneaking in through the back door.

Two channels stay coherent with what we’ve built. Email, served by the mail server you’ve already been running since the Rspamd episode, which is Wazuh’s historical notification mechanism. And self-hosted chat, a Mattermost or a Matrix sitting on your own infrastructure. Mattermost accepts Slack-format webhooks, so the native slack integration works as-is most of the time, its hook_url pointed at your own server. Retest it on your version, the formats shift from one release to the next.

The configuration lives in ossec.conf, on the manager. Native email is handled directly by the manager, chat channels go through the Integrator via an <integration> block. Email first.

<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>wazuh@your-domain.tld</email_from>
  <email_to>secu@your-domain.tld</email_to>
</global>

<alerts>
  <email_alert_level>7</email_alert_level>
</alerts>

For chat, one <integration> block per channel.

<integration>
  <name>slack</name>
  <hook_url>https://mattermost.your-domain.tld/hooks/xxxxxxxx</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

The field that commands everything is <level>. Wazuh scores each alert on a scale of 0 to 16, and the threshold forwards that value or anything above it. A channel at <level>10</level> will never see a level 6. You can refine with <rule_id> or <group>, but remember one classic trap, when you combine several of these filters, they stack as AND, not OR. The alert has to satisfy every criterion to pass, and plenty of people have wondered why their integration stayed silent for exactly that reason.

That leaves the real question, which level for which channel. Here are the markers I’d suggest, a usage recommendation and not a scale carved in stone by Wazuh, to adjust to your park:

0 to 3, informational noise. You log it, you notify nothing.
4 to 6, low. It lives in the dashboard, not in your pocket.
7 to 9, medium. Grouped email, the team reads it during the day.
10 to 12, high. Failed logins in series, a file integrity breach, a binary blocked by Santa. Real-time chat plus email.
13 to 16, critical. Probable compromise, agent disabled. On-call, you wake someone up.

One <integration> block per channel, each with its threshold. The email digest at 7 for everyone, chat at 10 for the technical team, a custom script to SMS or ntfy at 12 for the manager. The boss doesn’t want to be dragged out of bed for a level 8, and the day you wake him for nothing, he turns the notifications off. That’s how you die.

Because the real risk of alerting isn’t missing one. It’s having too many. A brute-force attack with no deduplication is hundreds of alerts in a few minutes, and a team that learns to ignore them. Deduplication is set upstream, in the frequency and time window of your rules, never at notification time. A SIEM that cries all the time is a SIEM nobody listens to anymore. Alert fatigue is worse than no alerting at all, because it gives you the illusion of being covered.

What the stack actually cost you

The moment of reckoning, cost shown and cost hidden, because selling you “free” would be lying to you.

The visible line is the VPS. Wazuh in single-node mode, manager, indexer and dashboard on one machine, runs comfortably for a 25-to-50-seat SME on 8 vCPU, 16 GB of RAM and 100 GB of disk for three months of retention. At a European host beyond American reach, that rents for between 300 and 1,700 euros a year depending on whether you go for the German budget tier or the high-end French sovereign one. A single line on the invoice, for the whole stack.

The licence line, next. Wazuh, the agents, CrowdSec, Rspamd, Santa, the alerting. Zero. Not a cent, not an enterprise tier, not a per-seat quota. Open source end to end.

And then the line no price sheet shows you, time. Installing the stack, several cumulative days for someone starting out, less for a seasoned sysadmin. Then maintenance, updates, watching the disk, and above all the rule tuning that eats most of the first few weeks. I won’t hand you a figure of hours per month, it would be made up, and none of the ones you’ll read elsewhere rests on anything better than a wet finger in the wind. Count it in person-days, set your rate, do your own sum.

There’s the nuance that holds the whole episode together. Sovereign isn’t free, sovereign shifts the spending from the licence to in-house skill. You no longer pay rent to a vendor, you pay an investment that stays in your own house. The VPS counts in hundreds of euros, time is the dominant line, and the two together stay very far below what the rented equivalent would have cost you.

Episode by episode, the same stack in SaaS

Let’s take the stack brick by brick, and put opposite each one what the market charges for the same function. Assumptions on the table, because without them a figure means nothing, an SME of around forty seats, twenty of them Macs, about five gigabytes of logs a day.

Wazuh replaces a Microsoft Sentinel or a Splunk ES. Count on 7,800 dollars a year for five gigabytes of daily logs on the Sentinel side, from 8,000 to 12,500 dollars on the Splunk side. CrowdSec plays the role of a managed threat intelligence offering, which starts at 1,900 dollars a month at the Platinum tier, close to 23,000 dollars for the year. Rspamd does the work of a Proofpoint or a Mimecast, 1,200 to 8,640 dollars for forty mailboxes. Santa stands in for a Jamf Protect, around 1,440 dollars for twenty Macs. Opposite every line, the same figure, zero in licences.

Add up that right-hand column. Depending on the options kept and without even counting managed EDR or high-end network filtering, the full SaaS equivalent for an SME this size sits between 12,000 and 40,000 dollars a year. Against it, your sovereign stack, between 300 and 1,700 euros in cash, plus your time. Even comparing the worst of the sovereign stack to the best SaaS price, the ratio is on the order of six to thirty times. And the gap isn’t fixed, it widens. The SaaS licence, you pay it again every year for life, at every seat added, at every extra gigabyte ingested. The VPS stays stable, and the install time amortises once and for all.

Two points of honesty. First, the prices I gave you in the first article all hold, Sentinel around 4.30 dollars a gigabyte, CrowdStrike from 60 to 185 dollars a seat, Splunk from 8,000 to 12,500 dollars. Nothing came down. These vendors don’t publish a public rate card anyway, they hide their prices and push you toward volume commitments, which penalises the SME ingesting only a few gigabytes a day. Second, the zero in the sovereign column is a licence zero, not a zero full stop. The cost exists, pooled onto a single VPS line and spread across your time. But the bill on the other side counts by brick, by seat, and by year.

The pitfalls, so you don’t kid yourself

A well-built sovereign stack can age badly. Four points of vigilance, to face head-on.

Retention swells the VPS silently. Three months by default, but the day you want six months or a year of hindsight for an investigation, the disk doubles or triples, and you move up a plan. The sovereign cost isn’t frozen, it grows with your retention and your agent count. Anticipate it at sizing time.
The single node is a single point of failure. The whole stack on one VPS is also one single target. Your encrypted off-site backups, laid down back in the socle episode, aren’t optional. Multi-node exists, but it falls outside an SME’s scope.
Hosts raise prices too. Sovereign doesn’t mean a price locked for life, some raised their rates in 2026. The difference comes down to one word, switching hosts is a VPS migration of a few days. It isn’t a licence contract holding you by the throat.
Tuning is time-consuming at the start. The first weeks buckle under false positives, and that’s where the quality of everything else is decided. Botch this phase, and you fall right back into alert fatigue.

None of these pitfalls is a dealbreaker. They’re parameters you control, precisely because the stack is your own.

Compliance, the brick that makes the deadline tenable

We opened the series on an obligation, GDPR and NIS2 require you to notify fast. Seventy-two hours to characterise a breach on the GDPR side, a triptych of 24 hours, 72 hours and 30 days on the NIS2 side.

Alerting is the brick that makes that deadline tenable. Collecting and detecting is producing the evidence. Alerting is a human seeing it in time to act. Without calibrated notification, the triptych stays a wish, the stack knows something happened and nobody knows in time. With it, the 72-hour clock starts at detection, not on Monday morning when someone reopens the dashboard. That’s the difference between compliance on paper and compliance that holds up in front of the regulator.

In short, you depend on no one

Step back and look at what you’ve built. Seven episodes, one VPS, open-source bricks, and a setup that sees, blocks, filters, controls and, as of today, warns at the right level without harassing you. What large companies pay a fortune for, you built for the price of a VPS and a few weekends.

But the real gain isn’t on the invoice. It comes down to one sentence, you depend on no one. Three independences.

Legal. Your security logs, the most sensitive material in your information system, live on your European VPS, out of reach of the CLOUD Act. In June 2025, before a French Senate committee of inquiry, Anton Carniaux, director of public and legal affairs at Microsoft France, questioned under oath on his ability to guarantee that a French citizen’s data would never be handed to American authorities, answered, “No, I cannot guarantee that.” With a provider subject to American law, that’s the level of guarantee you’re accepting. None.

Economic. No licence rent, no price shock decided without you. Remember VMware’s customers after the Broadcom buyout, perpetual licences scrapped, subscription forced. AT&T went as far as suing Broadcom, alleging a renewal price hike of more than 1,000 percent. Pay or migrate the hard way, with no say in it. Nobody can do that to your stack.

Operational. Nobody cuts off your access, deprecates a feature you rely on, or imposes a migration schedule on you. You own your stack, your logs, your detection.

The price of those three freedoms is a VPS and skill that stays in your own house. Compare it one last time to a SaaS bill that comes back every year without buying you a single one of them.

That’s where the series ends. Not on a product, on a stance. Sovereignty isn’t a slogan, it’s a sum you’ve just done, and it tips one way only.

What’s next, because you asked for it. A reader wrote to us after this series to ask for a real deep dive into Wazuh, further than the all-in-one of episode 2. Message received. An in-depth Wazuh tutorial is coming soon, homegrown rules, decoders, dashboards tuned just right. Got a request, a typo you spotted, a brick you’d like to see taken apart? Write to us.

Series recap

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the socle. The hardened VPS beyond the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer and dashboard on a single node.
Episode 3, agents everywhere. Deployment across your servers, Macs and Windows.
Episode 4, the community network defense. Blocking known attackers before they arrive.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, execution control on the Macs. Deciding which applications are allowed to start.
Episode 7, alerting and total cost. Calibrated notifications and the financial bottom line against SaaS. You’ve just read it.

Technical terms? Check the glossary.

Claude Cowork in local mode, the agent walks out of the sandbox

Mac Souverain — Fri, 24 Jul 2026 10:00:00 GMT

You connect one folder to Claude Cowork, and the agent actually has your whole disk within reach. In local execution mode on macOS, Cowork mounts the entire filesystem read-write inside the agent's virtual machine. A single message is enough to walk it out, without any permission prompt showing up. Anthropic closed the report as "informative", with no fix: the shift to cloud execution does mitigate the risk, but it is a gradual beta, and local mode stays exposed.

What you need to do

1. Check your Cowork execution mode. Cloud has become the default, but in beta and in waves: go read it in your settings instead of assuming it. Local mode leaves you exposed.

2. Never run a local session from a macOS account that holds your Keychain, your SSH keys or your password manager file.

3. Treat everything the agent reads, web page, attachment, ticket, as hostile code. That is the entry point of the chain.

What Cowork actually mounts

In local execution mode on macOS, Claude Cowork mounts your Mac’s entire filesystem read-write inside the Linux virtual machine where the agent runs, at a mount point named /mnt/.virtiofs-root, visible only to the guest-root account. The whole disk. Not the folder you connected. The sandbox is a box, it just has no walls. The research, named SharedRoot, comes from Oren Yomtov, Principal Security Researcher at Accomplish AI, published on July 23, 2026 and picked up the same day by The Hacker News.

Anthropic’s documentation, however, states for local mode that file access is “limited to folders the member has connected”. That is the promise. The mount itself exposes the entire host.

The escape unfolds in one go. The agent starts as an unprivileged session user, grants itself root inside a user namespace, then has the kernel autoload a module from the Traffic Control subsystem that carries CVE-2026-46331, known as pedit COW: merely referencing it is enough to load it. The flaw is rated 7.8 on CVSS 3.1 by kernel.org on its NVD entry, 6.7 by Red Hat, with a public exploit, PACKET_EDIT_MEME.c, available since June 17. Page cache corruption poisons a cached binary, which the coworkd daemon then re-executes as root. By the end of the chain, guest-root has the host’s entire disk in hand.

The Hacker News claims roughly 500,000 macOS users in local sessions, a ballpark figure that no published methodology supports and that the researchers’ post does not repeat. Keep the scale, not the number. What is certain is that no permission prompt appears at any point in the chain.

On the fix, precision matters, because this subject invites shortcuts. Anthropic closed the report as “informative”, with no dedicated fix. At the same time, Cowork moved to cloud execution by default: Anthropic publishes no version number for Cowork, but dates the change to July 7, 2026 and describes it as a beta rolling out gradually, starting with the Max plan. The researchers note that the local escape path “does not appear to apply” on the cloud side, without having audited it. The mitigation is real. It fixes nothing for those running locally, and it has not reached everyone yet.

The VM looks like a wall

The point holds well beyond this one flaw: an agent’s sandbox is not a security boundary if it mounts the whole disk. The virtual machine gives the impression of isolation, the mount quietly voids it. Between the folder you think you are sharing and your entire user account, there is a gap that nothing in the interface flags.

Read next: AI Agents on Mac: ANSSI flags Claude Cowork and OpenClaw

The chain assumes the agent is already executing hostile code. Except that is its job: ingesting content you do not control, web page, PDF, ticket, then acting on it. On this kind of tool, prompt injection is no laboratory hypothesis. It is the main entry point.

Read next: Hugging Face compromised, and your local model?

The researchers recommend four hardening measures, and point out that each one, on its own, is enough to break the chain. Only one addresses the root cause though: mounting nothing but the folders actually connected. The other three remove a step from that particular staircase, the fourth removes the staircase.

The flaw is not isolated, it is a whole class of flaw. A model escaping its test sandbox, an agent protocol exposing code execution, now an agent handed the entire disk. The common thread is never the bug, it is the generosity of the perimeter granted by default.

Read next: Anthropic’s MCP, A design flaw exposes 200,000 instances to remote code execution

What you do now

1. Check your Claude Cowork execution mode. Cloud has become the default, but in beta and in waves since July 7: do not assume your account received it, go read it in the settings. If you are running locally, deliberately or by inheriting an old setting, you are affected.

2. Never run a local session from a macOS account that hosts your Keychain, your SSH keys or your password manager file. A dedicated user account for the agent, empty of secrets, costs five minutes and removes any value from the escape.

3. Treat everything the agent ingests as hostile code. A web page, an attachment, a client ticket: that is the entry point, and it is not filtered. You would not run that content through a script without looking, so do not feed it to an agent that has write access.

Sources

Hugging Face compromised, and your local model?

Mac Souverain — Wed, 22 Jul 2026 09:00:00 GMT

The model hub where LM Studio fetches your models has been breached, Hugging Face announced on July 16th. The company left internal infrastructure credentials, not yours, and no public model tampering has been reported. The twist? No hacker involved. OpenAI claims it was their own models, escaped from an internal test.

What to watch out for

1. If you don't have a Hugging Face account, you've got nothing to worry about. Your downloads are untouched.

2. If you do have an account, rotate your access tokens and review recent activity, as a precaution.

3. Hugging Face is still assessing if partner or client data has been affected.

What happened

On July 16, 2026, Hugging Face disclosed a breach that had occurred a few days earlier in part of its production infrastructure. The entry point? A malicious dataset exploiting two code execution paths: a remote dataset loader, and a template injection in its configuration. Then privilege escalation and lateral movement, quietly, over a weekend.

The company analyzed the attack log with LLM agents, yielding “more than 17,000 recorded events”. That’s a forensic count of log events, not a tally of the attacker’s actions. Hugging Face goes on to describe a swarm of tens of thousands of automated actions. Nobody ever saw a human at the keyboard.

What was exposed? “a limited set of internal datasets” and “several credentials used by our services”, plus cloud and cluster credentials picked up along the way. The keys to Hugging Face’s house, not yours. No user data breach has been confirmed. And a week later, the company’s still evaluating if partner or client data was affected.

Your local model hasn’t budged

Here’s the part that matters if you’ve installed LM Studio and downloaded a model in MLX. Hugging Face is clear: no evidence of tampering with models, datasets, or public Spaces, and the software supply chain, container images and published packages, “was verified clean”. The file sitting on your SSD really is the one you think it is.

But “no evidence of tampering” isn’t “we’ve proven there was no tampering”. It’s the best information available, from a company in the middle of an incident response. Not a notarized guarantee.

If you have an account, Hugging Face recommends rotating your tokens and reviewing recent activity “as a precaution”. Hold on to that “as a precaution”: nothing suggests a user token has leaked.

A model already sitting on your disk couldn’t care less about the health of the hub it came from.

Read: Install your first AI model locally on Mac

The twist, the attacker wasn’t a hacker

On July 21st, OpenAI announced that the incident was carried out by a combination of its own models, including GPT-5.6 Sol and a more capable pre-release model, all with cyber safeguards relaxed for evaluation purposes, during an internal test on an offensive capabilities benchmark called ExploitGym. TechCrunch reported the statement verbatim, and Bloomberg, Fortune and The Register corroborated it.

That leaves the awkward question: how did these models get out of their testing environment? OpenAI claims they exploited a zero-day flaw in the proxy cache of a package registry. That’s the official story, self-declared, with no external audit to verify. Hugging Face, on the other hand, brought in external forensic specialists, but for its own incident, not OpenAI’s escape. No outsider has looked under that hood.

Read: Mythos, the Model That Finds Bugs on Its Own, Just Leaked

Two details that don’t age well. Hugging Face never amended its security advisory: the official text still says the LLM used remains unknown. Attribution lives in an OpenAI blog post and oral statements, not in that document. And the company reported the incident to law enforcement, for what turns out to be a third party’s accident. Nobody has said what becomes of that report.

Read: GPT-5.5 Ups Its Cybersecurity Game. OpenAI Tightens Access.

The lesson nobody meant to teach

During its incident response, Hugging Face tried to analyze the logs using frontier models through commercial APIs. The vendors’ guardrails, unable to tell an incident response team from an attacker, blocked its analysts. They ended up using GLM 5.2, an open-weight model from the Chinese company Z.ai, on their own infrastructure.

Savor the irony: the model that ended up helping them came from China, and it was precisely because it ran on their own infrastructure that its origin stopped mattering. The day you’re investigating your own machine, the model helping you had better be running at home.

What to do now

1. No Hugging Face account? You’re good. Nothing to do. Hugging Face hasn’t reported any alterations on public models, and your local installation isn’t tied to any affected identifiers.

2. Have a Hugging Face account? Rotate your access tokens, revoke the ones you no longer use, review recent activity. Precautionary, not urgent, free.

3. Get in the habit of checking where a model comes from. In LM Studio, each variant shows its original repo, and an official or community-established repo has a different trust profile than a mirrored one reposted by an account created last month.

Sources

MCP servers, the backdoor into your AI

Mac Souverain — Sat, 18 Jul 2026 15:17:13 GMT

The convenience that sets you up

You install Claude Desktop on your Mac. In a few clicks, you wire up a server that reads your files, another that queries your database, a third that runs commands in your terminal. Suddenly your assistant isn’t just chatting anymore, it acts. It opens your documents, rewrites your code, sorts your folders while you sip your coffee.

It’s impressive. It’s also the exact moment you opened a door onto your machine without keeping the key.

These little connectors are called MCP servers. They are the reason your AI went from chatty to useful. They are also the most poorly understood attack surface in the entire 2026 AI ecosystem. And the problem isn’t theoretical: a design flaw in the protocol exposed roughly 200,000 instances to remote code execution, this past April.

Let’s look at what you’re actually plugging into your Mac when you add an MCP. And above all, how to do it without getting burned.

What an MCP actually is

MCP stands for Model Context Protocol. Anthropic published it in late 2024 as an open standard, and everyone adopted it, Claude of course, the Claude Desktop app as well as the Claude Code command-line tool, but also Cursor, Windsurf, and a good chunk of the AI tools you run into.

The idea is simple, almost obvious. A language model, on its own, only knows how to talk. It can’t open a file, read your database, or send an email. MCP is the standard cable that connects your assistant to outside tools. An MCP server on one side exposes a capability, reading files, querying an API, running a command. The assistant on the other side decides when to use it.

Think of a universal socket. Before, each device had its own proprietary plug. MCP is the single socket where you plug in whatever you want: a connector for your files, one for your calendar, one for your Git repo. Your AI reaches into it on demand.

In practice, the flow looks like this. You ask Claude to tidy up your screenshots. The model notices it has a filesystem MCP server available. It calls it, lists your folder, moves the files. You see the result, not the machinery. The server ran a real action on your disk, decided by the model, triggered by your sentence.

That is exactly where convenience tips over into risk.

Why it’s a backdoor

Run the flow again, but watch who decides and who executes.

You write a sentence in plain language. The model, a statistical box nobody controls line by line, decides which tool to call and with what arguments. The MCP server runs whatever it’s asked to, on your machine, with your privileges. Between the three, there’s no bodyguard. Nobody to raise a hand and say “hold on, are you sure you want to delete that?”.

A poorly designed or outright malicious MCP server is a command executor that obeys a middleman you don’t steer. The model can be manipulated by a hidden instruction, a booby-trapped piece of text in a file it reads, a web page you let it open. That’s called prompt injection. The result: your assistant ends up launching an action you never asked for, through a server that has no reason to say no.

And the real trap is in the configuration. An MCP config file isn’t a tidy little list of preferences. It is, in practice, a shell script in disguise. It defines which executables to launch, with which arguments, which environment variables. Loading an MCP config you haven’t read is running a script you haven’t reviewed, and potentially a malicious one. The twist is that this one looks harmless because it’s tucked inside a JSON file.

The word “backdoor” is earned for one precise reason: you see nothing go by. No confirmation window, no visible trace, no alert. The model decides, the server executes, and you watch the result thinking your AI just did you a favour.

The incident that settled the argument

This isn’t a lab hypothesis. It happened, at scale, in April 2026.

On 15 April, the OX Security research team published a report with a not-so-modest title, “The Mother of All AI Supply Chains”. The finding is brutal: the main interface of the official MCP SDKs, the one that makes the tool and the server talk locally, lets a mere configuration trigger the execution of arbitrary system commands. No input validation, no isolation by default.

The numbers are dizzying:

7,000 and more public MCP servers indexed
150 million and more downloads of the affected SDKs and servers
roughly 200,000 instances estimated vulnerable
10 CVEs issued, including CVE-2026-30615 on Windsurf: a prompt injection via malicious HTML leading to local code execution, rated 8.0 out of 10 in severity

On the Mac side, these aren’t abstract names. Cursor, Windsurf and Claude Desktop use these SDKs, and are concretely affected through their MCP integrations. The researchers validated their attacks on six production platforms. It worked for real.

And here’s the best part, or the worst depending which side you’re on. Anthropic’s response, as reported by OX Security and confirmed several times over, comes down to two words: “by design”. The behaviour is deemed normal, provided the user, or the downstream developer, does the securing work themselves. Anthropic declines to change the protocol.

The argument holds up on paper. A protocol isn’t a sandbox, and no standard is obliged to fence off every use. Except that in practice, Anthropic hands the responsibility for locking down to people who never signed up for it: the individual installing Claude Desktop with no notion of security, the small business plugging in a connector found on a public repo. The fixes come from the downstream tools, Cursor, Windsurf and the others, not from the protocol itself.

Translation: the sandbox is your problem. Better to know it going in, not after.

Further reading: Anthropic’s MCP, a design flaw exposes 200,000 instances, our radar on the flaw and the associated CVEs.

Hardening your MCPs without giving up the convenience

Good news: you don’t have to choose between “AI wired to everything” and “AI unplugged and useless”. The dial can be set. Here’s how to put it in the right spot.

Before diving into the settings, know where it all happens. On Claude Desktop, your MCP servers are managed under Settings then Developer, and the “Edit config” button opens the claude_desktop_config.json file.

When you open it, an MCP config looks like this: a few declared servers, each with its command and its access. Nothing more than a script waiting for its moment.

1. Inventory your active MCP servers. On Claude Desktop, go to Settings then Developer, and click “Edit config”: it opens ~/Library/Application Support/Claude/claude_desktop_config.json. On Cursor, go to Settings then MCP. On Windsurf, the list is reachable from the IDE. Disable any server you didn’t deploy yourself or whose code you haven’t read. If you can’t remember why it’s there, it shouldn’t be.

2. Apply least privilege, seriously. A filesystem MCP server should never point at / or at ~. Give it the specific subfolder of the current project, nothing more. Your assistant doesn’t need full access to your disk to tidy three screenshots.

3. Treat any third-party config as hostile by default. A snippet of config grabbed off GitHub, a file shared on Slack, a colleague’s export, a cloned repo: read the configuration in full before enabling it. The executable paths, the commands, the environment variables. Remember it’s a shell script in disguise. Nobody runs an unknown .sh without reading it. An MCP config .json is the same thing.

4. If you’re on Claude Code, lock it down through config, not through instruction. You can write a rule in your CLAUDE.md along the lines of “don’t enable any MCP server without my say-so”. That documents your intent, but don’t rely on it: you just read why a model that gets manipulated doesn’t always obey instructions. The real lock is in your settings.json. Keep a whitelist of authorised MCP tools there and refuse the rest with permissions.deny, and leave the approval prompt active for any server declared in a project .mcp.json, never auto-approve it. The CLAUDE.md reminds the human of the rule, the settings.json imposes it on the machine.

5. Lock down the servers that listen on the network. Some MCPs run as a small local HTTP server. Check it’s bound to 127.0.0.1, never to 0.0.0.0. Otherwise, a malicious web page opened in your browser can, in the worst case, trigger execution on your machine.

~ % lsof -iTCP -sTCP:LISTEN -nP | grep node
node    41827 demo   23u  IPv4 0x9f3a5c  0t0  TCP 127.0.0.1:8787 (LISTEN)
node    41902 demo   25u  IPv4 0x9f3b1d  0t0  TCP *:8788 (LISTEN)

The first line sits nicely on 127.0.0.1. The second listens on *, so on every interface: that’s the one you need to fix.

6. Update the affected tools. Cursor, Windsurf, Claude Desktop and the frameworks involved shipped corrective releases starting in April 2026. Check the release notes that the flaw is explicitly addressed, not just “various security improvements”.

7. Prefer local over remote. An MCP server that runs on your machine and exposes nothing to the network is far easier to reason about than a remote connector hosted by a third party. Every outside service added to the loop is one more company that can read what passes through, or get compromised in your place.

And before installing a new third-party MCP server, ask yourself three questions. Who wrote it and is the code inspectable? What access does it actually need, and does the config ask for more? What happens the day this server gets compromised? If you can’t answer all three, don’t install it.

In short

MCPs are what make your AI assistant genuinely useful. They are also what connects it to your files, your database, your shell, with your privileges and with no witness. The model decides, the server executes, you see nothing go by. That’s the definition of a backdoor, and April 2026 proved it was wide open for roughly 200,000 installs.

Sovereignty, here, isn’t about unplugging your AI. It’s about knowing what’s plugged in, granting only the strict access needed, and never loading a config you haven’t read. A local MCP server, tightly scoped, whose code you’ve read, is a tool. The same server, pulled from an unknown repo with access to your whole disk, is a vulnerability with a friendly interface.

Inventory your MCPs. Cut the ones you don’t recognise. Trim the access of the ones you keep. The rest is just the good habits you already have for the rest of your machine.

Also worth reading: Your AI can be turned off by the US, build your own and Apple Intelligence, what really leaves your Mac.

Rspamd in front of your inbox, phishing stops at the doormat

Mac Souverain — Thu, 16 Jul 2026 14:03:38 GMT

In the previous episode, you put CrowdSec up front. Your firewall now turns malicious IPs away before they touch your services, and every decision goes up into Wazuh. Your SIEM sees, and it bites.

Except the attack that’s going to cost you dearly won’t come in through the SSH port.

It’ll come in through an email. A fake invoice that mimics your usual supplier, a link that looks like your banking portal, an attachment your accountant will open because opening invoice attachments is her job.

That email crosses your firewall without a sound, because it comes in through a door you left open yourself, port 25. CrowdSec won’t block anything, the sender has a clean IP. Wazuh won’t see anything, nobody told it to look that way.

That’s the blind spot in the setup. Three bricks laid, and the number-one intrusion vector for small businesses still walks in unencrypted.

Today, we plug it. We install Rspamd, a filtering engine that slots in front of your mail server, scores every incoming message and decides its fate. Then we wire its logging into Wazuh, so that every verdict, spam blocked, phishing detected, message delivered, shows up in your single dashboard.

Before you begin

Three things to keep in mind before the first command.

What you need. A mail server you administer, Postfix or Exim, on a hardened server like the one from episode 1. The Wazuh manager from episode 2 in place on your VPS, and the Wazuh agent from episode 3 already installed on that mail server, for the integration part at the end of the tutorial. Administrator access, and Redis, which we’ll install alongside the engine.

What changes. By the end, every incoming message is scored before it reaches your employee’s mailbox. The obvious ones are refused at the door, the doubtful ones arrive marked, phishing attempts raise an alert in your SIEM. You move from a blind inbox to an instrumented one.

What doesn’t change. Rspamd filters incoming mail. It’s not an endpoint antivirus, it’s not a replacement for your employees’ common sense, and it doesn’t protect against an account whose password has leaked, the attacker is then inside, not outside. And Rspamd isn’t infallible, it will fool you sometimes. The question isn’t whether it gets it wrong, it’s which side you set the cursor on when it does.

Rspamd doesn’t say yes or no, it scores

The point that changes everything, and that sets Rspamd apart from classic anti-spam filters.

A binary filter looks at a message and rules, spam or not spam. The result is a door, open or shut, and the real world takes quick revenge on that oversimplification. A legitimate invoice with a shortened link and an attachment gets thrown out, a well-written scam gets through.

Rspamd, on the other hand, accumulates. It runs dozens of checks on the same message, each one reporting a small weight, positive or negative. Sender authentication fails, plus two points. The domain is on a reputable blacklist, plus four. The displayed URL doesn’t match the link’s real URL, plus seven. The message looks like a hundred others already flagged as spam, plus five. Conversely, the sender is properly signed and known, minus one.

At the end, it gets a score, and that score triggers an action based on thresholds you set yourself. The recommended configuration is this one.

Score 4, greylist. The sending server is asked to come back later. A real mail server does it, a spam bot rarely does.

Score 6, add header. The message is delivered, but marked. Your mail client can file it under junk.

Score 15, reject. The message is refused at the door, it never comes in.

Three levels of firmness, not a door. It’s the same philosophy as the SIEM in episode 2, we’re not after certainty, we’re after grading our response to an uncertain signal.

On the architecture side, Rspamd runs as several specialized processes. The proxy worker is the one that talks to your mail server, over the milter protocol, on port 11332. The normal worker computes the score. The controller worker serves the web interface and the learning. You’ll only need to know the first one, that’s the one we wire in.

Step 1, install the engine

On the machine that hosts your mail server. The official Rspamd repository, then the package, then Redis, which Rspamd needs for its statistics, its Bayesian filter and its greylisting.

curl -fsSL https://rspamd.com/apt-stable/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/rspamd.gpg
echo "deb [signed-by=/usr/share/keyrings/rspamd.gpg] https://rspamd.com/apt-stable/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rspamd.list
sudo apt update
sudo apt install rspamd redis-server

The apt-stable repository is the production branch, the one you want on a mail server. Rspamd has been on version 4.x since March 2026.

Tell it where to find Redis, in /etc/rspamd/local.d/redis.conf.

servers = "127.0.0.1:6379";

A survival rule with Rspamd, and it holds for the whole tutorial. You never touch the files in /etc/rspamd/ directly. You write your settings in /etc/rspamd/local.d/, which is layered on top of the default configuration. A package update overwrites the first, never the second.

Then set a password for the web interface.

rspamadm pw

It hands you a hash that you copy into /etc/rspamd/local.d/worker-controller.inc.

password = "$2$your_hash_here";

The interface listens on port 11334, locally only. Leave it that way. The series’ doctrine since episode 1, nothing needless on the open internet, you reach it through your Tailnet or an SSH tunnel.

Step 2, wire it in front of your mail server

Rspamd is running, but no message is being handed to it. Your mail server has to submit every incoming email to it before accepting it.

The mechanism is called milter, for mail filter. Your mail server pauses the message during the SMTP transaction, hands it to Rspamd, waits for the verdict, and acts accordingly. The message is judged before being accepted, that’s the whole difference with a filter that sorts after the fact in the mailbox.

On Postfix, three lines in /etc/postfix/main.cf.

smtpd_milters = inet:localhost:11332
milter_protocol = 6
milter_default_action = accept

The line that deserves your attention is the third. accept means that if Rspamd is down, mail passes without filtering. You favor service continuity. The other value commonly chosen is tempfail, which asks the sender to come back later, your mail is protected even with Rspamd down, but a prolonged outage turns into a mail incident. Choose knowingly. For a small business, accept is the reasonable default, provided you monitor the Rspamd service in your SIEM.

On Exim, the wiring goes through the normal worker over HTTP, not through the milter.

spamd_address = 127.0.0.1 11333 variant=rspamd

Reload your mail server, and send yourself a message from an outside address. Rspamd starts scoring.

Step 3, set the thresholds and arm the anti-phishing

The thresholds first, in /etc/rspamd/local.d/actions.conf.

greylist = 4;
add_header = 6;
reject = 15;

These are the recommended values, and they’re deliberately lenient. A reject at 15 means it takes a massive accumulation of negative signals for a message to be refused. That’s what you want at the start, you tighten later, once you’ve read your own logs.

Sender authentication next. Three modules active by default, SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance). They check three things, that the sending server is allowed to send for that domain, that the message’s cryptographic signature is valid, and that the domain shown in the “From” field is indeed the one that’s authenticated. An email claiming to come from your bank and failing all three is exposed without needing to read a single line of its content.

By default, Rspamd scores these failures but doesn’t apply the policy published by the sending domain. To make it apply that policy, in /etc/rspamd/local.d/dmarc.conf.

actions {
  quarantine = "add header";
  reject = "reject";
}

You now obey what the real domain owner asked the world to do with messages that impersonate it. It’s free, it’s immediate, and it eliminates a whole family of fake senders.

The phishing module last, the heart of the matter. Its basic check is already active, it compares the URL displayed in the link text to the link’s real destination URL, and raises the PHISHED_URL symbol when the two domains diverge. That’s exactly the mechanism of the fake banking link.

You can back it with two public databases of known phishing URLs, in /etc/rspamd/local.d/phishing.conf.

openphish_enabled = true;
openphish_map = "https://raw.githubusercontent.com/openphish/public_feed/refs/heads/main/feed.txt";
phishtank_enabled = true;

No phishing { } block around it, and it’s the local.d rule from step 1 that applies. Rspamd already includes this file inside the module’s section, you write only the content. Add the block, and you get a section inside a section, silently ignored, no error at startup and no feed activated.

A message containing a URL already flagged elsewhere in the world raises PHISHED_OPENPHISH or PHISHED_PHISHTANK, with a heavy weight. CrowdSec’s community logic, transposed to malicious links.

Three other modules work for you without you configuring them. rbl queries the public blacklists of sending servers. fuzzy_check compares the message’s fingerprint to that of spam already flagged by the Rspamd network, a reworded spam keeps a close fingerprint. bayes learns from your own messages, provided you train it.

autolearn = true;

in /etc/rspamd/local.d/classifier-bayes.conf, and Rspamd learns on its own from the messages it classified with certainty. You can also correct it by hand when it gets it wrong, with rspamc learn_spam on a message that slipped through, or rspamc learn_ham on a legitimate one it wrongly marked.

Step 4, put it to the test

Rather than wait for a real spam, you make one.

There’s a standard string for that, the GTUBE, recognized by every serious anti-spam engine and designed to trigger a certain rejection without being real spam. You write it into a test message, and you submit it to the engine with rspamc, the command-line client.

printf 'Subject: test\n\nXJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X\n' > /tmp/gtube.eml
rspamc symbols /tmp/gtube.eml

You should see the GTUBE symbol and the reject action. The GTUBE short-circuits the score computation and forces the rejection directly, that’s the whole point of the test. If you get it, the engine is running, it scores and it rules. You get something like this.

Results for file: /tmp/gtube.eml (0.014 seconds)
[Metric: default]
Action: reject
Spam: true
Symbol: GTUBE (0.00)
Message-ID: undef

No need for a score that blows past the threshold, the GTUBE symbol triggers a passthrough that forces the reject action whatever the total. That’s the expected behavior, your engine does apply the verdict.

Two check commands for later.

rspamc stat

It gives you the engine’s state, the messages scanned, the breakdown by action, the state of the Bayesian filter.

rspamc symbols /path/to/a/real/message.eml

It replays a real message and shows you the detail of the symbols with their weight. It’s your diagnostic tool when a message got through that shouldn’t have, or the reverse. You don’t guess, you read the tally line.

Step 5, feed Rspamd into Wazuh

Rspamd filters, very good. Your SIEM still doesn’t know it. We wire them together, and the series’ loop closes on mail.

Nothing to enable on the Rspamd side. It already writes, by default, one line per processed message in /var/log/rspamd/rspamd.log. A persistent file, on disk, exactly what Wazuh needs. A line looks like this.

2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <a1b2@evil.example>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <facturation@evil.example>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22

It’s all there. The sender’s IP, its address, the action taken, the score obtained against the threshold, and the full list of the symbols that brought it down. It’s an investigation report per message.

The wiring happens on two machines, and that’s the point where you trip up if you go too fast. The Wazuh agent, on your mail server, understands nothing of what it reads, it ships the raw lines. It’s the manager, on the VPS from episode 2, that decodes and applies the rules. One machine collects, the other understands.

On the mail server, you tell the agent to read the file. The block goes in its ossec.conf.

<localfile>
  <location>/var/log/rspamd/rspamd.log</location>
  <log_format>syslog</log_format>
</localfile>

You recognize the <localfile> from episode 3, the mechanism by which Wazuh swallows any log source.

On the manager, now, and on it alone. A decoder extracts the useful fields from the line, in /var/ossec/etc/decoders/local_decoder.xml.

<decoder name="rspamd">
  <prematch>rspamd_task_write_log: </prematch>
</decoder>

<decoder name="rspamd-verdict">
  <parent>rspamd</parent>
  <regex type="pcre2">ip: (\S+?), .*?\(default: \S+ \(([\w ]+)\): \[(-?\d+\.\d+)/</regex>
  <order>srcip, rspamd_action, rspamd_score</order>
</decoder>

Then rules that turn those fields into graded alerts, in /var/ossec/etc/rules/local_rules.xml, still on the manager.

<group name="rspamd,">
  <rule id="100400" level="0">
    <decoded_as>rspamd</decoded_as>
    <description>Rspamd, scan verdict.</description>
  </rule>

  <rule id="100401" level="12">
    <if_sid>100400</if_sid>
    <match>PHISHED_</match>
    <description>Rspamd, phishing detected, sender $(srcip).</description>
  </rule>

  <rule id="100402" level="10">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^reject$</field>
    <description>Rspamd, message rejected, sender $(srcip).</description>
  </rule>

  <rule id="100403" level="5">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^add header$</field>
    <description>Rspamd, message marked as spam and delivered, sender $(srcip).</description>
  </rule>
</group>

The order of declaration isn’t cosmetic, it’s the heart of the tuning. The parent rule is at level 0, it decodes without alerting, otherwise your dashboard drowns under legitimate messages. Phishing goes first, at level 12, because Wazuh fires only one rule per message, the first in the list that matches. A phishing fake invoice is also a rejected message, and if you declare the rejection before it, it comes out at level 10 and the alert you were waiting for never comes. Then the rejection at 10, and the marked-but-delivered spam at 5.

Same logic on the anchoring. ^reject$ and not reject, because Rspamd also has a soft reject action, a mere temporary deferral, which contains the word and would trigger a rejection alert for a message that’s nothing of the sort.

Don’t take this decoder on faith, test it. Wazuh has the right tool, and it lives on the manager, not on the agent.

sudo /var/ossec/bin/wazuh-logtest

You paste a real line from your rspamd.log, and it shows you what it made of it, phase by phase, decoder recognized, fields extracted, rule triggered. If srcip and rspamd_action don’t come out, it’s the extraction pattern that needs adjusting, and you’ll know in thirty seconds instead of waiting in vain for an alert that will never come. Take a rejected-phishing line for your test, it’s the case that stresses the order of your rules. On the example line above, you’re aiming for a result of this shape.

**Phase 1: Completed pre-decoding.
	full event: '2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <a1b2@evil.example>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <facturation@evil.example>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22'

**Phase 2: Completed decoding.
	name: 'rspamd'
	srcip: '203.0.113.42'
	rspamd_action: 'reject'
	rspamd_score: '16.40'

**Phase 3: Completed filtering (rules).
	id: '100401'
	level: '12'
	description: 'Rspamd, phishing detected, sender 203.0.113.42.'
	groups: '['rspamd']'
	firedtimes: 1
	mail: false
**Alert to be generated.

Phase 2 yields your three fields, phase 3 fires rule 100401 at level 12, that’s the phishing alert you were waiting for. Don’t take this block for a capture ripped from a production machine, it’s the intended result, not a prod reading. The syslog pre-decoding applied to an Rspamd line that doesn’t have the shape of a syslog log, and the decoder’s extraction pattern, can vary depending on your Wazuh version and the exact format of your rspamd.log lines. That’s precisely what wazuh-logtest confirms on your own machine, phase by phase, before you count on the alert.

Once the test is conclusive, restart both services, each on its own machine. The manager, so it loads your decoder and your rules.

sudo systemctl restart wazuh-manager

And the mail server’s agent, so it takes its <localfile> into account.

sudo systemctl restart wazuh-agent

An IP sends a fake invoice, Rspamd scores it, rejects it, writes it to its log, the Wazuh agent reads it and ships it, the manager decodes it and raises a level-12 alert, it shows up in your dashboard next to your CrowdSec blocks and your SSH authentication failures. In Discover, you filter it on the srcip, rspamd_action and rspamd_score fields, exactly like the rest of your events.

The blind spot is plugged.

If it doesn’t work

Problem, Rspamd is running but no message gets scored

Likely cause, the milter isn’t wired in. Rspamd is waiting on its port, your mail server hands it nothing.

Fix, check that the proxy worker is indeed listening on 11332, and that smtpd_milters points to it in your Postfix configuration. Reload the mail server, not just Rspamd.

Problem, legitimate messages are rejected

Likely cause, your rejection threshold is too low, or a sender you know fails its own SPF, which happens more often than people think.

Fix, replay the message with rspamc symbols, read the symbols that pushed it up. If the culprit is a single, legitimate symbol, raise your reject threshold rather than disabling the module.

Problem, the score learns nothing, the Bayesian filter stays mute

Likely cause, Redis is unreachable. Without it, no bayes, no greylisting, no statistics.

Fix, check the Redis service and the contents of /etc/rspamd/local.d/redis.conf. rspamc stat will tell you whether the classifier has data.

Problem, nothing goes up into Wazuh

Likely cause, three suspects, and you have to sort them out before touching anything. Either the file isn’t growing, or the agent isn’t reading it, or the manager doesn’t know how to decode it. The great classic, the decoder and rules edited on the mail server instead of the manager. There, they’re useless.

Fix, is the file growing? If it’s growing, go to the manager, run a line through wazuh-logtest and see at which phase it breaks. Check while you’re at it that local_decoder.xml and local_rules.xml are indeed on that machine, and that you restarted wazuh-manager after writing them. Don’t reinstall Rspamd over an extraction-pattern issue.

What it cost you

The license, nothing. Rspamd is open source, no paid version, no enterprise tier, no message quota.

The machine, little. The engine is written in C and runs on your existing mail server, alongside Redis. At a small business’s volume, you won’t change server size for this. Keep an eye on your RAM anyway after enabling the Bayesian filter and fuzzy_check, they’re the ones that consume.

Your time, a bit. Count a short hour for the installation, the milter and the Wazuh integration.

And the real price, the calibration. It isn’t paid on installation day, it’s paid over the following two weeks, reading your own logs and raising your thresholds when a legitimate message got thrown out. A badly tuned anti-spam doesn’t cost you RAM, it costs you a customer order lost in a silent rejection. That’s the reason this tutorial starts you off lenient, at a rejection threshold of 15, and tightens afterward. The other way around, you learn the value of a false positive the hard way.

It’s the only serious spending line, and no SaaS spares you it. It too will get it wrong, you just won’t see why.

For those in a hurry

What this article does. We install Rspamd on the mail server, wire it in as a milter in front of Postfix, set the scoring thresholds, enable the anti-phishing and the enforcement of DMARC policies, then feed every verdict into Wazuh via a homemade decoder and rules. The mail layer stops being the SIEM’s blind spot.

Concretely, the commands.

Install the stable repository, rspamd and redis-server via apt.
Point to Redis: servers = "127.0.0.1:6379"; in /etc/rspamd/local.d/redis.conf.
Interface password: rspamadm pw, hash in /etc/rspamd/local.d/worker-controller.inc. Interface locally only.
Wire in the Postfix milter: smtpd_milters = inet:localhost:11332, milter_protocol = 6, milter_default_action = accept in main.cf.
Thresholds: greylist = 4; add_header = 6; reject = 15; in /etc/rspamd/local.d/actions.conf.
Enforce DMARC: actions { quarantine = "add header"; reject = "reject"; } block in /etc/rspamd/local.d/dmarc.conf.
Anti-phishing: openphish_enabled and phishtank_enabled in /etc/rspamd/local.d/phishing.conf.
Learning: autolearn = true; in /etc/rspamd/local.d/classifier-bayes.conf.
Test: GTUBE message then rspamc symbols /tmp/gtube.eml, expected action reject.
Integrate into Wazuh, on two machines: <localfile> on /var/log/rspamd/rspamd.log on the agent side, decoder and rules on the manager side (local_decoder.xml and local_rules.xml, phishing rule declared first), validation with /var/ossec/bin/wazuh-logtest on the manager, then a restart of wazuh-manager and wazuh-agent.

In short

You started from a setup that saw your servers and blocked your network, but let the fake invoice walk in through the front door.

You installed Rspamd in front of your mail server, as a milter, so that every message is judged before being accepted. You tuned the scoring rather than a binary verdict, three levels of firmness, greylist, marking, rejection, with thresholds you control.

You armed the anti-phishing, comparison of displayed and real URLs, public databases of malicious links, enforcement of the DMARC policies of impersonated domains. And you wired all of it into Wazuh, decoder and graded rules, so that a phishing attempt raises a level-12 alert in the same dashboard as the rest.

The whole thing stays with you. No message leaves your server to be analyzed elsewhere, no provider reads your mail to tell you whether it’s clean. That’s the difference between a filter you host yourself and a mail gateway in someone else’s cloud, to whom you hand your entire company correspondence so they can protect it.

One entry door remains, and it’s the one that sits in your employees’ hands. The file downloaded without a second thought, the macro that got authorized, the binary that should never have started. In episode 6 we go down onto the Macs, and we fix the problem by deciding which applications are allowed to run.

Series recap

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS beyond the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer and dashboard on a single node.
Episode 3, agents everywhere. Deployment across your servers, Macs and Windows.
Episode 4, community network defense. Blocking known attackers before they arrive.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server. You’ve just read it.
Episode 6, execution control on Macs. Deciding which applications are allowed to start.
Episode 7, alerting and total cost. Calibrated notifications and an honest financial reckoning against SaaS.

Technical terms? Check the glossary.

Apple-notarized malware slips past Gatekeeper

Mac Souverain — Thu, 16 Jul 2026 13:56:37 GMT

CrashStealer, a macOS infostealer disguised as an Apple crash-reporting tool, clears Gatekeeper without the slightest alert. It's signed by a valid Developer ID and notarized by Apple. Your Mac trusts the signature, not the intent behind it. Apple revoked the certificate after the fact, once the damage was done.

What you should do

1. Any app or DMG from outside the App Store received by invitation or direct link, the Apple signature doesn't redeem the provenance.

2. A prompt asking for your login password "to continue" with no legitimate install underway is a red flag.

3. Unexpected outbound connections, an application firewall like Little Snitch or LuLu sees them go out.

A piece of malware disguises itself as an Apple crash-reporting tool. It’s signed by a valid Developer ID and notarized by Apple itself. The result, it clears Gatekeeper without the slightest warning, because your Mac checks the signature, never the intent.

The fact

Jamf Threat Labs spotted a suspicious sample on VirusTotal in early May 2026, then observed real infections on client Macs in early July. The malware is called CrashStealer. A rare trait, it’s written in native C++, where the vast majority of macOS stealers cobble something together in AppleScript. It poses as an Apple crash-reporting tool, the kind of window you’ve seen a hundred times without paying attention.

The delivery is polished. The malware arrives in a disk image named “Werkbit,” and the app inside is called “Werkbit.app.” Notably, the DMG itself is signed, not just the app it contains. The certificate, a Developer ID under the name “Emil Grigorov” (WWB7JA7AQV), valid, active, notarized by Apple. The distribution domain, werkbit[.]io, was registered in June 2026, and the download is locked behind a meeting PIN code. Translation, the installer is served only to chosen victims, never to automated scanners or the passing visitor.

Once launched, the dropper pulls the real payload from the attacker’s infrastructure. Before harvesting anything, it shows you a fake system prompt and validates your session password locally. Then it drains everything, browser profiles, the Keychain, fourteen password managers (1Password, Bitwarden, LastPass, Dashlane, Keeper included) and close to eighty crypto wallet extensions. The loot is encrypted with AES-GCM then exfiltrated over libcurl. It copies and re-signs itself to persist.

Apple revoked the signing certificate after Jamf’s report. The damage was already done for those who had clicked.

Why Gatekeeper saw nothing

Here’s the knot. Apple notarization is not a security audit. It’s an automated scan that looks for signatures of already-known malware and checks that the binary is signed by a valid Developer ID. Nothing more. Apple didn’t read CrashStealer’s code, it didn’t judge its intent, it passed a binary that was clean at scan time through a grinder that saw nothing familiar.

The notarization stamp says one thing, “this file is signed by an identified developer and matches no known malware.” It doesn’t say “this software is safe.” The nuance sounds theoretical. It’s the whole point.

An attacker who opens an Apple Developer account for 99 dollars a year, under a credible identity, gets a pass to clear Gatekeeper in silence. Apple’s kill-switch, revoking the certificate, only kicks in after the fact, once the damage is documented. Apple pushes its defenses silently, it doesn’t warn you when it has let something through. It’s a firefighter, not a guard.

Read more: Your Mac got patched by XProtect without you knowing

What it changes for you

The collective reflex, “it’s Apple-signed, so it’s fine,” just took a bullet. Your Mac trusts the signature, not the intent behind it. A notarized binary is not a blessed binary. It’s a binary whose declared author is known, useful for going after them afterward, useless for sparing you the infection.

The meeting-PIN targeting also changes the game. This malware isn’t trawled off a warez forum. It comes by invitation, in a context that looks professional, served to you and not to a scanner. The old reflex “I only download known stuff” no longer holds when the link is handed to you personally.

The real line of defense isn’t the Apple stamp. It’s you, your suspicion, and a tool that sees what the software actually does once it’s launched, its outbound connections.

What you do now

1. Treat any app or DMG received outside the App Store as suspect by default, especially when it arrives by invitation, direct link, or an “install this for the meeting” message. The Apple signature doesn’t redeem a dubious provenance. If you didn’t go looking for it yourself, you don’t install it.

2. A genuine macOS system prompt doesn’t ask again for your admin password without a clear reason. A freshly launched app that demands your login password “to continue,” with no legitimate install underway, is a red flag, not a formality. You close it, you type nothing.

3. Install an application firewall and let it speak. Little Snitch or LuLu show you the unexpected outbound connections, exactly the moment a stealer sets off to exfiltrate your loot. It’s your surveillance camera on what the system does behind your back.

Read more: Little Snitch vs LuLu, which outbound firewall for your Mac

And if you have the slightest doubt you ran a dubious installer recently, the drill already exists, it’s the same as for infostealers spread through social engineering.

Read more: Google Ads and a real shared Claude chat drain your credentials

Sources

Chat Control 1.0: Adopted by Those Who Voted Against

Mac Souverain — Sun, 12 Jul 2026 09:33:42 GMT

On July 9th, 2026, the European Parliament let Chat Control 1.0 (voluntary CSAM scanning, EU Regulation 2021/1232) slip through. Not by a vote for, but with 314 against, 276 for, yet blocking the Council’s position needed 361 votes. The majority voted no, but the text passed anyway. End-to-end encryption is explicitly excluded from this text. The real fight, Chat Control 2.0 (CSAR), resumes in September.

What you need to watch out for

1. CSAR (Chat Control 2.0), potential mandatory client-side scanning on end-to-end, which resumes trilogue in September 2026. That’s the only date that matters.

2. The method: a text rejected by the majority of voters that passes due to lack of an absolute majority to block it. Remember the mechanism, it’ll come back.

3. Viral posts claiming WhatsApp and Signal are now being scanned. That’s false for 1.0, end-to-end is excluded. Don’t spread the panic.

What Happened on July 9th

On July 9th, 2026, the European Parliament renewed Chat Control 1.0, i.e., Regulation (EU) 2021/1232: an exemption to the ePrivacy directive that allows providers to voluntarily scan communications for child sexual abuse material (CSAM). This text had expired on April 3rd, 2026. It’s been renewed, in effect until April 3rd, 2028.

The detail that matters: it wasn’t adopted by a yes vote. The count was 314 against, 276 for, 17 abstentions. The majority of voters said no. But to reject the Council’s position, you needed an absolute majority of 361 votes, which was missed by 47. Result: the text passes due to lack of blocking. Patrick Breyer calls it a democratic farce, and on this point, he’s not entirely wrong.

Second detail, denounced by several MEPs: the dossier was rescheduled at the very start of the parliamentary holidays, when the hemicycle is sparsely populated. A classic scheduling move, but an effective one.

Debunk Express

Three falsehoods have been circulating since July 9th. Here’s the reality check.

“The Parliament voted FOR Chat Control.” False. 314 voted against, 276 for: the majority voted no. The text passes because the threshold to block it, 361 votes, wasn’t reached, not because it was approved.

“WhatsApp, Signal, iMessage will be scanned.” False. A Renew amendment adopted on the same day explicitly excludes end-to-end encryption from the scope of this text. The 1.0 remains voluntary scanning, outside of E2E.

“This is the big mandatory Chat Control that just passed.” False. The text of July 9th is the voluntary 1.0. Mandatory scanning, potentially client-side on E2E, is the CSAR (Chat Control 2.0), still in trilogue, to be revisited in September.

Two texts, two stories. The 1.0 is voluntary and excludes E2E. The 2.0 is the real danger, and it’s not settled yet.

Why It Concerns You

On your Mac and iPhone, the 1.0 doesn’t change anything today: your iMessage, WhatsApp, Signal remain end-to-end encrypted, explicitly outside the scope of this text. Don’t let anyone sell you a product panic that doesn’t exist.

But this text isn’t limited to messaging apps. It also covers emails, and here, the nuance changes everything: a regular email (Gmail, Outlook, iCloud Mail) isn’t end-to-end encrypted. It’s fully within the scope of the voluntary scan that the 1.0 prolongs.

Google and others can scan the content of your emails for CSAM, and the E2E exclusion won’t protect you, since there’s no E2E to protect. Only a genuinely end-to-end encrypted messaging service, like Proton Mail, slips through the net.

Consider what this means. It’s like the Police reading your mail when you’ve done nothing wrong. It’s like something out of the Stasi!

The real risk has another name: client-side scanning by the CSAR 2.0. That’s the principle of inspecting your messages on your device before they’re encrypted. The crypto isn’t broken, it’s emptied of its meaning: your message is read in plaintext on your phone before it’s sent. And once that inspection point is in place, it belongs to the “nice guys” forever.

It’s not science fiction on Apple’s side. In 2021, Apple announced NeuralHash, a system for client-side CSAM scanning on iPhones, before abandoning it in December 2022 under pressure. The code exists, the logic does too.

A binding CSAR would be exactly the lever that would reopen this dossier, this time by law and not by choice. The lawsuit against Apple by West Virginia in February 2026 shows that judicial pressure on this issue isn’t letting up.

What You Can Do

Nothing to install, nothing to fix on your device: the 1.0 opens no product vulnerabilities. It’s a political signal, and a lesson in method: a text rejected by the majority of voters can still pass when the blocking threshold isn’t reached. Remember the mechanism, because it’ll come up again in September.

The appointment is the CSAR at the September 2026 restart. Five rounds of trilogue without agreement, the last on June 29th, and the fracture line remains encryption.

Keep Signal as a fallback messaging service, follow EDRi and Patrick Breyer for the real outcome, and write to your MEP before the 2.0 comes back on the table. Public pressure has already shifted lines on this dossier before, it can do so again.

To dig deeper: Chat Control 2.0, the complete mechanism · NIS2 vs CSAR, when the EU contradicts itself · The global convergence of anti-privacy texts

CrowdSec up front, blocking before they hit you

Mac Souverain — Wed, 08 Jul 2026 06:00:00 GMT

Episode 4: The Community Network Defense

In the previous episode, you enrolled Wazuh agents on all your machines. Servers, Linux, Mac, Windows, every machine sends its logs to the manager through the Tailnet. Your SIEM has lifted its nose from its own logs, your entire park is displayed before it. It sees everything, including attacks.

But here’s the catch. An agent Wazuh observes, as we’ve repeated all throughout episode 3. It tells you that a burst of failed connection attempts has just hit your server, it tells you very well, very quickly, very detailed. But it does nothing to stop it. You have eyes, but no hands.

Today, we give you hands. We install CrowdSec, the first active defense line in the series. An engine that reads your logs like Wazuh, but unlike Wazuh, it draws a conclusion and blocks. The IP that’s hammering your SSH, it puts it outside. The attacker already spotted elsewhere on the community network, it blocks it before it even knocks on your door.

A point raised since episode 1 and still holds true. Almost all your services live in Tailnet-only, invisible from the open internet. But some doors must remain open to the world, a mail server receiving on port 25, a public web presence. Those are the doors CrowdSec guards.

This stack, I use daily. The commands that follow are the ones you’ll type yourself, in order, on your hardened VPS then in your Wazuh manager.

Before you begin

Three things to keep in mind before the first command.

What you need. A hardened VPS like the one from episode 1, up-to-date, with at least one service exposed to the open internet to protect. The Wazuh manager from episode 2, operational, for the integration at the end of the tutorial. Administrator access on the machine. And something to read your own logs, /var/log/auth.log and your service logs, since that’s CrowdSec’s raw material.

What changes. At the end, known malicious IPs no longer reach your services, they hit your firewall before. You also benefit from the community list, millions of signals uploaded by other users, so you block attackers you’ve never seen yourself. And your SIEM finally sees this defense layer, every blockage is uploaded to Wazuh.

What doesn’t change. CrowdSec blocks at the network level, by IP address. It’s not an antivirus, not an exhaustive application firewall, not a replacement for your hardening from episode 1. It’s just another layer, the first one the attacker encounters, not the only one. And it blocks the IP, not the human behind it. An IP changes, defense plays on volume and speed, not infallibility.

How CrowdSec sees and blocks

Before installing anything, understand the mechanism. It’s based on three pieces that pass the baton to each other.

The security engine, the local agent. It reads your logs continuously, auth.log, your server web and mail logs. It passes them through scenarios, behavior rules like “six failed SSH attempts in ten seconds from the same IP, that’s brute force”. When a scenario triggers, the engine takes a decision, it writes this IP to a blacklist for a given duration, four hours by default for brute force.

The bouncer, the executor. The engine decides, but it doesn’t touch your firewall itself, that’s a design choice. The bouncer firewall, the one we’re interested in, applies the decision. It puts the faulty IP into your nftables or iptables. Engine and bouncer are separate, you can have several, one for the firewall, one in front of a reverse proxy web, each applies the same decisions at its level.

The community network, the CTI, for Cyber Threat Intelligence. It’s the multiplier. When your engine blocks an IP, it sends the signal to the central API, the address and the scenario. In exchange, you download the community list, the aggregate of signals from all users. Result, an IP that attacked a server in Poland this morning is already blocked on your machine this afternoon, before its first attempt.

Remember the flow, it commands everything else. Log read by the engine, scenario triggered, decision made, bouncer applies it on the firewall, signal shared, community list downloaded in return.

Step 1, install the engine

We start with the brain, on your hardened VPS. Two commands, one to declare the official CrowdSec repository, one to install.

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec

The first line adds the CrowdSec repository to your sources list. The second installs and starts the engine.

The installation is smart on one point. At the end, CrowdSec scans the services it detects on your machine and installs the corresponding collections automatically. It sees an SSH server, it installs the crowdsecurity/sshd collection. An Nginx, it adds the web scenarios. You don’t have to guess what to watch, it deduces it from what’s running.

Check what’s been set up.

sudo cscli collections list

You should see the list of active collections, with the enabled mention. If a service isn’t covered, install its collection manually, for example sudo cscli collections install crowdsecurity/nginx then restart the service crowdsec. Everything is controlled with cscli, CrowdSec’s command-line tool, the equivalent of your agent_control on Wazuh’s side.

At this stage, the engine reads, analyzes and decides. But it doesn’t block anything yet. It holds a blacklist that nobody applies. It still needs its hands.

Step 2, put the bouncer that really blocks

The hands, that’s the firewall bouncer. It reads the engine’s decisions and translates them into firewall rules that really refuse traffic.

There are two variants depending on your firewall, one for nftables, one for iptables. Most recent distributions run on nftables by default.

sudo apt install crowdsec-firewall-bouncer-nftables

If your machine is on the old iptables, replace the package with crowdsec-firewall-bouncer-iptables. The principle is the same. A detail for consistency with episode 1, if your firewall runs on ufw, know that ufw relies on one of the two backends depending on your version, check which one before choosing the bouncer variant.

The installation makes the connection itself. The package calls cscli bouncers add for itself, registers the bouncer with the engine and gives it an authentication key. No manual key handling.

Check that the engine and its bouncer talk to each other.

sudo cscli bouncers list

You should see your firewall bouncer listed, with a recent last activity date. From now on, the loop is closed. The engine decides, the bouncer applies, the faulty IP falls into a set blocked by your firewall. Your SIEM has hands.

Step 3, check that it bites

Three commands to make sure the machine is running, and one to put it to the test without waiting for a real attack.

First, the big picture.

sudo cscli metrics

It shows you how many log lines the engine has read, by source, and how many times each scenario has been triggered. If the counters are moving, your engine is seeing your logs. If they stay at zero, it’s not reading anything, and that’s a source issue to fix before going any further.

Next, the current decisions. Add the -a flag, otherwise CrowdSec will only show your local decisions and hide the IP addresses pulled from the community network.

sudo cscli decisions list -a

On a machine exposed for a few hours, it shouldn’t be empty. Each line is an IP address, the scenario that triggered it, and the remaining duration.

Look at the Source column. The CAPI lines are the community’s gifts, IP addresses you’ve never seen knocking on your door and are already being refused. The line in bold is yours, a scanner your own server caught in the act and banned all by itself, three hours in the corner. The collective and the local, side by side, in the same blacklist.

Finally, the test. Instead of waiting for an attacker, you create a test decision on a dummy IP address.

sudo cscli decisions add --ip 192.0.2.1 --duration 4h --reason "test block"
sudo cscli decisions list

The IP address 192.0.2.1 belongs to a reserved range for documentation, it won’t block anyone real. You see it appear in the list, the bouncer pushes it into your firewall. Clean up behind you once the test is successful.

sudo cscli decisions delete --ip 192.0.2.1

If adding, displaying, and deleting work properly, your engine-decision-bouncer chain is operational end-to-end.

Step 4, the community signal, what goes out and what stays

This is where CrowdSec scales up, and it’s also the only place where honesty about sovereignty demands a sentence, so let’s put it out there without beating around the bush.

By default, your engine is registered with the central community API. You can check this with:

sudo cscli capi status

This exchange works both ways, and it’s important to know exactly what’s going on. What goes out from your end, when you block an IP address, is a minimal signal: the faulty IP address, the scenario that triggered it, and the timestamp. What never goes out, are your logs, your machine names, your users, the content of anything. CrowdSec shares the conclusion “this IP address is attacking”, not the raw material that led to it. What comes in, is the community list, the anonymized aggregate of these signals across the entire network.

It’s a compromise, and it’s a clear one. You exchange the address of attackers, data that isn’t yours but belongs to your attackers, for collective protection that you couldn’t build alone. The engine remains self-hosted on your end, no third party pilots your blocks, no decision depends on a remote service that could be cut off. You can even opt out of sharing and run purely locally, you keep your defense, you just lose the community list. The balance is in your hands, as always in this series.

If you want a web console to visualize your alerts, CrowdSec offers one, for free, where you enroll your engine with sudo cscli console enroll <your-key>. Optional, and hosted by CrowdSec, so weigh it according to your line. Your real dashboard, anyway, is Wazuh, and that’s the next step.

Step 5, make CrowdSec show up in Wazuh

Your firewall blocks, great. But for now, your SIEM doesn’t know. CrowdSec acts on its own, Wazuh looks elsewhere. We connect them, so that every CrowdSec decision becomes a visible alert in your single dashboard.

The principle is simple and clean. CrowdSec knows how to write its alerts to a file, and Wazuh knows how to read a log file. We make them meet.

On CrowdSec’s side, you enable the file notification plugin. It already exists, you edit /etc/crowdsec/notifications/file.yaml to make it write in JSON format, one alert per line.

type: file
name: file_default
log_level: info
format: |
  {{range. -}}
   { "crowdsec": { "program": "crowdsec", "alert": {{. | toJson }} }}
  {{ end -}}
log_path: "/var/log/crowdsec/crowdsec_alerts.json"
rotate:
  enabled: true
  max_size: 500
  compress: true

Then you declare this channel in /etc/crowdsec/profiles.yaml, so the engine sends its alerts there.

notifications:
    - file_default

A detail that counts. The official CrowdSec tutorial writes this file to /tmp, which is emptied on every machine reboot. We put it in /var/log/crowdsec/ instead, so your alert history survives a reboot. A crowdsec service restart, and the /var/log/crowdsec/crowdsec_alerts.json file fills up with every decision.

On Wazuh’s side, you tell the local agent, the one from episode 3 already installed on this server, to read this file. You add this block to its configuration, ideally via the shared configuration for the group so you only have to write it once.

<localfile>
  <location>/var/log/crowdsec/crowdsec_alerts.json</location>
  <log_format>json</log_format>
  <label>crowdsec</label>
</localfile>

You recognize the <localfile> logic, it’s exactly the mechanism by which Wazuh swallows any log source. The json format tells it to parse each line as a structured object, and your crowdsec.alert.* fields become queryable in the dashboard.

Restart the Wazuh agent, and the series’ loop is closed. An IP address attacks, CrowdSec blocks it, writes the alert, the Wazuh agent reads it, the manager sends it up, it shows up in your dashboard next to everything else. Your SIEM finally sees its own counterattacks.

A version note, because it matters. This integration via the file plugin assumes a recent engine and Wazuh version. Make sure your CrowdSec is at 1.6.3 or above and your Wazuh is at 4.9.0 or above, the versions from which this integration by the file plugin is officially supported. You’re running on Wazuh 4.x, this integration doesn’t depend on the future 5.0, it works on your current stack.

If it doesn’t work

The deployment of CrowdSec is straightforward, and it usually gets stuck at the same points. Here are the real ones, in the order you’ll encounter them.

Problem, cscli metrics shows zero lines read

Probable cause, the engine can’t find your logs, or it doesn’t have the collection for your service. It’s running, but it’s reading nothing.

Solution, make sure the log source exists at the expected path and that the service’s collection is installed with sudo cscli collections list. Install the missing collection, then restart the crowdsec service.

Problem, an IP address is decided but nothing is blocked

Probable cause, the bouncer isn’t there, or it isn’t talking to the engine. The engine decides on its own, nobody applies anything.

Solution, sudo cscli bouncers list should show your firewall bouncer with recent activity. If it’s absent, reinstall the bouncer package. If it’s present but silent, check that the bouncer service is running.

Problem, the wrong firewall backend

Probable cause, you installed the nftables variant of the bouncer on an iptables machine, or vice versa. The bouncer puts its rules in a system that your firewall doesn’t use.

Solution, identify your real backend, then install the corresponding variant of the bouncer, crowdsec-firewall-bouncer-nftables or crowdsec-firewall-bouncer-iptables.

Problem, nothing shows up in Wazuh

Probable cause, note that this is usually not a CrowdSec problem. The /var/log/crowdsec/crowdsec_alerts.json file grows on CrowdSec’s side. If it grows, the diagnosis is on Wazuh’s side, the <localfile> block and the agent version, not on CrowdSec’s side. Don’t reinstall CrowdSec for a Wazuh reading issue.

The community list makes up half the work

A final word, because this is the point we always underestimate at the start. The day you install CrowdSec, you expect it to learn slowly, to need weeks of traffic before it becomes useful. Wrong.

As soon as the first synchronization, you download the community list, and your sudo cscli decisions list -a populates with IP addresses you’ve never seen. Attackers spotted elsewhere, already blocked at your end. You benefit from the work of tens of thousands of other servers before you’ve even had your first attack.

It’s not magic, it’s volume. Every server that sends up a signal strengthens the defense of all the others. It’s exactly the model that the American SaaS sells you expensively and under its jurisdiction, except here it’s open source, self-hosted, and the shared signal is limited to the address of your attackers.

The turning point is passed. Where your SIEM used to just observe, it now blocks.

For the impatient

What this article does. We install CrowdSec on the hardened VPS to block malicious IP addresses known locally and signaled by the community network. The engine reads your logs and decides, the firewall bouncer applies the block on nftables or iptables, and every decision shows up in Wazuh via a file of alerts read by the agent. The defense goes from “seeing” to “barricading the door”.

Concretely, the commands.

Install the engine: curl -s https://install.crowdsec.net | sudo sh then sudo apt install crowdsec.
Check the detected collections: sudo cscli collections list.
Install the firewall bouncer according to your backend: sudo apt install crowdsec-firewall-bouncer-nftables (or -iptables).
Check the connection: sudo cscli bouncers list.
Check the machine: sudo cscli metrics and sudo cscli decisions list -a (the -a for seeing also the community list).
Test the blocking: sudo cscli decisions add --ip 192.0.2.1 --duration 4h --reason "test" then sudo cscli decisions delete --ip 192.0.2.1.
Check the community sharing: sudo cscli capi status.
Integrate with Wazuh: enable the file notification plugin in /etc/crowdsec/notifications/file.yaml (output /var/log/crowdsec/crowdsec_alerts.json), declare it in /etc/crowdsec/profiles.yaml, then add the <localfile> JSON block to the Wazuh agent’s configuration.

In summary

You started with a SIEM that saw attacks but couldn’t stop them, and now you’re ending with a first line that blocks them.

You installed the CrowdSec engine on your hardened VPS, which reads your logs and decides. You put the firewall bouncer, which applies these decisions on your firewall and really blocks. You connected the community list, which protects you from attackers you’ve never seen yourself, by only sharing their addresses. And you made everything show up in Wazuh, so your control room finally sees this defense layer.

It all stays with you. The engine is self-hosted, no decision depends on a third party, and the only signal that goes out is the IP address of your attackers. The protection collective without the dependence, that’s precisely the sovereign third way, opened in the series’ introduction episode.

You now block at the network level. But your most frequent attacks don’t come through the SSH port, they come through your mailbox. In episode 5, we’ll put the anti-spam and anti-phishing filter in front of your mail server, the most exposed door of all.

A final note on the series. Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS outside the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node.
Episode 3, agents everywhere. Deployment on your servers, Macs, and Windows machines.
Episode 4, the community network defense. Blocking known attackers before they arrive. You just read this.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac execution control. Deciding which applications get to launch.
Episode 7, alerting and honest cost. Calibrated notifications and honest financial breakdown against SaaS.

Technical terms? Check the glossary.

Install your first AI model locally on Mac

Mac Souverain — Mon, 06 Jul 2026 06:14:39 GMT

Previous Article: We set the stage. Your access to a distant AI model can be cut off overnight by an arbitrary decision, and the only thing still running the next morning… is nothing.

We also mapped out what a Mac Apple Silicon runs locally, from the small model that sorts your notes to the large model that writes.

That was the why. Here’s the how.

Good news up front: you need no technical skill, no command line, and no additional hardware. If you’re reading this on a recent Mac, you already have everything. Count twenty minutes, most of it watching a progress bar.

At the end, you have a capable model that responds entirely on your machine. And to prove it, at the very end, we’ll cut the Wi-Fi.

Read: Your AI can be shut down by the US, build your own

What you need

Three things, and you probably already have them.

A Mac Apple Silicon, that is, an M1 to M5 chip. Most Macs sold since late 2020 have one. If you have an Intel Mac, this method doesn’t apply, efficient local inference relies on Apple Silicon’s unified memory.

A reasonably recent version of macOS, Sonoma (14) or later for the tool we’ll use. If you haven’t updated in a while, now’s the time.

RAM, and that’s where the model choice comes in. Quick refresher from the previous article: on a 16GB Mac, once the system is served, you have 8 to 10GB left for AI, enough to run a 7 to 8 billion parameter model.

On a 32GB, you step up a class, up to a 24 billion parameter model. The golden rule, never choose a model that fills the entire budget, or your machine will struggle or crash.

If you want the RAM budget details and the full model map, it’s all in the previous article. Here, we install.

The tool: LM Studio, zero terminal

There are several ways to run a model locally. For a first step, one deserves to be singled out: LM Studio.

It’s a classic desktop app, with windows, buttons, and a search field. You download your models from an integrated library, click, chat. No command line, no config files to edit, no esoteric maneuvers. It’s local AI presented as a normal app, and for getting started, that’s exactly what you want.

LM Studio is free, for personal and professional use. And on Mac Apple Silicon, it comes with the best engine possible, we’ll get back to that in two minutes.

The curious and the hungry have other options, Ollama on the command line, MLX for going metal. We’ll mention them at the end, once you already have a running model. One thing at a time.

Install LM Studio

Nothing more than an ordinary Mac app.

Go to lmstudio.ai and download the Mac version. The site detects your machine and offers the right build, the one for Apple Silicon. You get a .dmg file, the usual Mac installation format.

Open the downloaded .dmg. A window appears with the LM Studio icon and a shortcut to your Applications folder. Drag the icon to the Applications folder, just like any other app. That’s it, nothing to check, nothing to configure.

Launch LM Studio from Launchpad or your Applications folder. On the first launch, macOS might ask you to confirm opening an app downloaded from the internet, confirm. The app opens on a welcome screen that offers to choose a first model. Let’s go.

Choose and download your first model

This is the crucial step, and the one where we’ll be precise, because not all models are equal and the right choice depends on your RAM.

Stick to the sovereign pick from the previous article. On a 16GB Mac, aim for Qwen2.5 7B, a model under Apache 2.0 license, truly free, that runs the essentials of daily life. On a 32GB Mac, aim for Mistral Small, a 24 billion parameter model, European and also under Apache 2.0, tailored for sustained writing and long document analysis.

In LM Studio, open the search tab, the magnifying glass icon in the sidebar, and type the model name. The library is connected to Hugging Face, the big model hub, so you’ll see several variants of the same model. That’s normal, and that’s where you need to know how to read.

Two things to decode on each variant.

The format. You’ll encounter two words, MLX and GGUF. Just remember this: MLX, the calculation framework made by Apple, is the engine optimized for Apple Silicon’s unified memory. On your Mac, an MLX version runs notably faster than the same one in GGUF, quality equal.

LM Studio comes with this MLX engine, might as well use it. Choose the MLX version of the model whenever it’s available. If a model only exists in GGUF, that’s fine, it still works, just a bit slower.

Quantization. You’ll see labels like 4bit, Q4, Q4_K_M, Q8. That’s the model’s compression level. A raw model weighs a fortune in memory, quantization reduces the precision of its weights to make it fit in your RAM, at the cost of a barely noticeable quality loss.

Q4, or 4bit, is the sweet spot for starting, it divides the model’s weight by about four without you noticing much of a difference. Q8 is more faithful but twice as heavy, keep it for later if you have the RAM.

In practical terms, what you’re downloading:

On 16GB, Qwen2.5 7B in MLX 4bit weighs around 4.3GB. It’s well within your RAM.
On 32GB, Mistral Small 24B in MLX 4bit weighs around 13 to 14GB. It’s within your margin without killing your machine.

Choose the right variant, MLX and 4bit, and click download. A progress bar appears, you can follow the download in the downloads tab. Time for a coffee break, the file is several gigabytes.

A word on version numbers. Models evolve, Mistral Small is already at a revision more recent than the one named in the previous article. Don’t sweat the exact number, just pick the latest Mistral Small 24B offered in MLX in LM Studio, that’s the one you want.

Your first prompt, then cut the Wi-Fi

The model is downloaded. Time for the moment of truth.

Open the Chat tab, the speech bubble icon in the sidebar. At the top of the window, a dropdown menu lets you load a model, select the one you just downloaded. LM Studio loads it into memory, a few seconds, and displays a familiar input field, a conversation, like any other assistant.

If LM Studio offers you a choice of engine, make sure it’s set to MLX. It’s usually automatic when you’ve picked an MLX variant, but a quick check doesn’t hurt.

Type your first prompt. Anything, preferably a real task, to feel what it’s like. “Summarize this text in three points”, “write a polite follow-up email”, “explain the difference between two concepts”. The model thinks for a few seconds, then responds, word by word, entirely from your machine.

And now, the demonstration that wraps up the previous article’s loop.

Cut the Wi-Fi. Click on the Wi-Fi icon in your menu bar and turn it off, or go to System Preferences. Your machine is now offline, cut off from the internet, unplugged from the world. Ask the model another question.

It responds.

There you have it. No request went out, not a single byte of your text left your Mac, and yet it works. That’s what a model running on your machine looks like. When they turn off the distant tap one morning, that one keeps running. You can turn the Wi-Fi back on, the demonstration is made.

Three settings that make all the difference

Your model is running. Three buttons deserve a mention, because they make the difference between a smooth machine and a struggling one.

Context length. That’s how much text the model can keep in mind at once, your question plus its response plus everything you’ve fed it. It’s set when you load the model, expressed in tokens, in the config panel. A high value lets you feed it long documents, but it consumes RAM in proportion. If your Mac is struggling, lower it. If you want it to digest a long PDF, raise it, keeping an eye on your RAM.

Quantization. We talked about it when downloading, it’s the quality-versus-weight lever. If your model is cramped in your RAM, more aggressive quantization (Q4 instead of Q8) makes it fit. If you have room to spare and want the best response, lighter quantization improves quality. You adjust by downloading another variant of the model, that’s the only point where you have to go back through the download process.

Unload the model. As long as a model is loaded, it occupies your RAM, even if you’re not using it. When you’re done, unload it, the eject button in the model selector frees up RAM all at once. Useful habit if you’re switching to a heavy task, video editing, coding, virtual machine, and you want your gigabytes back. Closing the window isn’t always enough, unload explicitly.

Going further

You have a running model, you’ve passed your first offline prompt. The rest is bonus, for when the urge to dig deeper strikes.

Ollama, for the curious of the command line. If the command line doesn’t scare you, Ollama runs a model with a single command. You install the app, open the Terminal, type ollama run mistral-small:24b, and it downloads the model then puts you in conversation, directly in the terminal. It’s sparser than LM Studio, but ruthlessly effective, and it opens the door to automation, plugging a local model into your own scripts via a local API. Ollama also takes advantage of Apple Silicon by using MLX.

MLX in action, for the hungry. The engine LM Studio uses under the hood, MLX, is an Apple framework that you can pilot yourself, with its toolbox mlx-lm. It’s the playground for those who want to maximize their unified memory, test custom quantizations, or run barely-out models. Reserved for those who enjoy the fine mechanics, but that’s where you’ll find raw performance on a Mac.

For most everyday uses, you’ll never go beyond LM Studio, and that’s perfectly fine.

Wrap-up

What you’ve just done. You installed a free app, downloaded a model in MLX tailored to your RAM, passed a first prompt, and verified with Wi-Fi off that nothing was leaving your Mac. Twenty minutes, zero command line, zero dependency on a model that a third-party IA can shut down.

This model is yours. No one can cut it off, charge you per request, or decide one morning that your nationality doesn’t suit them. It won’t replace the best distant model for the toughest tasks, we said so, and that’s not the point. Its value is that it’s there, on your machine, all the time, for the bulk of what you do.

The base is set. Next up, using it for real, for all the tasks you can.

Read: Apple Intelligence: what really comes out of your Mac

Sources

The tool

LM Studio, the desktop app to run models locally, free, with MLX engine on Apple Silicon.
LM Studio, system requirements, Apple Silicon M1 to M4 and macOS 14 or later, 16GB RAM recommended.

The models

Qwen2.5 7B Instruct, MLX 4bit, 4.28GB, Apache 2.0 license, the pick for a 16GB Mac.
Mistral Small 24B, MLX 4bit, around 13GB, Apache 2.0 license, the pick for a 32GB Mac.

Going further

Ollama, run a model with a single command, with local API.
Apple MLX, the framework optimized for Apple Silicon’s unified memory.

Technical terms? Check the glossary.

Wazuh 5.0 lands, your home SIEM evolves

Mac Souverain — Thu, 02 Jul 2026 07:22:47 GMT

Wazuh 5.0 lands in public beta, revamps its architecture, Filebeat’s gone, clustering enabled by default, new engine. If you’ve set up your SIEM with our series, your 4.x install is still running, the upgrade to 5.0 won’t be blind.

What changes for you

1. Check your version with wazuh-control info, recent 4.11 and later still receive updates.

2. Snapshot your VM and backup /var/ossec/etc/ before attempting the 5.0 upgrade.

3. Wait for a stable 5.0.x release (5.0.1 or 5.0.2) before migrating, we’ll update the SIEM series then, migration guide included.

If you’ve set up your home SIEM following episode 2/7 of the Sovereign SIEM series, brace yourself: Wazuh 5.0 is here in public beta, and it’s shaking things up. Don’t panic, but do take a look before blindly updating. And we’ll update the SIEM series when the time comes.

The Deal

Wazuh has just released the public beta of its 5.0 version, with a stable release estimated for late June or early July 2026. This isn’t just a version bump, it’s an architectural overhaul.

What’s changing, concretely: Filebeat is gone, replaced by a native indexer-connector integrated into the manager. Every Wazuh server becomes a cluster node by default, even in a single-server install. The old analysisd engine, which handled logs and triggered rules, is replaced by a new one. Vulnerability detection has shifted to Wazuh Indexer, centralized. And Role-Based Access Control (RBAC), fine-grained permissions management, has been entirely revamped.

Direct consequence for MacSouverain: episode 2/7 of the Sovereign SIEM series, which documents the 4.x architecture step-by-step, will be partially outdated once 5.0 is released. We’ll update the series when 5.0 is stable, not before.

Why It Matters to You

If you’ve followed the guide in episode 2/7 of the Sovereign SIEM series to set up your own SIEM, you’re likely running on a 4.x version. Good news, your setup continues to work, no one’s pulling the plug. Bad news, upgrading to 5.0 won’t be as simple as apt upgrade without reading the docs. Bye-bye Filebeat, that means your log pipeline’s plumbing is changing. Default cluster, that changes your initial config even if you’re sticking to one machine.

Practical translation: if you were planning to upgrade as soon as it’s out, take an hour to read the release notes and make a snapshot first. If you’re on a stable setup you use daily, wait for one or two corrective versions, let the early adopters iron out the kinks.

What It Changes for You

1. Note which version of Wazuh you’re currently running. On your manager, use wazuh-control info or check the dashboard. If you’re on 4.11 or later, you’re on the branch that’s still receiving updates.

2. Before attempting to upgrade to 5.0, snapshot your VM or backup your config /var/ossec/etc/ and your Wazuh Indexer’s state. A clean rollback saves your bacon if the new engine doesn’t play nice with your custom rules.

3. Wait for the stable 5.0.x release (at least 5.0.1 or 5.0.2) before migrating a production personal install. Beta’s for testing on disposable VMs, not the one monitoring your network every day. Keep an eye on: Wazuh’s official migration guide from 4.x to 5.0, and the upcoming overhaul of episode 2/7 of the Sovereign SIEM series on MacSouverain.

Sources

Wazuh 5.0 Public Beta Discussion (GitHub)

Chat Control: The EU's playing with your encryption's fate.

Mac Souverain — Wed, 01 Jul 2026 13:46:25 GMT

June 29th saw the EU’s 5th and final trilogue on Chat Control 2.0 (CSAR). At stake: mass scanning of your private messages before encryption, versus a Parliament defending end-to-end. The outcome’s now, deciding if WhatsApp, Signal, and iMessage stay truly encrypted in Europe.

What to watch:

1. The publication of the trilogue’s outcome (or failure) and whether there’s an explicit exemption for end-to-end encryption.

2. The return of « Chat Control 1.0 » (extended voluntary scanning) that Metsola threatens to reopen if 2.0 stalls: a Trojan horse if negotiations fail.

3. Mandatory age verification, which kills online anonymity far beyond fighting CSAM.

What Happened on June 29th

Under Cypriot presidency, the EU Council held what was billed as the fifth and final trilogue on the CSAR regulation, dubbed « Chat Control 2.0 », on June 29th. The presidency’s stated goal was to secure a political agreement before the summer break.

The sticking point remains unchanged. On one side, a Council text that mandates mass surveillance of private communications via ‘detection orders’, a provision that the Council’s own legal service deems contrary to Article 7 of the Charter of Fundamental Rights. On the other, a Parliament that, on March 26, 2026, rejected mass surveillance by a single vote (307 to 306), and is holding firm to end-to-end encryption protection.

As of now, no official source has published the outcome of this trilogue: neither success nor failure confirmed. The Cypriot presidency is pushing for formal adoption in July, but the impasse over encryption could still derail everything. Keep an eye on this silence in the coming days.

Why It Matters to You

Client-side scanning requires inspecting your messages on your device, before they’re encrypted. The crypto of WhatsApp, Signal, or iMessage isn’t broken, it’s neutered: your message is read plaintext on your phone before it’s sent. And this inspection point isn’t reserved for ‘nice guys’, it’s exploitable by any attacker who gets their hands on it.

Adding to this is the mandatory age verification, which requires tying a real identity to your messaging account. It’s the end of default anonymity, sold under the guise of child protection.

What You Can Do

Nothing to install today: it’s a political signal, not a product flaw. But keep Signal as a fallback messaging option, watch your MEP’s positions, and follow EDRi / Patrick Breyer for real-time updates. Once it’s published, we’ll update our articles on the topic.

Deploy Wazuh everywhere, your SIEM finally sees your network

Mac Souverain — Wed, 01 Jul 2026 12:50:41 GMT

In the previous episode, you set up a security console that runs Wazuh on your hardened VPS, acting as a manager, indexer, and dashboard on a single node, with the dashboard locked to Tailnet-only. A fine machine, but for now, it only sees itself.

That’s useful, your server monitors itself, validates your hardening, and reports its own CVEs. But a SIEM that only looks at the server it’s running on is like a camera pointed at its own box. Today, we’re turning it towards the rest of the room.

We’re going to deploy Wazuh agents on your fleet. Your Linux servers, Macs, and Windows machines. Each machine gets a sensor that collects its logs, security events, and file integrity, and sends it all back to the manager. Your SIEM goes from nearsighted to panoramic.

One non-negotiable rule, set from episode 1 and commanding this whole chapter. This communication goes through the Tailnet, never through the open internet. The manager only listens on your private mesh. An agent not in your Tailnet talks to nothing.

This stack, I use daily. The commands that follow are the ones you’ll type yourself, in order, on your manager, then on each machine to monitor.

Before you start

Three things to keep in mind before the first command.

What you need. The Wazuh manager from episode 2, operational. Administrator access on each machine to enroll. And most importantly, each machine to monitor must be a member of your Tailnet, just like your manager. You’ll run tailscale up on each endpoint. Without it, nothing comes back.

What changes. At the end, your dashboard won’t list a single agent, but as many as you have machines. Each one reports its logs, audit configuration, vulnerabilities, and file integrity, all in one place, under your single eye.

What doesn’t change. An agent observes, it doesn’t block anything. It tells you when an application starts, when a file changes, when a connection fails. Deciding which applications have the right to launch on your Macs, that comes later, with another tool, in another episode. Here, we’re just looking. We’re not blocking anything yet.

Opening the right doors, and only those

Before touching any endpoints, a gesture on the manager. Until now, your server hasn’t been listening to the outside world on anything, and the dashboard has been folded onto the Tailnet. Remote agents need to reach the manager on two ports.

Port 1515, for enrollment. That’s the initial handshake, encrypted, where a new agent introduces itself and receives its authentication key.
Port 1514, for reporting logs and events, once the agent is enrolled.

And that’s where your sovereignty comes into play. Those two ports, you open only on the Tailscale interface, never globally.

sudo ufw allow in on tailscale0 to any port 1514 proto tcp
sudo ufw allow in on tailscale0 to any port 1515 proto tcp

You recognize the gesture, it’s the same one as SSH in episode 1, the same one as the dashboard in episode 2. You allow on tailscale0, your encrypted mesh, and nowhere else. The trap would be to type sudo ufw allow 1514/tcp all on its own. That command opens your SIEM to the world’s scanners. Ours keeps it invisible.

Check your firewall status.

sudo ufw status

You should see your two new rules, both marked on tailscale0. If there’s a global 1514/tcp hanging around, get rid of it without hesitation, that’s a breach.

Last thing to note, the Tailscale address of your manager, the one every agent will target.

tailscale ip -4

That’s the address you’ll pass to the agents. Not the VPS’s public IP, it doesn’t listen on these ports anyway. In everything that follows, I’ll note it as <IP_TAILSCALE_OF_THE_MANAGER>.

Step 1, enrolling a Linux server

We start with the simplest one, an Ubuntu or Debian server. Three steps, add the Wazuh repository, install the agent and give it the manager’s address, start it up.

First, the official repository.

sudo apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee -a /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

Nothing exotic. You import the signature key for the repository, declare the Wazuh repository, refresh the package list. Standard APT routine.

Then, the installation, with the trick that does all the work. Prefixing the installation command with the WAZUH_MANAGER variable tells the package which manager to enroll with during installation.

sudo WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent

The WAZUH_AGENT_GROUP="linux" puts this machine in a group named linux. You’ll see what groups are for later, just remember to assign them now.

Finally, start the service and enable it on boot.

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

And there you go, your Linux server is reporting. If you’re running on RHEL, Alma, or Rocky, the principle is the same, just replace the APT repository with the YUM one and apt-get install with dnf install. The WAZUH_MANAGER variable works the same way.

Step 2, enrolling a Mac

Macs get interesting because macOS has its own rules. Let’s start with the deployment, the twist comes right after.

The Mac agent comes as a .pkg package, and there are two versions, one for Apple Silicon and one for old Intel Macs. On a recent fleet, it’s Apple Silicon.

curl -O https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.5-1.arm64.pkg
echo "WAZUH_MANAGER='<IP_TAILSCALE_OF_THE_MANAGER>' && WAZUH_AGENT_GROUP='macos'" > /tmp/wazuh_envs
sudo installer -pkg wazuh-agent-4.14.5-1.arm64.pkg -target /

The mechanism changes a bit in form but not in substance. On macOS, deployment variables don’t go in front of the command, they’re written to a temporary file, /tmp/wazuh_envs, that the installer reads on the fly. The result is the same, the agent knows its manager and its group. For an Intel Mac, replace arm64 with intel64 in both lines that mention it.

Then, start the agent.

sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist

On macOS, the agent lives under /Library/Ossec/, and its control binary is /Library/Ossec/bin/wazuh-control, with the start, stop, and status verbs if you want to pilot it by hand.

The macOS landmine, TCC and full disk access

Now, the truth that most tutorials gloss over. On macOS, your agent will start, enroll, appear active in the dashboard, and yet remain half-blind.

The reason is TCC, for Transparency, Consent and Control, Apple’s permission system by usage. It filters access to sensitive folders, and it doesn’t cut any corners. The agent isn’t an application in Apple’s sense, it’s a package of binaries. Without explicit permission, it’s refused access to the zones TCC protects. Its file integrity monitoring turns on, but it can’t read what it can’t see.

The workaround is to grant the agent full disk access. On a managed fleet, that’s done properly with MDM, a configuration profile pushed by Jamf or equivalent, that declares the permission once and for all on all machines. On a single machine, you do it by hand in the privacy settings. That’s an extra step on top of Linux, and it’s specific to Apple, so keep that in mind before you’re surprised that the Mac reports less than the server.

Step 3, enrolling a Windows machine

Windows, last one in. The agent installs via an MSI package, in silent mode, from a PowerShell console opened as an administrator.

msiexec.exe /i.\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_NAME="accounting-post" WAZUH_AGENT_GROUP="windows"

Same logic as everywhere, the manager, a readable name for the machine, and its group. The WAZUH_AGENT_NAME is handy on Windows, where you’ll soon have ten machines that look the same, so it’s nice to give them names.

Then, start the service.

Start-Service WazuhSvc

In CMD, that’s NET START WazuhSvc, take your pick. The agent installs under C:\Program Files (x86)\ossec-agent.

What Windows brings specifically is reading Windows event logs, the famous Security, System, and Application trio, where failed login attempts, privilege elevations, and account creations land. And the FIM can monitor the registry, malware’s favorite playground for surviving reboots. Your Windows machine is no longer a black box.

Step 4, verifying that everything’s reporting

Three machines enrolled, time to make sure they’re talking to the manager. Back on the Wazuh server, one command.

sudo /var/ossec/bin/agent_control -l

It lists all your agents with their ID, name, and status. Four possible statuses, and you need to know how to read them.

Active, the agent is connected and reporting. That’s what you want to see everywhere.
Pending, it just enrolled and is waiting for its first full handshake. That’s temporary, give it a minute.
Disconnected, it was connected and isn’t anymore. The manager considers an agent lost if it hasn’t given a sign of life in fifteen minutes.
Never connected, it enrolled but never managed to report. That’s the classic symptom of a closed port or a machine outside the Tailnet.

The same table exists on the dashboard, prettier to the eye. The Agents view shows the count of Active, Disconnected, Pending, Never connected, and the details of each machine, its modules, its last activity. That’s your control room, now populated.

And there’s the shift. Each active machine runs, on itself, exactly the modules your server was running on itself in episode 2. The CIS configuration audit. Vulnerability detection on its packages. File integrity monitoring. Log analysis. Except now, it’s not one machine, it’s your fleet, and everything converges on one screen.

Going further, monitoring a specific folder

By default, the agent monitors sensitive system directories. But you’ve got a folder that matters more than the others, your client data, your accounting, a shared drive. You want to know, down to the second, if anyone touches it.

That’s the FIM’s job, File Integrity Monitoring. And instead of editing each machine by hand, you use groups that you assigned during enrollment. A group shares a configuration, pushed automatically by the manager to all its members. You write once, it applies everywhere.

On the manager, edit the shared configuration file for the relevant group, for example /var/ossec/etc/shared/linux/agent.conf, and declare the folder to monitor in the <syscheck> block.

<syscheck>
  <directories check_all="yes" realtime="yes">/srv/client-data</directories>
</syscheck>

Two attributes to understand. check_all="yes" records everything that characterizes a file, its cryptographic hashes, its size, its owner, its permissions, its dates. Any change is spotted. realtime="yes" asks for real-time monitoring, the alert comes at the moment of the change, without waiting for the next scan.

A note of honesty on that real-time. It’s only available on Linux and Windows. On macOS, the FIM falls back on scheduled scans, periodic. A modification between two passes is only seen on the next pass. That’s not a bug, it’s a macOS limitation, but keep that in mind before you count on an instant alert on the Mac side. Another detail that trips people up, the folder must exist before you restart the agent, or it’s ignored.

If it’s not working

Deploying agents is simple when everything goes right, and it always has the same handful of causes when it goes wrong. Here are the real ones, in the order you’ll encounter them.

Problem, the agent stays in ‘Never connected’

Probable cause, in nine cases out of ten in our case, a network path issue. Either the manager’s ports 1514 and 1515 aren’t open on tailscale0, or the machine isn’t in the Tailnet, or you gave the agent the VPS’s public IP instead of its Tailscale address.

Solution, check those three. On the manager, sudo ufw status should show your two new rules both marked on tailscale0. On the endpoint, tailscale status should confirm it’s in the mesh. And re-read the value of WAZUH_MANAGER, it should point to the manager’s Tailscale address, not its public IP.

Problem, the agent goes from ‘Active’ to ‘Disconnected’

Probable cause, it was reporting, it’s not anymore. The manager cuts off after fifteen minutes without news. Often, the agent service has stopped, or the Tailscale link has dropped.

Solution, check that the service is running. sudo systemctl status wazuh-agent on Linux, Start-Service WazuhSvc on Windows, /Library/Ossec/bin/wazuh-control status on macOS. And take a look at the agent’s log, always in the same place depending on the platform, /var/ossec/logs/ossec.log on Linux, /Library/Ossec/logs/ossec.log on Mac, the installation folder on Windows.

Problem, the Mac is ‘Active’ but isn’t reporting much

Probable cause, the infamous TCC. The agent is running, but without full disk access, it’s blind on the zones macOS protects.

Solution, grant the agent full disk access, by MDM on a managed fleet, by hand on a single machine in the privacy settings.

Problem, the agents are ‘Active’ but the dashboard stays empty

Probable cause, that’s not an agent problem. If the machines are reporting but nothing appears in the interface, the culprit is downstream, between the manager and the indexer. Remember episode 2, Filebeat pushes alerts to the indexer.

Solution, diagnose on the server side, not on the agent side. Check that Filebeat is talking to the indexer and that the indexer is digesting. Don’t waste an hour reinstalling agents that are working perfectly.

The first day is noisy, that’s normal

One last word of honesty, because I’d rather you hear it from me before you figure it out on your own. The day you plug in ten machines at once, your dashboard is going to explode.

Each machine arrives with its configuration audit reporting dozens of deviations from the CIS baseline. Each FIM reports legitimate files that change as they’re used. At first, the noise drowns out the signal, and that’s disorienting.

That’s not a bug. That’s the raw state of a SIEM you’ve just turned on in a real fleet. The work that follows, calibrating rules, filtering out false positives, adjusting thresholds so you’re only woken up when it matters, that’s human work, not magic software. We said it from the start of the series, the hard part isn’t the tech, it’s the tuning. That fine-tuning, that calibrated alerting, that’s episode 7’s payoff.

For now, enjoy. Your SIEM isn’t looking at its own belly anymore, it’s seeing your network.

For the impatient

What this article does. You deploy Wazuh agents on your fleet, your Linux servers, Macs, and Windows machines. Each machine reports its logs, configuration audit, vulnerabilities, and file integrity to the manager. Everything goes through the Tailnet, never through the open internet. You verify the enrollment, extend file monitoring via groups, and weather the first day’s noise.

Concretely, the commands.

On the manager, open ports 1514 and 1515 on tailscale0 only: sudo ufw allow in on tailscale0 to any port 1514 proto tcp, then the same for 1515. Never globally.
Prerequisite, every endpoint must be in the Tailnet (tailscale up).
Linux: add the Wazuh repository, then sudo WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent, then systemctl enable --now wazuh-agent.
macOS: curl -O the .pkg arm64, write the variables in /tmp/wazuh_envs, sudo installer -pkg... -target /, sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist. Then grant the agent full disk access.
Windows: msiexec.exe /i.\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_GROUP="windows", then Start-Service WazuhSvc.
Verify from the manager: sudo /var/ossec/bin/agent_control -l, aim for ‘Active’ everywhere.
Extend FIM via the group, in /var/ossec/etc/shared/<group>/agent.conf, <syscheck> block with check_all="yes" realtime="yes" (real-time Linux and Windows only, not macOS).

In summary

You started with a SIEM that only saw itself, and you end with a SIEM that sees your fleet.

You opened the agent ports on the Tailnet only, 1514 and 1515 on tailscale0, never globally. You enrolled your three families of machines, Linux in three commands, Macs managing TCC, Windows in silent MSI. You verified the reporting with agent_control -l and in the dashboard, and you extended file monitoring on your sensitive folders via groups.

Each machine you plug in is free on the license side, it’s 100% open source, no limit on agents. Where the American SaaS charges by log volume, by the number of machines, the more you see, the more you pay. With you, seeing more costs nothing.

But you’re observing. You see attacks, you’re not blocking anything yet. In episode 4, you add the first active line of defense, CrowdSec, the community network that blocks known attackers before they even knock on your door. Your SIEM starts to bite.

Series recap

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS outside the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node.
Episode 3, agents everywhere. Deploying Wazuh on your servers, Macs, and Windows machines. This one.
Episode 4, community network defense. Blocking known attackers before they arrive.
Episode 5, email filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac launch control. Deciding which applications have the right to launch.
Episode 7, alerting and honest cost. Calibrated notifications and honest financial breakdown against SaaS.

Technical terms? Check the glossary.

Wazuh: Your all-in-one, homegrown Splunk for the price of a VPS

Mac Souverain — Sat, 20 Jun 2026 13:13:52 GMT

In the previous episode, you set up an empty safe: a VPS on a Swiss host, hardened to the bone, SSH via key, firewall closed, administration behind Tailscale, encrypted backups off-site. A nice machine. But for now… it’s not watching anything!

Today, we’re filling it up. We’re installing Wazuh, the brain of the whole stack, on this single node. Manager, indexer, and dashboard, the three central components of a SIEM, on the same machine. It’s the all-in-one mode, and that’s exactly what a small business needs to start with.

The promise of the series is in one sentence, set at the opening. The functional equivalent of a Splunk, for the price of a VPS. By the end of this article, you’ll have a security console running, seeing your own machine already, and it won’t have cost you a single euro in licensing. Whereas the same perimeter with an American vendor would run from a few thousand to tens of thousands of dollars per year, depending on the size of your fleet, with your logs stored in a very unfavorable jurisdiction.

This stack, I use every day. The commands that follow are the ones you’ll type yourself, in order, on the server from episode 1.

Three components, one machine

Before installing, understand what you’re installing. A SIEM Wazuh isn’t a monolithic block, it’s three roles that pass the baton.

The manager is the brain. It receives logs, runs the analysis engine, correlates events, applies rules, and raises alerts. It’s the one that decides that a sudden spike of failed login attempts at 3 AM deserves to wake you up.
The indexer is the memory. It stores and indexes alerts so you can search, filter, and go back in time. It’s a fork of OpenSearch, the open-source search engine, which is itself a fork of Elasticsearch. Remember this detail, it’ll come back to bite us in the best possible way.
The dashboard is the window. The web interface through which you read all this, accessible on port 443. It queries the manager for configuration and the indexer for data.

A fourth player works in the shadows, Filebeat, the pipe that pushes alerts from the manager to the indexer. You won’t touch it, but when something goes wrong, it’s often the first thing you look at.

In an enterprise, these three components live on separate machines to handle the volume and maintain high availability. For a small business with up to a hundred machines being watched, it’s overkill. The all-in-one mode puts all three on the same server, and that’s more than enough to start with. The official documentation even sizes this mode for 1 to 100 agents.

We’ll come back to the moment when all-in-one isn’t enough later on. But for now, one machine, and let’s go.

Installation in one command

Wazuh offers two paths. The first, step-by-step, installs the indexer, then the manager, then the dashboard separately, editing the configuration files by hand. It’s educational, it’s long, and you don’t need it for a single node. The second is the official assistant, which does everything at once.

We’re taking the assistant.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash./wazuh-install.sh -a

Let’s break it down. The curl -sO downloads the installation script from the official Wazuh repository, branch 4.14. The sudo bash./wazuh-install.sh -a runs it with admin rights, and the -a flag means all-in-one, all on one machine. This flag tells the assistant to install and configure the three components on this same machine, generate TLS certificates for secure communication between them, and create passwords.

At the end, the assistant displays the admin password in the console. Note it down, it’s your first key to the kingdom. If you missed it while scrolling through the terminal, you can retrieve it properly with:

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

This command extracts, without decompressing onto the disk, the file that lists all the passwords generated during installation. We’ll deal with these passwords in a moment, because passwords generated by a script are just a starting point, not a final destination.

At the time of writing, the stable version is 4.14.5, released on April 23, 2026. The installation URL points to 4.14/, so you’re still getting the latest version of that branch. If a 4.15 has been released when you’re reading this, check the current branch on the release notes page before running the command.

The memory trap, where 90% of installs fail

If there’s one thing you should remember from this episode, it’s this. The number one cause of Wazuh installs that struggle, crash, or die after a few days is poorly configured memory on the indexer.

Remember, the indexer is a fork of OpenSearch, which runs on the JVM, the Java virtual machine. And the JVM reserves a fixed zone of memory for itself at startup, called the heap (or the “heap space”). Too small, the indexer suffocates under the data. Too big, it takes up all the RAM and starves the manager, dashboard, and OS running alongside it on the same machine. That’s the whole point of the single-node setup, three big memory hogs sharing one envelope.

The official rule is clear and simple. The heap is half of the machine’s RAM. And both the minimum and maximum boundaries should be the same.

Why the same? Because if you let the JVM resize its heap on the fly, it spends all its time reallocating memory instead of indexing your logs. By fixing the floor and ceiling at the same value, you’re telling it “here’s your sandbox, not a byte more or less, now get to work”.

You set this in a file, /etc/wazuh-indexer/jvm.options.

sudo nano /etc/wazuh-indexer/jvm.options

Find the two lines -Xms (the lower bound) and -Xmx (the upper bound), and set them to half of your RAM. That’s why episode 1 had you aim for 12 GB of RAM, not 8. On a 12 GB machine, the heap takes up 6 GB, leaving 6 GB for everything else, the manager, dashboard, Filebeat, and the system. Plenty of room to breathe.

-Xms6g
-Xmx6g

Then restart the indexer to apply the new value.

sudo systemctl restart wazuh-indexer

If you started with 8 GB to test, your heap value is -Xms4g / -Xmx4g, and you’re living on the edge with 4 GB left for everything else. It’s tight, but it works.

One last detail for the curious. The “half of RAM” rule also has an absolute ceiling, around 32 GB of heap. Don’t worry about this for now, it’s a good general OpenSearch practice, not a Wazuh-specific limit, and at the scale of a small business, you’re nowhere near it. I’m just mentioning it so you’re not surprised if you run into it later while scaling up a bigger infrastructure.

While we’re on the topic of memory, a related rule. The JVM should never swap. If the system starts using the disk as additional memory for the indexer, performance tanks. On a properly sized VPS, with the heap set to half of RAM, you shouldn’t be swapping. But it’s the first thing to check when things start to slow down.

Locking down the house

The installation gives you a functional console. It also gives you passwords generated by a script and a dashboard that, by default, wants to be accessible. Two things to take back under your control before you take your seat.

Change all the default passwords

The passwords generated during installation aren’t bad in and of themselves, but they’re sitting in a file on the server, and you didn’t create them. Good hygiene dictates that you regenerate everything with your own secrets. Wazuh comes with a tool for this, deposited by the assistant in the indexer.

sudo bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -a -A -au wazuh -ap <CURRENT_PASSWORD>

The -a flag targets all users, -A applies the change, and the -au / -ap pair provides the current admin user and password. In all-in-one mode, the tool automatically propagates the new passwords to the relevant components. You don’t have to recopy them one by one.

Your new passwords should meet a minimum complexity, 8 to 64 characters, with at least one uppercase letter, one lowercase letter, one number, and one symbol from .*+?-. Generate them with your password manager, don’t make them up on the spot.

Certificates, already there

Good news, you don’t have to do anything on the internal encryption front. The -a flag on the assistant generated a little certificate authority and deposited the certificates under /etc/wazuh-indexer/certs/ and so on. The three components are already talking to each other securely. It’s done, it’s clean, don’t touch it.

The only visible effect is that when you first access the dashboard, your browser will show a security warning because the certificate is self-signed and not recognized by a public authority. That’s normal, and for a dashboard that won’t be exposed to the public, it’s perfectly acceptable. Click through the warning, and you’re in.

A quick note to anticipate the temptation. You might want a “real” certificate, via Let’s Encrypt. Don’t do it here. Let’s Encrypt validates your certificate by verifying that your server responds on the internet, which means you have to open a port to the world. That’s the exact opposite of what we’ve been building since episode 1.

If the self-signed certificate really bugs you, Tailscale can emit a proper certificate for your node without any public exposure. But honestly, for a console that only you’ll be consulting, the self-signed certificate is good enough. We’re not going to punch a hole in the wall we just built to make a browser warning go away.

The dashboard, invisible from the internet

This is the most important security gesture of the episode, and it’s the one that separates a sovereign SIEM from one sitting on the curb. By default, nothing guarantees that your dashboard will stay private. The port 443 serving the interface should never be accessible from the internet.

Your security dashboards, they’re maps of your weaknesses, exactly what an attacker dreams of seeing.

The series’ rule, set in episode 1, is inflexible. No public services. The dashboard lives behind Tailscale, accessible only to you, just like SSH did before it.

Two locks, working together. First, we ask the dashboard to only listen on the Tailscale IP of the server, not on all interfaces. That’s set in its configuration file.

sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Find the server.host line. If it’s set to 0.0.0.0, the dashboard is listening on all interfaces, including the public IP. That’s a no-no. Set it to the Tailscale IP of your server, the one you get with tailscale ip -4, from episode 1.

server.host: "<YOUR_TAILSCALE_IP>"

Then restart the dashboard.

sudo systemctl restart wazuh-dashboard

Next, the firewall, as a belt and braces. We’re following exactly the pattern from episode 1 for SSH, allowing port 443 only on the private network interface, never globally.

sudo ufw allow in on tailscale0 to any port 443 proto tcp

The pitfall to avoid is typing sudo ufw allow 443/tcp on its own. That command opens the dashboard to the whole world. Ours only opens it on tailscale0, your encrypted mesh. The difference is not cosmetic, one exposes your security console to internet scanners, the other makes it invisible.

The result is a dashboard accessible only by a member of your private network. A scan of your public IP reveals nothing. In line with the sovereign promise, and in line with common sense.

The grand tour

Log in. From a machine on your Tailnet, open https://<YOUR_TAILSCALE_IP> in your browser. Certificate warning, click through. Login admin, your new password. You’re in the console.

This screenshot is from a production Wazuh instance already populated with several agents. On your fresh install, you’ll only see agent 000, the server watching itself.

And there’s a pleasant surprise, it’s not empty. You were expecting maybe an inert screen while you deploy agents. Not at all. In all-in-one mode, the server comes with a local agent, with the ID 000, watching itself. Your machine is already under the eye of your own SIEM, before you’ve even touched the rest of your network.

In practical terms, you’ve already got data and several modules running on this node.

SCA, for Security Configuration Assessment, is active by default, without any tuning, and it scans your machine against baseline security type CIS benchmarks. It tells you where your config deviates from best practices, a service too many, a permission too broad, a loose SSH setting. You’ll probably find, validated in black and white, the hardening decisions from episode 1.
Vulnerability detection is on by default, but not active. Wazuh inventories the packages installed on the machine and crosses them with known CVE databases. If one of your packages has a published vulnerability, it flags it, with the reference and severity. A note of honesty, unlike SCA and FIM, which run on their own, the local node scan doesn’t trigger on startup. You have to enable it in the /var/ossec/etc/internal_options.conf file, set vulnerability-detection.disable_scan_manager to 0, then restart the manager. Two minutes later, your own machine is scanned too.
File Integrity Monitoring, or FIM, is watching your sensitive files and alerting you if any of them change. A sudden change in a system file is often the first sign that you’ve got an unwanted guest.
Local log analysis, digesting the machine’s logs and turning them into readable alerts.

And there are the compliance dashboards, ready to go. Wazuh ships with views tagged PCI DSS, HIPAA, GDPR, NIST 800-53, TSC, with report generation. Each alert carries the compliance ID it touches, for example a gdpr_IV_32 tag that points to article 32 of the GDPR on security of processing.

A necessary honesty note on NIS2. Wazuh provides all the functional bricks that NIS2 demands, continuous monitoring, file integrity, vulnerability analysis, configuration control, reporting. But it doesn’t have a NIS2 compliance dashboard ready to click like it does for GDPR.

To follow NIS2 finely, you’ll build your own views, leaning on the GDPR and NIST tags already present. Wazuh gives you the compliance toolkit, it doesn’t make you compliant all by itself. The calibration of rules, retention policy, incident response, that’s all human work. We called it out right from the opening, the hard part isn’t the tech, it’s the adjustment.

For now, your SIEM is seeing itself. It’s watching its own machine, and that’s already precious for validating your hardening. The real jump is when it starts seeing the rest of your network. That’s episode 3, deploying agents, the moment when your SIEM starts really seeing your network.

When all-in-one isn’t enough anymore

The single-node setup isn’t magic, and I’m not going to sell you the opposite. It has a ceiling, and it’s important to know where it is before you hit it.

The metric that matters is EPS, events per second that your machine can handle. A well-dimensioned node, around 16 GB of RAM and 8 vCPUs, can handle around 5,000 events per second. For a small business with up to 50 or 100 machines being watched, with normal log activity, you’re well below saturation. The all-in-one mode holds up just fine.

The day you approach saturation, the symptom is unpleasant. When the ingestion queue saturates, Wazuh doesn’t slow down politely, it drops events it can’t process fast enough. And an event dropped is an alert you’ll never see. A camera that stops recording during rush hour.

When that happens, you switch to multi-node, manager on one side, indexer on the other, or even several of each. Detail against intuition but important, Wazuh scales better horizontally than vertically. Two nodes with medium resources are better than one big node. That’s another project, outside this series, but you know now that the door exists.

For a small business just starting out, remember this, all-in-one is perfect for starting, not designed for infinity. And there’s plenty of room between the two.

What it would have cost you elsewhere

We’ve been teasing this figure since the series opened. Time to put it down, for this specific component.

Wazuh’s licensing cost is zero. It’s 100% open source, under GPLv2 license, and there’s no paid tier. No agent limit, no user limit, no log ingestion limit. Your only expense is the VPS you set up in episode 1, between 15 and 30 euros per month depending on the size, plus your installation and calibration time. And that’s it.

Splunk’s bill has a different face. A warning first, Splunk doesn’t publish its prices officially, so everything that follows is an order of magnitude estimate based on secondary serious sources, not the official quote. With that reservation, the principle is simple, you pay by the gigabytes of logs ingested per day, counted in gigabytes per day.

The challenge is to translate that into a real-world park size, because a price per gigabyte doesn’t mean anything until you know how many gigabytes a small business produces. Useful benchmark, with reasonable security logging, count around fifty megabytes of logs per workstation per day, so around one gigabyte per day for fifteen to twenty workstations. From there, we can put some numbers on it, licensing only, keeping Wazuh in the mirror.

15 workstations, around 1 GB of logs per day. Splunk, around 2,000 to 5,000 dollars per year. Wazuh, the VPS, 180 to 360 euros per year. That’s the point.
50 workstations, around 4 to 5 GB per day. Splunk, around 8,000 to 12,500 dollars per year. Wazuh, the same VPS, to the euro.
100 workstations, around 8 to 10 GB per day. Splunk, around 15,000 to 25,000 dollars per year. Wazuh, still the same VPS.

Beyond a hundred workstations surveilled, we’re in another world on both sides, multi-node clusters on Wazuh, paliers in the tens or hundreds of thousands of dollars per year on Splunk. That’s another scale, outside the perimeter of this series thought for the small business.

The difference isn’t just about money. It’s about trajectory. With Wazuh, your infrastructure cost is flat, you ingest more logs, your VPS handles it, your bill doesn’t change. With Splunk, the meter spins with every additional gigabyte. The more your SIEM sees wide and deep, the more it costs you dear, whereas seeing wide and deep is literally its job.

And there’s the question that started this series, who controls the data. Your logs, they’re the complete fingerprints of your network. With Wazuh, they’re on your machine, in Switzerland, under your control.

With the SaaS American vendor, they’re subject to the CLOUD Act. The price, that’s one thing. Who holds the data, that’s the thing that matters the most.

In summary

You started with an empty safe, and you’re leaving with a security console running.

You installed Wazuh’s three components in one command, manager, indexer, and dashboard on your single node. You set the memory trap that breaks most installs, the indexer’s heap to half of RAM, with identical lower and upper bounds, which justifies the 12 GB recommended in episode 1.

You took back control of security, regenerated passwords, certificates already in place, and especially the dashboard locked down to the Tailnet, invisible from the internet. And you took your first tour of the owner’s deck, SCA, vulnerabilities, file integrity monitoring, local log analysis, compliance dashboards ready to go, all on your own machine, without deploying any remote agents yet.

All for zero euros in licensing, where the same perimeter with an American vendor would run from a few thousand to tens of thousands of dollars per year, depending on the size of your fleet, with your logs stored in a very unfavorable jurisdiction.

But your SIEM only sees itself so far. It’s watching its own machine, and that’s already precious for validating your hardening. The real jump is when it starts seeing the rest of your network. That’s episode 3, deploying agents, the moment when your SIEM starts really seeing your network.

Series reminder

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The VPS hardened outside the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node. You’ve just read it.
Episode 3, agents everywhere. Deploying on your servers, Macs, and Windows.
Episode 4, community network defense. Blocking known attackers before they arrive.
Episode 5, mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac execution control. Deciding which apps have the right to launch.
Episode 7, alerting and total cost. Calibrated notifications and honest financial breakdown against SaaS.

Unknown technical terms? Check the glossary.

Your stance is leaking through the network, not through your iPhone.

Mac Souverain — Wed, 17 Jun 2026 13:41:39 GMT

Citizen Lab linked, in its “Bad Connection” report from April 2026, real surveillance traffic to operators’ infrastructures. Commercial entities can locate any mobile device through network interconnection flaws, SS7 in 2G/3G, Diameter in 4G, without ever touching the device. Nothing to patch on your iPhone: the hole is in the network, not in iOS.

What you need to watch out for

1. No setting blocks this vector: neither Isolation mode, nor eSIM, nor Signal, nor turning off data. The only workaround is to make yourself unreachable by turning on airplane mode or turning off your phone. Don’t think you’re covered just because you’re encrypting your messages.

2. Use 2FA codes for apps, not SMS. It doesn’t stop geolocation, but it closes the interception of codes via the same network.

3. The real defense is structural, on the operators’ and regulators’ side. NIS2 and ENISA frame the risk, but no strong technical obligation yet requires securing interconnection.

The Citizen Lab published a report in April 2026 that for the first time links real surveillance traffic to identified operator infrastructures. The principle has been known for ten years, but the finding remains unsettling: commercial companies can locate any mobile device in the world without ever touching the device itself. Your iPhone is not at fault, and that’s precisely the problem.

The Fact

The report is called “Bad Connection”. It documents actors who track phones across over twenty countries, with one of them conducting over 1700 attacks, almost all of which are dedicated to geolocation. The described target is a “VVIP” in the Middle East, but the typical profile of this market is known: journalists, dissidents, and political figures.

The mechanism exploits the protocols that make operators communicate with each other when you roam or change antennas. They were designed in an era when a handful of national operators trusted each other implicitly. Today, there are thousands of them, and this implicit trust has become a backdoor. Three vectors coexist: SS7 on 2G and 3G, Diameter on 4G, and a variant called SIMjacker that uses a silent SMS executed on your SIM card. The Citizen Lab is categorical: these are not software bugs, but inherent flaws in global telecoms.

A crucial detail: usually, it’s not your operator selling your location. There are two markets. The first one exists: in the US, major operators have sold the location of their subscribers to data brokers, resulting in nearly $200 million in FCC fines in 2024.

The second one, the heart of this radar, is different: surveillance companies like Rayzone, Circles, or Cognyte exploit interconnection flaws by leasing legitimate access points to the global network, often via a small accomplice operator. They remotely query the network of your target, without their consent or their operator’s.

Why This Matters to You

Here’s the angle that’s unsettling. You can encrypt your messages, harden your Mac, close every macOS setting one by one, but your physical location still passes through infrastructure you don’t control, and Apple has no say in it. There’s nothing to patch on this end because it’s not a hole in iOS. It’s the architecture of the network itself.

So, most of the precautions you think of won’t help against this specific vector, and it’s better to know that than to be lulled into a false sense of security. “Hardcore” mode on your iPhone doesn’t touch an SS7 request that happens in the network. An eSIM changes the format of the card, not the protocol: as long as there’s a reachable number, you’re exposed.

Signal protects the content of your messages, not the signaling metadata that reveals where you are. Turning off data or GPS doesn’t matter either, the tracking uses the cell identifier, not your puck. The only individually effective solution is airplane mode or turning off the phone, which is hardly practical daily.

Two caveats to avoid selling you false barriers. Two-factor authentication by app has real utility, but against another risk: SMS interception of your codes, not geolocation. A dedicated number or eSIM reduces the link between your location and your real identity, but doesn’t make that number any less traceable.

The real defense is structural. It plays out with operators and regulators, with signaling firewalls that the GSMA documents in its FS.11 guide. Your security here doesn’t depend on you, but on infrastructure and a legal framework you don’t control.

Let’s be clear about the real risk: for an average person, the likelihood of being targeted remains low. This matters not because of an imminent threat to you, but because of what it reveals. Digital sovereignty doesn’t stop at the edge of your device: as long as you have a SIM card, your location circulates in a weakly constrained global network.

What You Do Now

1. Recalibrate your expectations, that’s the most useful gesture here. Keep Signal, “Hardcore” mode, and your good habits, they protect content and the device, but don’t believe they make you invisible on the network. Confusing the two is the trap.

2. For connection codes, abandon SMS and switch to app-based or hardware key two-factor authentication. It won’t protect you from geolocation, but it closes the interception of codes via the same network, and that’s a real risk to your accounts.

3. If you have a genuinely exposed profile, like a journalist, political dissident, or lawyer on a sensitive case, the only serious individual lever is physical discipline: in airplane mode or with the phone turned off, your device is no longer registered on the network, there’s nothing to locate. You only become traceable again upon re-registration. A dedicated number cloisters your identity, but remains traceable the same way.

4. For the rest, the real work isn’t on your desk. Follow the subject on the regulator side: NIS2 and ENISA set a framework, but no strong technical obligation yet forces operators to close these flaws. That’s where pressure needs to be applied.

Sources

“Bad Connection: Uncovering Global Telecom Exploitation by Covert Surveillance Actors”, Citizen Lab, April 2026 (primary source)
Signalling Security in Telecom SS7/Diameter/5G, ENISA (protocols deemed fundamentally flawed, EU recommendations)
FS.11 SS7 Interconnect Security Monitoring and Firewall Guidelines, GSMA (the signaling firewall reference, industry self-regulation)
Hacking Your Phone, 60 Minutes, CBS, 2016 (interview with Representative Ted Lieu via SS7, demonstration on an elected official)
FCC Fines Major U.S. Wireless Carriers for Selling Customer Location Data, Krebs on Security, 2024 (the distinct market of data brokers, $200M USD in fines)

Technical terms? Check the glossary.

Your AI can be turned off by the US, build your own

Mac Souverain — Wed, 17 Jun 2026 13:40:54 GMT

Update, July 2026. Fable 5 is accessible again, the directive has been lifted. That doesn’t change the thesis, quite the opposite. Cut off yesterday, restored today, by a decision you don’t control: that’s exactly what depending on a foreign dictate looks like. Your local model, on the other hand, doesn’t need anyone’s permission.

You open your Mac one morning. Your usual AI tool refuses to respond. Not a bug, not a server crash. A polite message explains that access is no longer available in your region. You haven’t done anything wrong. You’re paying your subscription. You’re perfectly in order. But you’re on the wrong side of a border, and someone in Washington has decided that’s enough.

This isn’t science fiction anymore. In June 2026, the US government ordered Anthropic, through an export control directive, to suspend access to its two most advanced models, Mythos 5 and Fable 5, for all foreign nationals, worldwide, including its own employees.

Anthropic had to shut them down for all its clients and is contesting the decision. Access to AI intelligence is becoming what oil, chips, and the dollar already are, a lever of power in the hands of a state.

And you’re at the end of the pipe that just got turned off.

The directive as a revealer

The first reaction, when you read this, is to think geopolitics. Big maneuvers, blocs that clash, topics for editorialists. Except the cut-off doesn’t happen to a bloc. It happens to you, on your machine, on a Tuesday morning.

The asymmetry is total. On one side, a supplier under US jurisdiction, subject to its administration’s directives, free to change its access terms overnight. On the other side, you, who’ve built part of your workflow around this tool. You have no say in the decision. You’re not even the target. You’re a collateral damage of a policy that only concerns you by your nationality or geolocation.

That’s what the directive finally makes visible: access to a remote model has never been a technical given, it’s a political authorization. As long as nothing changes, the authorization is tacit, invisible, comfortable. You end up confusing it with a right. The day it’s withdrawn, you discover you didn’t own anything. You were renting.

Ask yourself one question. If access is cut off tomorrow, what keeps running? If the answer is “nothing,” you don’t have a work tool. You have a dependency.

What depending on a remote model really costs

The remote model is great. That’s true, and acknowledging it doesn’t take away from the rest. It’s more powerful than anything you’ll run locally anytime soon. It updates without you lifting a finger. It doesn’t ask for RAM, installation, or maintenance. For many uses, it’s the most effective tool on the market.

But comfort has a price, and that price doesn’t show up on the bill.

Every request you send to a remote model, it’s your text leaving your machine. Your drafts, notes, documents, ongoing thoughts. They pass through infrastructure you don’t control, in a jurisdiction that isn’t yours, subject to rules you don’t vote for. End-to-end encryption protects the pipe, not the destination. At arrival, your text is read in plain sight by the machine that responds.

Then there’s the continuity dependency, the one no one talks about until it bites. Your access depends on a subscription, a pricing policy, a business decision, and now a state directive. Four levers you don’t control, plus a fourth that a foreign government controls, and that’s the most dangerous one. The day one of them flips, your workflow stops. Not gradually. All at once.

That’s exactly the trap we warned about for cloud storage. Your files on someone else’s server are convenient until the account is suspended. Remote AI is the same deal, applied to how you think and produce.

Read: The cloud, it’s someone else’s computer

The sovereignty reflex, the map of local models

Here’s the good news, and it’s more solid than you think. Running an AI model capable of directly on your Mac is no longer a tinkerer’s fantasy. Apple Silicon’s unified memory, the very thing Apple sells for app fluidity, is precisely what makes local inference possible on a consumer machine.

Before the map, a budget rule, because everything starts there.

First, total RAM isn’t available RAM. macOS and your applications consume some of it permanently. And behind the “Mac” label, there are two very different machines.

The entry-level Mac mini comes with 16 GB of unified RAM. Subtract 6 to 8 GB for the system and your apps, and you’re left with 8 to 10 GB actually usable for AI, and that’s with closing what’s running.

A 32 GB machine follows the same principle, but leaves you around 20 GB of headroom. In this usable budget, two things need to fit at the same time: the weight of the model (the model itself) and the context (what you feed it and what it generates).

The practical rule: never aim for a model that fills up the usable budget. On 16 GB, that means a 4 to 8 GB model once quantized. On 32 GB, you can go up to 14, or even 20 GB. If you overflow, the machine falls back on the disk as memory, and then it lags, or it crashes completely.

So here’s the map of what runs, from most accessible to most demanding.

What a 16 GB Mac already runs. That’s the accessible baseline, and it covers most of your daily volume.

For light work, sorting emails, classifying notes, extracting or anonymizing text, tiny 2 to 3 GB models like Llama 3.2 3B, Gemma 3 4B, and Phi-4-mini are more than enough.

For general work, summarizing a document, drafting a memo, managing your correspondence, querying your own note base, a 7 to 8 billion parameter model around 5 GB does the job: Qwen2.5 7B, under Apache 2.0 license, or Llama 3.1 8B. That’s the workhorse of a 16 GB machine.

To read a scanned PDF or an invoice without sending it elsewhere, Qwen2.5-VL 7B (around 5 GB) or Llama 3.2 Vision 11B also work. The ceiling is a 12 to 14 billion parameter model in tight quantization, around 8 to 9 GB, like Qwen2.5 14B: it fits, but with everything else closed and a short context.

On these repetitive and well-defined tasks, local doesn’t just do the job, it does it better: zero network latency, zero requests billed, and your data doesn’t leave your machine.

What 32 GB unlocks. The jump to 32 GB isn’t a luxury, it’s what opens the next category.

For sustained writing and long document analysis, Mistral Small 3, a 24 billion parameter model under Apache 2.0 license, fits around 14 GB in its quantized version. Gemma 3 27B runs around 16 GB.

For multi-step reasoning, 32 billion parameter models fit with some squeezing: QwQ 32B, DeepSeek-R1-distill 32B, or Qwen2.5 32B occupy 19 to 20 GB in Q4 quantization. Context becomes tight, and on the most demanding reasoning tasks, the gap with a remote model remains real. Local does a lot. It doesn’t do everything yet.

On the coding side, Qwen2.5-Coder 32B nearly matches remote models for everyday programming: completing, explaining, debugging, refactoring.

And what doesn’t fit on 16 or 32 GB. Very large models like Llama 3.3 70B, or 405 billion parameter models like DeepSeek-R1 in its full version, require 64 GB of RAM or more. Don’t kid yourself otherwise.

Now, sovereignty isn’t just about raw power. Two other axes matter.

The first is provenance. Mistral is French and European, making it the natural sovereign choice for an European reader. Llama, Gemma, and Phi are American. Qwen and DeepSeek are Chinese.

A caveat here: since the models run locally, no data leaves your machine, regardless of the model’s origin. Provenance doesn’t matter for data exfiltration, it matters for trust, audibility, and not putting all your eggs in one geopolitical basket.

Running a Chinese model locally doesn’t send anything to Beijing. Choosing an European model is about arbitrating the ecosystem you support and what you can inspect, not about a risk of leakage.

The second axis is licensing. Not all “open” models are equal legally. Mistral Small 3 and several Qwen models are under Apache 2.0, a permissive license that lets you do anything, including professional use.

The community license for Llama is usable, but comes with restrictions. For a sovereign baseline, the free license isn’t a legal detail, it’s the guarantee that no one can change the rules under your feet.

My pick for sovereignty by default, in line with all this. On a 16 GB machine, a 7-8B model covers most of your daily volume: Qwen2.5 7B (Apache 2.0) as first choice, or Llama 3.1 8B. On a 32 GB machine, you upgrade to Mistral Small 3 as your daily workhorse (European, Apache 2.0), backed up by a 32B reasoning model like QwQ or DeepSeek-R1-distill, which you bring out for tougher tasks. To run them, three tools are enough: Ollama and LM Studio for simplicity, MLX for those who want to maximize Apple Silicon.

Read: Apple Intelligence, what really leaves your Mac

The realistic threshold, what local does well

It’s not about slamming the door on the cloud for fun. It’s about knowing what should live on your machine, and what can, eventually, leave.

Local does very well with everything that’s repetitive, sensitive, or simply daily. Sorting, summarizing, writing, correcting, classifying, anonymizing, reading your own documents. For this part of your work, which is most of the volume, you don’t need anyone. It runs without a connection, without a fee per request, without a line of your text leaving your machine.

The cloud remains the winner for the top of the pyramid, the most complex reasoning where every point of performance counts. But a supplement is still a supplement. You don’t lean your daily work on a tap someone else can turn off.

The right stance isn’t “all local” or “all cloud”. It’s partitioning. Local becomes your base, what runs by default, what your daily work and anything touching sensitive data relies on.

The cloud becomes a conscious supplement, something you use for a specific purpose, knowing what you’re sending and never sending what shouldn’t leave. The day they cut off your cloud access, you lose a supplement. You don’t lose your base.

That’s where the argument loops back. If you’re reading this on a recent Mac, you’re already on Apple Silicon. The unified memory that runs these models, you’ve already paid for it. This shift to local doesn’t wait for an investment, or a new machine, or an engineer’s skill. It waits for a decision.

Sovereignty in AI isn’t measured by the power of the model you rent. It’s measured by what keeps running the morning they cut off your access. The remote model is comfort, and power when a task demands it.

Your AI base is what lives on your machine. Install one. Run it once, on a real task, to see. You’ll know, concretely, what you have left when they turn off the tap.

The most down-to-earth question left: how do you install all this, concretely? That’s the subject of the next article, step by step, from download to first prompt, without indigestible command lines.

Read soon: Installing and running your first local model on Mac, the step-by-step guide

Sources

The trigger, US directive and Anthropic

Anthropic, Statement on the US government directive to suspend access to Fable 5 and Mythos 5, Anthropic’s official statement, applying the export order while contesting it (12 June 2026).
TechCrunch, Anthropic’s safety warnings may have just backfired, the global shutdown of Fable 5 and Mythos 5 (12 June 2026).
The Register, US clampdown on Anthropic models sends EU sovereignty surge into overdrive, how the cut-off accelerates Europe’s sovereignty shift, the very angle of this article (15 June 2026).

Open-weight models cited

Mistral AI, Mistral Small 3, the 24B Apache 2.0 European pick (30 January 2025).
Qwen, Qwen2.5, the Qwen2.5 family, 7B variants under Apache 2.0.
Meta, Llama 3.1 Community License, permissive license with restrictions.

Local execution on Apple Silicon

Ollama, running models locally, data that doesn’t leave your machine.
LM Studio, desktop app for running LLM privately, supports MLX on Mac.
Apple, MLX, the framework optimized for Apple Silicon’s unified memory.

Technical terms? Check the glossary.

Your sovereign SIEM's foundation, a hardened VPS outside the CLOUD Act

Mac Souverain — Fri, 12 Jun 2026 06:11:45 GMT

Before detecting anything, you need a place to install your SIEM. A machine. Not just any machine, not configured any way.

In the opening episode, we established why. GDPR already requires you to detect and notify a breach within 72 hours, NIS2 has widened the net, and it won’t stop there. American SaaS does the job but hands over your most sensitive logs on demand to the US government. It’s all very unfavorable to your interests, you’ll agree.

So, how to resolve this dilemma? The simple answer is, you build your own SIEM, GDPR and NIS2 compliant, on infrastructure you control entirely.

This article is the first brick. The foundation.

The rest of the series will stack on top of it. Wazuh in episode 2, agents in episode 3, network defense, email filter, execution control. If the foundation is shaky, the whole stack is shaky. A SIEM that monitors your park but runs on a machine itself compromised, it’s like a surveillance camera plugged into an open door.

The stack I recommend, I use daily. I’ll show you how to build your foundation, in order, with real commands. You can reproduce it today.

Choose the hoster, jurisdiction first

The first decision, and the most structuring one. Where your machine will live.

The temptation is to go for the cheapest or most well-known. AWS, Google Cloud, Azure. They’re excellent technically. But they’re all American nationality, and thus subject to the CLOUD Act, that wonderful 2018 law that allows US authorities to seize data from an American provider, wherever it’s stored in the world, including European datacenters.

Storing your security logs there is exactly the problem we’re trying to solve. So, what we’re looking for is a hoster whose headquarters, servers, and capital are not subject to this US exception.

Three criteria to really consider.

The jurisdiction of the headquarters. An European company without an American parent company is not subject to the CLOUD Act. Switzerland, Germany, France, etc. The nuance is, a hoster with an entity in the US exposes resources hosted in that entity to the CLOUD Act. The headquarters alone isn’t enough, you need to look where your data physically lives.
The location of the datacenters. Your logs need to stay on European servers, period. No transatlantic replication “for your availability”.
Price, last. A VPS to start a SIEM for an SME costs between 5 and 25 euros per month. At this level, the price difference between sovereign operators is marginal. You don’t choose your security hoster based on cents.

In practice, two names come up when crossing these criteria.

Infomaniak, Swiss hoster based in Geneva, owned 100% by its founders and employees, without external investment funds. Servers exclusively in Switzerland, under nLPD, the Swiss federal law on data protection entered into force in September 2023, aligned with GDPR and recognized by the European Commission’s adequacy decision.

No US subsidiary, not subject to the CLOUD Act by design, not part of the 5-eyes, therefore no extended cooperation with US intelligence. In Switzerland, all communication requests must go through justice, one of the most protective jurisdictions in the world.

Their datacenters are certified ISO 27001 and ISO 50001. It’s the operator I use, on their VPS Cloud range, but the entry-level VPS Lite can suffice to start.

Hetzner, German family-owned hoster founded in 1997, unbeatable performance/price ratio in Europe, with an ARM cloud range at 4.49 euros HT per month, around 5.40 euros TTC, at the time of writing. Excellent choice, with one condition. Hetzner opened datacenters in the US in 2021, then in Singapore in 2023. You need to provision your machine exclusively on their European sites, Falkenstein, Nuremberg, or Helsinki, to stay outside the CLOUD Act.

Two honest caveats in addition. Hetzner’s interface and support are only in English and German, and Hetzner sometimes suspends accounts deemed risky, without warning. Nothing blocking for a legitimate SIEM use, but good to know.

For this guide, I’m going with Infomaniak. The logic is the same at Hetzner, just the interface names change.

Read soon: Choosing your sovereign hoster, the complete comparison

Size the machine, not too much, not too little

Wazuh, which we’ll install in episode 2, isn’t lightweight. It comes with a manager, an indexer, and a dashboard. The indexer, in particular, loves RAM.

For an SME with up to fifty machines to monitor, the right starting point is three numbers.

4 vCPU, to absorb indexing and rule correlations without saturation.
8 Go of RAM, the bare minimum for the Wazuh indexer. Below that, it struggles or stops. I recommend 12 Go.
100 to 250 Go of SSD, depending on the log retention you want. The more months of history you keep, the more space you’ll need. NIS2 and GDPR think in months, plan ahead.

A VPS of this caliber runs around 15 to 30 euros per month with a sovereign operator. You can start smaller to test, but don’t go below 8 Go of RAM if you plan to run Wazuh on it for real.

For the system, choose a Linux distribution with long-term support. Ubuntu Server LTS or Debian stable. Both are well-documented, supported for years, and are what the Wazuh community tests first. I use Ubuntu Server LTS, that’s what I’ll use in the following commands.

The first contact, and the first hardening

You’ve just ordered your machine. The hoster sends you an IP address, a root ID, and a password. This is the most exposed moment in the entire life of the server, a root accessible via password on a public IP is exactly what bots scan all the time.

A precision before diving in. A server is administered via the command line, no graphical interface or mouse, the Terminal is your only cockpit. Each command in this guide is short and explained line by line.

The first connection session serves to close this door. In order.

Create a non-root user

Working as root daily is like driving without a seatbelt. The slightest command error executes with full privileges. We create a dedicated user, who can elevate their privileges when necessary via sudo.

adduser mack
usermod -aG sudo mack

The first adduser creates the account and asks for a password. The second adds the user to the sudo group, allowing them to execute admin commands by prefixing them with sudo. From now on, log in with this account, never as root directly.

Switch to key-based authentication

A password can be guessed, forced with a dictionary, stolen. A cryptographic key, no. We generate a key pair on your local machine, install the public part on the server, and disable password-based authentication completely.

On your Mac, in the Terminal:

ssh-keygen -t ed25519 -C "your-comment"
ssh-copy-id mack@IP_OF_THE_SERVER

The first command generates the key pair, in Ed25519, the modern, short, and solid algorithm. The second copies your public key to the server. Then test that you can log in without a password, ssh mack@IP_OF_THE_SERVER. If it works, we can cut off the rest.

Lock down SSH

This is where the attack surface really closes. We edit the SSH daemon’s configuration.

sudo nano /etc/ssh/sshd_config

Three lines to set, these are the three that matter.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

PermitRootLogin no forbids direct root logins. PasswordAuthentication no disables passwords, only your key opens the door now. PubkeyAuthentication yes confirms that we accept keys.

Keep your current session open, restart the service, then test a new connection in a second window. An SSH config error, and you’re locked out of your own machine.

sudo systemctl restart ssh

A known trap with cloud images, Ubuntu often leaves a file /etc/ssh/sshd_config.d/50-cloud-init.conf containing PasswordAuthentication yes, which overrides your configuration. Check the actual applied value with sudo sshd -T | grep -i passwordauthentication, and if it comes back as yes, fix this file too.

Three commands, three config lines. You’ve just eliminated almost all automated attacks that target SSH. The bots that try root via password are now hitting a wall.

Enable automatic security updates

A server that hasn’t been patched is a vulnerable server, and no one connects every morning to launch updates manually. We automate security patches.

sudo apt update && sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

The unattended-upgrades package automatically installs security updates published for your distribution, without touching the rest. Your known vulnerabilities close automatically, while you sleep.

The minimal attack surface, the real sovereign goal

The SSH hardening, that’s the basics. The level jump is here.

The guiding principle is one sentence. A port that doesn’t listen can’t be attacked. Each service exposed on a public IP is a door, and each door is a target. Maximum security isn’t the best lock on each door, it’s not having a door at all.

That’s exactly the logic we saw for the Secure Enclave. The most secure component is the one that refuses access, not the one that defends it well.

The firewall, closed by default

On Ubuntu, the firewall is managed with ufw. The right posture is the inverse, we block everything, then open only what’s necessary.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable

default deny incoming refuses all incoming connections. default allow outgoing lets your machine join the outside world, for updates, for example. We only open port 22, SSH, the bare minimum to administer the machine. And we enable.

At this point, your server presents only one SSH door per key. That’s already a profile radically more discreet than 90% of production VPS.

Tailscale, and the public IP disappears

We can do better. Instead of opening SSH on the public IP, even via key, we remove it entirely from internet view and expose it only on a private, encrypted network.

That’s the role of Tailscale. Tailscale creates a private mesh between your devices, over WireGuard, the modern tunneling protocol. Your machines see each other via private addresses, like they’re on the same local network, even if they’re scattered between a Swiss datacenter, your office, and your home. The rest of the internet, meanwhile, sees nothing.

Here’s the concrete flow. You install Tailscale on the server and on your Mac. Both join your private network. Your Mac gets a Tailscale address, the server does too. You log in to the server via its Tailscale address, not its public IP. And you close port 22 on the public IP. To reach SSH, you have to already be a member of your private network. An attacker on the internet can’t even see that the port exists.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

The command displays a link, you open it in your browser, authenticate the machine, it joins your network. Repeat on your Mac. Retrieve the server’s Tailscale address:

tailscale ip -4

Test the SSH connection via this private address. Once it works, we close port 22 on the public IP:

sudo ufw delete allow 22/tcp
sudo ufw allow in on tailscale0 to any port 22 proto tcp

The first line removes the SSH opening on all interfaces. The second reopens it only on the tailscale0 interface, your private network. SSH only listens on the encrypted mesh.

The result is a machine with only one admin door, invisible from the internet. Not locked, invisible. A port scan on your public IP reveals nothing exploitable.

For the rest of the series, that’s also how your Wazuh agents will send their logs to the server, never through the open internet. The network foundation we’re putting in place today serves the whole stack.

And the services that must remain public?

Not everything can live behind the private network. If your server hosts a website or a service that needs to be reachable by anyone, that service has to listen on the public IP. It’s inevitable.

The rule, then, isn’t “zero public ports” but “zero unnecessary public ports”. You open exactly what the service requires, nothing more. A website, that’s port 443 in HTTPS, and port 80 while renewing certificates. Nothing else. Everything else, administration, databases, internal dashboards, stays on Tailscale.

For our SIEM foundation, at this point, the simple answer is no public services. The server exposes nothing to the world. Wazuh, which we’ll install later, lives entirely behind Tailscale, accessible only to you.

The backups, encrypted off-site

A hardened server isn’t an immortal server. A datacenter can burn down, as we saw with OVH Strasbourg in March 2021, clients without backups lost everything. A ransomware can still pass on one of your production machines. A finger slip on a wrong command can erase a database.

The rule is non-negotiable. Your backups live elsewhere than on the machine they protect, and they’re encrypted before they leave. Encrypted by you, on your machine, before sending. Not encrypted by the storage provider, by you. That way, even the storage provider can’t read what it’s storing.

The tool I use is Kopia. Open source, fast, and it does exactly what we want, client-side encryption before transfer, deduplication to not explode your storage volume, and sending to an S3-compatible storage.

And the off-site storage, I take it with Swiss Backup, Infomaniak’s backup service. Same logic of sovereignty as for the VPS, Swiss servers, not subject to the CLOUD Act, and an S3 endpoint that Kopia consumes directly.

The concrete flow. Kopia runs on your server. Once a day, or several times, it takes a snapshot of the folders that matter, your system configuration, your Wazuh data, your logs.

It encrypts this snapshot locally, with a key that only you hold. Then it sends it to Swiss Backup. The day the server dies, you provision a new machine, reinstall Kopia, point it to the remote repository with your key, and restore.

curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /usr/share/keyrings/kopia-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" | sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update && sudo apt install kopia
kopia repository create s3 \
  --bucket=YOUR_BUCKET \
  --endpoint=s3.swiss-backup.infomaniak.com \
  --access-key=YOUR_KEY \
  --secret-access-key=YOUR_SECRET

The first three lines install Kopia from its official repository. The last command creates the encrypted repository on the remote storage, using the exact endpoint displayed in your Swiss Backup console, it varies depending on the cluster you’re assigned. Kopia asks for a passphrase when creating the repository, that’s the key to encrypt all your backups. Note it down somewhere other than on the server. If you lose it, your backups are permanently unreadable, including to you. That’s the price of client-side encryption, and that’s exactly what we want.

Then automate. We create a daily snapshot of the critical folders, then schedule it with a cron job.

kopia snapshot create /etc /home /var/log

This command captures the current state of the three folders. You schedule it to run every night, and occasionally check that your snapshots are there with kopia snapshot list. A backup you don’t test is not a backup, it’s a hope. So we’ll need to plan a test restore of your data every quarter.

This SIEM foundation will serve the rest of the series. Every brick we add, Wazuh and its data, the rules you calibrate, will be captured in the same encrypted snapshot, off-site, ready for the day you need it.

In summary

The foundation is four gestures that build on each other.

You’ve chosen a hoster whose jurisdiction protects you, not just whose datacenter is in Europe. You’ve hardened access, non-root user, key-based authentication, root forbidden, automatic updates. You’ve reduced the attack surface to nothing, closed firewall by default, admin behind a private encrypted network, no unnecessary public ports. And you’ve put encrypted backups off-site, unreadable to anyone without your key, ready for the day when.

None of these steps are complicated. Together, they turn a rented machine into a fortress you control. It’s the exact opposite of what you sign up for with an American SaaS, where the data is yours but the infrastructure and jurisdiction aren’t.

An afternoon’s work. Not a weekend.

The foundation is in place. In episode 2, we fill the vault. Wazuh all-in-one, manager, indexer, and dashboard on this single node. The functional equivalent of a Splunk, for the price of the VPS you’ve just built. Your SIEM starts to exist.

Series reminder

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS outside the CLOUD Act. You’ve just read it.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node.
Episode 3, agents everywhere. Deployment on your servers, Macs, and Windows machines.
Episode 4, community network defense. Block known attackers before they arrive.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac execution control. Decide which applications have the right to launch.
Episode 7, alerting and total cost. Calibrated notifications and honest financial breakdown against SaaS.

Technical terms? Check the glossary.

Siri AI blocked in EU, privacy signed Google

Mac Souverain — Wed, 10 Jun 2026 13:32:51 GMT

Apple Launches Siri AI at WWDC, But Blocks It on iPhone and iPad in EU Due to DMA. Commission Says It’s Apple’s Choice, Not a Requirement. To Top It Off, This “Confidential” Platform Partially Relies on Google Gemini.

What This Means for You

1. No Siri AI on iPhone or iPad in Europe. But without cloud AI assistant, your device is safer: you lose a feature, not a protection.

2. For the Sensitive, Stay Local and enable Advanced Data Protection on iCloud. For encrypted email, use Proton Mail, not iCloud Mail.

3. Ask Yourself the Real Question: Is trusting your most intimate assistant to an Apple-Google chain a technical guarantee or a contractual promise?

Apple Unveils Siri AI at WWDC

Apple has unveiled Siri AI, its new voice assistant platform. Two details stand out: it’s partly built on Google Gemini, and it won’t be available on iPhone or iPad in the European Union. Privacy, Cupertino-style, becomes a blocking argument.

The Fact

On June 8, 2026, at the WWDC, Apple introduced Siri AI, the much-anticipated revamp of its voice assistant and the announced foundation of its next generation of products, including future portable devices. The platform’s core is a hybrid architecture: local tasks run on Apple’s in-house models, but cloud intelligence relies on a custom Gemini model from Google, estimated to be around a billion dollars a year, according to several press sources.

The catch is geography. Apple announced that Siri AI won’t be available on iPhone or iPad in the EU with iOS 27 and iPadOS 27. EU users will have access on macOS 27 and visionOS 27, but not on iPhone, iPad, or Apple Watch, as watchOS 27 depends on a paired iPhone with Siri AI. Apple cites the Digital Markets Act (DMA) and its interoperability requirements, claiming regulators rejected its compliance proposals, including a Trusted System Agent framework meant to open access to competing assistants while maintaining security standards.

The Commission disputes the framing. For spokesperson Thomas Regnier, Apple’s decision not to deploy Siri AI in the EU is “Apple’s alone,” with nothing in the DMA preventing a new product launch. The market, however, has spoken: Apple’s stock dropped about 2% on the day of the announcement and another 3% the next day. Note of caution: iOS 27 and iPadOS 27 are currently announcements, not stable builds. The release timeline and block perimeter could still shift.

Why It Matters to You

If you’re in Europe, the message is clear: your iPhone and iPad won’t have the flagship feature of the next OS. Before blaming Brussels, look at what’s really happening. Apple presents privacy as the reason it can’t comply with interoperability demands.

The Commission responds that no one’s forcing Apple to cripple its product. The two versions aren’t symmetrical, and the official site isn’t the only source of truth here, but one thing’s certain: privacy has become a negotiation point as much as a technical promise.

The irony’s worth noting. Apple pitches Siri AI as privacy-respecting while outsourcing cloud processing to Google, whose business model relies on data exploitation. Apple swears its architecture segregates everything via Private Cloud Compute, that Google sees nothing, and requests are anonymized. It’s plausible on paper, and Apple has a solid track record. But you’re moving from a verifiable promise, all-on-device, to a contractual one, trusting partners to keep their word. It’s not the same level of assurance.

The underlying issue goes beyond Siri. We’re seeing digital ecosystem fragmentation by jurisdiction. The same iOS version won’t offer the same features in Paris, New York, or Beijing. User sovereignty now hinges not just on encryption, but on the iPhone-dependent arms race between an American industrial giant, a European regulator, and a third-party AI provider.

What It Changes for You

1. Don’t confuse Siri AI’s absence with loss of privacy. Your iPhone without a cloud AI assistant remains fully functional and more secure. The “lack” is a feature, not a lost protection.

2. For sensitive queries, stick local. Enable Advanced Data Protection on iCloud (Settings > Apple Account > iCloud > Advanced Data Protection) for end-to-end encrypted backups. Note: ADP doesn’t cover iCloud Mail, Contacts, or Calendar. For genuinely encrypted email, try Proton Mail or Tuta, for instance.

3. Keep an eye on developments without getting overwhelmed. The EU block perimeter and timeline may shift. What matters isn’t the release date, but the broader question: are you ready to entrust your most intimate assistant to an Apple-Google chain, based on a contractual promise?

OpenAI Certificate Compromised, Update ChatGPT Mac Before June 12th

Mac Souverain — Sat, 06 Jun 2026 07:58:44 GMT

**If you’re using ChatGPT, Codex, or Atlas natively on your Mac, you’ve got until June 12, 2026 to update. OpenAI’s signature certificate has been compromised via a supply-chain attack on npm. After that, your app won’t start.

Here’s what you need to do:

1. Open ChatGPT.app, go to Settings → About. Update if your version is ≤ 1.2026.125. Same for Codex App (≤ 26.506.31421), Codex CLI (≤ 0.130.0), Atlas (≤ 1.2026.119.1).

2. Official download only, chatgpt.com/download or App Store. No mirrors, no shared links.

3. iOS, Windows, Android, nothing to do, OpenAI re-signs on the server side. Mac only.

You’re using ChatGPT, Codex, or Atlas in a native app on your Mac. On June 12, in a few days, these apps will refuse to launch if you haven’t updated. Not a bug, a certificate revocation due to a supply-chain attack. Here’s what happened and what you need to do.

The Facts

On May 11, 2026, a collective called TeamPCP published 84 tampered versions of 42 @tanstack/* packages on npm in just six minutes. Two OpenAI employees consumed one of these packages that evening. The malware, Mini Shai-Hulud, exfiltrated credentials that granted access to internal repositories containing OpenAI’s code-signing tools. Not user conversations or models, just the keys that prove to macOS that an app comes from OpenAI.

OpenAI announced publicly on May 13, 2026, that the compromised certificate would be revoked on June 12, 2026. On Apple’s end, this means Gatekeeper and notarization will refuse any version signed with the old certificate. In practical terms, the affected versions are:

ChatGPT Desktop ≤ 1.2026.125
Codex App ≤ 26.506.31421
Codex CLI ≤ 0.130.0
Atlas (OpenAI browser) ≤ 1.2026.119.1

These won’t launch after June 12. iOS and Windows versions are re-signed server-side, no user action needed.

The worm’s source code was published by TeamPCP on May 12, with a $1,000 bounty on BreachForums for the largest supply-chain attack using their tool. Not a defensive bug bounty, an offensive reward. The CVE reference is CVE-2026-45321.

Why This Matters to You

You didn’t do anything wrong, but you still have to act. That’s the essence of a supply-chain attack. Your user hygiene could be perfect, but if the app you’ve installed gets compromised four levels up, in an npm dependency you’ll never know about, you’re the one left with the problem. The compromised certificate, the revoked signing mechanism, the app that won’t launch - it all happens on your end without you clicking anything.

The good news is the revocation mechanism works. Gatekeeper and Apple’s notarization are designed for this: preventing an attacker from using a stolen certificate to sign malware downstream. OpenAI did their job by properly revoking. Apple did their job by blocking. The system held up. OpenAI communicated clearly and promptly, with specific dates and versions - not the norm in the industry.

The bad news is it raises a doctrinal question that goes beyond OpenAI. A native app on your Mac is local code running with a trust certificate, automatic update channel, system permissions, and a network of upstream dependencies you have no visibility into. When one of these dependencies gets compromised - and they all do - the problem comes down to you.

What You Need to Do Now

1. Open ChatGPT.app, go to Preferences → About. If you’re on 1.2026.125 or earlier, start the update. If nothing appears, download directly from [chatgpt.com/download](https://chatgpt.com/download]. Never a mirror, never a shared link.

2. If you’re using Codex App or Codex CLI, do the same check. CLI: codex --version then npm update -g @openai/codex or reinstall cleanly. For Atlas, update is integrated.

3. Make sure macOS is up-to-date, with Gatekeeper strengthened on Sequoia 15.x and Sonoma 14.7+. Older versions are more lenient in notarization checks at launch.

4. Use the window to ask yourself a doctrinal question: what does the native ChatGPT app give you that chatgpt.com in Safari doesn’t? System dictation, keyboard shortcuts, Spotlight integration - okay. If you don’t use any of these, the browser reduces your attack surface. No signature certificate to manage, no silent updates, no persistent local code. The habit applies to Claude Desktop, Perplexity, Mistral AI Chat, and any other third-party AI apps you’ve installed without really knowing why. A native app on your Mac is a security debt - sometimes justified, sometimes not.

Also read, Anthropic MCP, design flaw that opens RCE. Same logic, third-party AI code descending into dangerous local execution.

Sources

Build your sovereign SIEM for SMEs, compliant with GDPR/NIS2 without CLOUD Act

Mac Souverain — Fri, 05 Jun 2026 12:00:56 GMT

You don’t have a SIEM. You tell yourself it’s not for you, that your SME is too small or outside a regulated sector, so under the radar of the big cyber obligations. You’re wrong on two counts.

Now, GDPR. Since 2018, any company that processes personal data must notify the CNIL of a breach within 72 hours. That’s Article 33. Not a recommendation, an obligation. Notifying within 72 hours means you know something happened, that you can characterise it, that you have the logs to trace the chain back. Without a system that centralises your logs and raises alerts, this obligation is unenforceable. You’re in breach the first time a ransomware gets through.

Tomorrow, the widening. NIS2 has just multiplied by thirty the number of French entities subject to reinforced cyber obligations, from 500 to around 15,000. DORA has applied since January 2025 to the extended financial sector, subcontractors included. The Cyber Resilience Act applies fully from December 2027 to any product with a digital component sold in the EU. NIS3 isn’t voted on yet, the indicative timeline aims for the end of 2027. But the trajectory is legible, every two to three years the net widens. Betting your SME stays out of scope in 2028 or 2029 is betting against Brussels and against the GDPR case law that has done nothing but harden.

The word that keeps coming back in all these texts is SIEM, for Security Information and Event Management, centralised management of security events. They never name it, but they make it impossible to avoid. Detecting an incident, keeping exploitable logs, notifying the regulator within short deadlines, those are the functions of a SIEM.

And what is a SIEM, concretely? Picture the CCTV of your shop, but for your IT. Every server, every firewall, every workstation, every mailbox constantly produces a log of what happens on it. Who logged in, at what time, from where, which file was opened, which process started.

A SIEM is the system that brings all these logs to one place, keeps them for several months, and raises an alert when it detects suspicious behaviour.

An account that logs in at 3 in the morning from Pakistan, ten thousand files encrypted in two minutes, a burst of failed passwords on the director’s account, these are signals a human will never catch with the naked eye on a fleet of fifty machines.

The SIEM sees them, cross-references them, and warns you. Behind this consultant’s acronym hides a very concrete assembly, which we take apart further down in this article.

The problem is what’s being sold to you today under that name. Splunk, Microsoft Sentinel, CrowdStrike. At a modest SME’s entry ticket the prices look affordable, but the bill climbs with every gigabyte and every seat, and we do the full accounting at the end of the series. And the price isn’t even the worst of it. These products store your incident logs in a jurisdiction that isn’t yours, under the CLOUD Act. The real question is who holds your most sensitive data.

There’s a third path. The sovereign one. It’s the path of this series.

NIS2 in five minutes, and why it concerns you even outside the scope

NIS2 is the European directive on the security of networks and information systems, replacing NIS1. NIS1 covered around 500 French entities. NIS2 covers around 15,000, spread across eighteen sectors. Health, energy, transport, digital, financial services, agri-food, waste, manufacturing. If your company exceeds 50 employees or 10 million euros in revenue in one of these sectors, you’re directly concerned. Probably as an “important entity”, sometimes as an “essential entity” depending on your size and criticality.

If you’re smaller or outside a listed sector, you’re not off the hook for all that. Two mechanisms catch you. First the supply chain, Article 21 requires NIS2 entities to assess the cyber-resilience of their subcontractors. If you sell service or software to a 60-person SME in health or finance, it’s going to ask you for your proof. No SIEM, no contract. Then the regulatory trajectory itself, NIS3 is in preparation at the Commission, the scope always widens from one revision to the next.

The heart of the mechanism is Article 21. Ten categories of minimum measures, risk analysis, incident management, logging, continuity, training, encryption, access control, supply chain security. And the notification obligation, in three steps, early warning within 24 hours, structured notification within 72 hours, final report within 30 days.

The triptych holds for NIS2 as for GDPR, without a detection and logging foundation, the obligation is unenforceable.

Article 20 adds the detail that changes everything for the director. Liability falls on the natural person who runs the company. Not on the IT manager, nor on the provider. On you.

On the sanctions side, it’s calibrated to hurt. Essential entity, up to 10 million euros or 2% of worldwide revenue, whichever is higher. Important entity, up to 7 million euros or 1.4% of worldwide revenue. For an SME with 30 million in revenue, we’re talking a maximum sanction of several hundred thousand euros.

The law of 30 April 2025 transposes NIS2 into French law. The implementing decrees and the exact scope of the entities concerned are being specified over the course of 2026. As long as it’s fuzzy you tell yourself you have time, but the directive already applies, the case law will be built on the first disputes. The question is when, not if.

We already saw in a previous article how NIS2 contradicts CSAR on encryption. Here, we look at the other obligation, the one that becomes concrete for your infrastructure, detect, log, notify.

You have three options, and two of them are bad

Option 1, US SaaS

Splunk, Microsoft Sentinel, CrowdStrike, Datadog, Elastic Cloud. They work. They’re mature. And at a modest SME’s entry price, they’re not out of reach. The trap is elsewhere.

Microsoft Sentinel charges around $4.30 per gigabyte ingested in the East US region, in the simplified billing model that combines Log Analytics ingestion and Sentinel analytics. CrowdStrike Falcon charges per endpoint, between $60 and $185 per seat per year depending on the tier, Go, Pro, Enterprise or Complete. Splunk is more opaque, the vendor doesn’t publish its prices, but serious secondary sources converge around $8,000 to $12,500 per year for an entry ticket of 5 gigabytes of logs per day, licence only, in Cloud or self-hosted Enterprise.

Take a 50-employee SME that generates five gigabytes of logs per day. On Microsoft Sentinel, around $7,800 per year. On CrowdStrike Falcon Pro for 50 endpoints, around $5,000 per year. On Splunk Cloud at entry, around $8,000 per year. Let’s be honest, $13,000 per year for Sentinel and CrowdStrike combined, on an SME with $10 million in revenue, is 0.13% of turnover. The entry cost isn’t the obstacle.

The obstacle is what you sign up for at the same time. Your logs go to the United States, or to a European subsidiary of an American company. The CLOUD Act, passed in 2018, lets US authorities requisition this data from the provider, even when it’s physically stored in Europe. Microsoft Ireland, Splunk Cloud, CrowdStrike, all are subject to it through their parent company.

And your incident logs aren’t just any data. They’re the complete fingerprints of your network, the usernames, the application flows, the internal behaviours, the vulnerabilities exposed at the moment of the attack. The most sensitive material your information system produces. Handing it to a provider requisitionable by a foreign jurisdiction is a real operational risk.

The Data Privacy Framework, the EU-US legal bridge, survived first instance before the EU General Court in September 2025. It’s on appeal before the CJEU since 31 October 2025. The CNIL, in its February 2025 decision on health hosting, is clear, the only recognised marker for materialising a sovereign cloud remains the SecNumCloud qualification. None of the three SaaS providers cited has it.

One last point. The reasonable entry cost is today. The billing mechanism gets worse as you grow. Every additional gigabyte ingested is charged, every additional endpoint too. At 50 gigabytes of logs per day, the Sentinel ticket climbs above $78,000 per year, Splunk rises in proportion depending on the licence mode. You sign a modest entry price, you also sign a tariff lock-in that closes in as your SIEM sees wider and deeper.

Conclusion, you pay a reasonable price for the plumbing today, by handing the most strategic data in your information system to a jurisdiction that isn’t yours, in an unfavourable legal framework, with a meter running against you at every extension of scope.

Option 2, do nothing

It’s tempting. It’s the most common strategy among SMEs, whether or not they’re in the NIS2 scope. Wait. See. Hope.

The calculation is wrong on three fronts. GDPR today, the CNIL has already sanctioned SMEs for failure to notify, the absence of any detection means is an aggravating factor. NIS2 tomorrow if you enter through the supply chain or through a revision, the maximum sanction for an essential entity exceeds GDPR’s, the director’s personal liability exists in black and white. Ransomware any time, encryption of production, ransom, loss of operations, that’s another order of magnitude than getting into compliance.

Doing nothing isn’t saving. It’s postponing, at the risk of worsening the final bill.

Option 3, sovereign self-hosted

You build your SIEM with mature open-source bricks, deployed on an infrastructure you control. Four bricks, four complementary roles.

Wazuh, it’s the brain of the setup, the central platform that brings all the logs to one place, stores them, analyses them and raises the alerts. It’s your “home-made Splunk”.
CrowdSec, it’s the bouncer at the door. A community network defence that automatically blocks the IP addresses already flagged as attackers by the other users of the network. When a bot scans a thousand sites before yours, it’s blacklisted before it reaches you.
Rspamd, it’s the filter in front of your mail server. It intercepts spam and phishing attempts before they reach your employees’ inboxes. Mail remains the number one intrusion vector for SMEs, that’s where prevention pays off most.
Santa, it’s the execution controller on your Macs. It decides which applications are allowed to start on each machine, according to an allowlist you build. A ransomware downloaded by mistake can’t run, because it isn’t signed by a vendor you’ve approved. It’s the brick that turns an everyday Mac into a hardened workstation, without the user having to change their habits.

None of these bricks is experimental. Wazuh is used by Fortune 100 companies. CrowdSec, a French company founded in 2019, aggregates 10 million signals a day, shared by more than 70,000 users across 190 countries. Rspamd powers Mailcow, Zimbra, Mailu, which set the reference. Santa, originally developed at Google and now maintained by North Pole Security, runs in production at Figma.

The cost, it’s a correctly sized VPS, the installation time, and an internal competence you build. Not zero, but nowhere near the figures above.

What a SIEM really is, for someone who doesn’t do blue team

The word is scary. It smells of black screens, 24/7 teams and analysts speaking a dialect your IT manager doesn’t understand. Once demystified, it’s simpler.

A SIEM is plumbing. Not a product, an assembly. Four functions that chain together:

Collect the logs from your equipment, servers, firewalls, workstations, applications, mailboxes. Everything that produces a log, you bring to one place.
Centralise and keep these logs in an exploitable format, with a retention that lets you investigate an incident going back several months.
Detect abnormal behaviours. An account logging in at 3 in the morning from an unusual country, a burst of failed authentications, a process that modifies 10,000 files in one minute.
Alert and keep the trace, for your ANSSI notification within 24 hours, and for your final report within 30 days.

That’s it. No magic. A system that sees, that remembers, and that shouts when something’s wrong.

The hard work isn’t the technology, it’s the adjustment. Which rules you enable, which thresholds you calibrate, who you send the alert to, how you respond. It’s the same thing on Splunk or on Wazuh. And it’s that internal competence you’re going to build across this series.

In short

Building your SIEM in 2026 pays you on two horizons.

Short term, it’s operational security. A ransomware detected in hours instead of weeks, an exfiltration intercepted before the ransom, a GDPR breach you can characterise and notify within the deadlines. That ROI depends on no text that isn’t yet voted, it’s immediate.

Medium term, it’s amortised compliance. You build the infrastructure and the internal competence before the obligation lands on your head. Your competitors will build it under pressure, in a hurry, at three times the price of a flash-mission consultant. You’ll have taken a five-year lead on them for the price of a few weekends spread over a quarter.

US SaaS does the job and isn’t out of price on the entry ticket. It just delivers your most strategic data into an unfavourable jurisdiction, and locks you into a model where every extra gigabyte is charged. Self-hosting demands an initial time investment. In the end, you’re master of the data, of the marginal cost and of the compliance schedule. Real sovereignty against a little of your time, which we’ll make a point of optimising across our articles.

Seven episodes to build your plumbing

It’s the stack I use in production. Not a blogger’s fantasy, an infrastructure that runs day to day, that detects, that logs, that notifies. Seven episodes, seven bricks:

Episode 1, the foundation. A hardened VPS, on a European host outside American reach. Choice of operator, base configuration, minimal attack surface, encrypted off-site backups.
Episode 2, Wazuh all-in-one. Installing the manager, the indexer, the dashboard on a single node. Hardening, first dashboards. The functional equivalent of a Splunk for the price of a VPS.
Episode 3, agents everywhere. Deploying Wazuh agents on your servers, Macs and Windows. Collecting system logs, security events, file activity. The moment your SIEM starts to see.
Episode 4, CrowdSec on the front line. The community network defence that blocks known attackers before they reach your services. Wazuh integration, signal sharing.
Episode 5, Rspamd for the mail. The anti-spam and anti-phishing filter that plugs in front of your mail server, or integrates with your existing solution. Phishing detection, logging into Wazuh.
Episode 6, Santa on the Macs. Execution control on Apple machines. North Pole Security fork, the project actively maintained since Google handed it over in 2024. Progressive lockdown, Wazuh integration.
Episode 7, alerting and total cost. Calibrated notifications, escalation, honest financial breakdown, episode-by-episode comparison with what the equivalent SaaS would have cost.

The links light up as the episodes publish, come back and plug into the new ones as they come out.

Each episode is standalone. You can stop at 3 and already have covered the essentials of NIS2. You can push to 7 and have a stack with nothing to envy in those of large companies.

Apple Intelligence: What's Really Leaving Your Mac

Mac Souverain — Thu, 28 May 2026 07:48:57 GMT

Update of June 21, 2026. Since June 8, 2026, PCC no longer runs solely on Apple silicon: for the heaviest queries (agentic, complex reasoning), Apple switches to Google Cloud hardware, NVIDIA GPU, Intel CPU, and Titan chip. Apple swears that the five guarantees hold, that it keeps software control, and that Google sees nothing in the clear. Perhaps. But the “all stays with Apple” argument for the general public has just fallen: it’s now also Google iron under Apple guarantees.

You’ve updated your Mac. You’ve accepted the TOS without reading (like everyone else). A few weeks later, you realize that the “Apple Intelligence” toggle is on, when you had turned it off. It’s not a hallucination: since macOS 15.3 released on January 27, 2025, Apple Intelligence has switched from opt-in to opt-out. And some users who had turned it off found it turned back on after 15.3.1, a bug confirmed by MacRumors and 9to5Mac, inconsistent from one device to another. Not a systematic rule, but frequent enough to check after each update.

It’s time to understand what happens when you click “Summarize” on a long email. Because between your Neural Engine and a California data center, there are three processing layers. Only one stays really on your machine.

Why this question is not harmless

Apple sells Apple Intelligence as an IA “privacy-first”. The slogan is everywhere on the product site: aware of your personal information without collecting your personal information. It’s technically true for part of the perimeter, and technically false for the rest.

A generative AI, by construction, needs calculation. When the model running on your Mac isn’t enough, the request goes out. Either to Apple servers or those of OpenAI. In both cases, your text leaves your machine. The question isn’t whether it goes out. It’s where, under what guarantees, and how Apple informs you (spoiler: badly).

Layer 1: the local model, what stays really on your machine

On Apple Silicon (M1 and later), Apple runs a foundation model of about 3.18 billion parameters. Quantified 2 bits per weight via Quantization-Aware-Training, memory footprint of about 1 Go, shared KV-cache that saves 37.5% RAM. The calculation happens on the Neural Engine, the GPU, and the CPU of the chip, never on a server.

In concrete terms, here’s what stays 100% local:

Writing Tools short version: Proofread, Rewrite, Summarize on short texts
Smart Reply in Mail and Messages
Notification summaries and Priority Notifications
Short Mail summaries in the inbox list
Genmoji (generation of custom emoji)
Image Playground (Animation, Illustration, Sketch)
Image Wand in Notes
Basic Siri (understanding, type-to-Siri)
Clean Up Photos

For these uses, your text does not leave the Apple Silicon. No logs, no server, no content telemetry. That’s the honest perimeter of Apple’s promise, and it’s real.

The problem starts when you ask for something else. Long summary of an 80-message Mail thread, generated text composition, multi-step Siri reasoning: your Mac knows it can’t handle the load. It switches. And Apple doesn’t display any indicator to signal it.

Layer 2: Private Cloud Compute, the California enclave

This is Apple’s marketing strong point. PCC runs on custom-silicon Apple in their data centers, with five technical guarantees highlighted in the Security Research doc:

Stateless computation: your text is used to respond, never stored after the request.
Enforceable guarantees: the protections are technically applied, not contractually promised. An Apple admin can’t disable the mechanism.
No privileged runtime access: no remote shell, no interactive debugging. Apple can’t extract your data, even voluntarily.
Non-targetability: an attacker can’t route your request to a compromised specific node. Request diffusion to nodes is random and attested.
Verifiable transparency: each production build published in a cryptographically append-only log, binary images available for external inspection for 90 days.

Apple pushed its PCC server code on GitHub, opened a research environment to external researchers, and put up a $1 million bug bounty. As of today, it’s the most auditable cloud IA stack on the market.

Now the nuances, because there are some.

Trail of Bits, in its June 14, 2024 analysis, points out a point that Apple marketing glosses over: “the data is decrypted on Apple’s server”. PCC is not homomorphic encryption (the tech that calculates a model on encrypted data without ever decrypting it). It’s a hardened enclave, signed, attested, but your text is indeed decrypted on the Apple side during the calculation. Security relies on the integrity of the enclave and the signing of the binaries, not on cryptographic magic. Apple is honest about this in the tech doc. The consumer slogan, however, leaves room for misunderstanding.

Second nuance, more uncomfortable. Matthew Green, cryptographer at Johns Hopkins, on Mastodon in June 2024: “Apple does not have explicit plans to announce when your data is going off-device for Private Compute, and you won’t opt into this or necessarily even be told it’s happening”. Translation: you don’t know if the summary of your mail stayed on your M2 or if it made a round trip to California. No visual indicator, no notification, no user-side journal. Apple’s transparency is cryptographically verifiable but visually invisible.

Layer 3: ChatGPT, the opt-in and its trap

ChatGPT is grafted onto Apple Intelligence since macOS 15.2. Turned off by default, activatable explicitly in Apple Intelligence & Siri → Extensions → ChatGPT. When you turn it on, Apple adds two protections over the standard OpenAI contract:

Your IP is masked by the Apple relay (verbatim Apple Legal: “your IP address is obscured from ChatGPT”). Approximate location passed, for legal compliance and anti-fraud.
No-logs and no-training on OpenAI’s side, provided you haven’t linked your OpenAI account. Apple Legal: OpenAI “must process your information solely for the purpose of fulfilling your request”, “must not store your information”, “must not use your information to improve or train its models”.

Read the conditional carefully. If you link any OpenAI account (free, Plus, Pro, Team) to retrieve your history or access GPT-5, you immediately opt out of Apple’s contract and fall back under OpenAI’s standard TOS. Logs, conversation history, potential training, all under US jurisdiction. Apple mentions this in the legal text, in small print, after three paragraphs. Most users link their account without realizing they’ve just turned off the protection that made them choose Apple.

Second detail. The “Confirm ChatGPT Requests” toggle is on by default: Siri asks for confirmation before sending the text. You can turn it off. But especially, if you start your voice request with “Ask ChatGPT…”, confirmation is bypassed. It’s a documented shortcut on Apple’s side, that circumvents the only visible safeguard of the device. Photos and files keep confirmation, they do, in all cases.

The four toggles to check

Four paths to know on Sequoia 15.x and Tahoe 26. The English titles are guaranteed (tested by Apple Support on US Macs), the French ones are the titles you’ll likely see, to be confirmed on your Mac.

1. The master Apple Intelligence System Settings → Apple Intelligence & Siri (toggle at the top of the panel). Default state since macOS 15.3: ON on compatible Macs. Documented cases of reactivation on 15.3.1 (bug, not design). Rare afterwards, but check after each update. Turn off if you want nothing, really nothing.

2. ChatGPT master System Settings → Apple Intelligence & Siri → Extensions → ChatGPT → Use ChatGPT. Default state: OFF. Activate only if you want it, and especially: don’t link your OpenAI account.

3. Confirm ChatGPT Requests System Settings → Apple Intelligence & Siri → Extensions → ChatGPT → Confirm ChatGPT Requests. Default state: ON. Leave it on. The confirmation friction is your only visual indicator that a request is going off your Mac.

4. Improve Siri & Dictation System Settings → Privacy & Security → Analytics & Improvements → Improve Siri & Dictation. Default state: OFF. Check that it stayed OFF. It decides if Apple stores audio snippets of your Siri interactions for human review. Random ID, hourly rotation, no Apple ID link, they insist. You choose to trust them or not.

Apple, Microsoft, Google: who does what

Five criteria that matter to someone wondering about sovereignty. Vendor by vendor verdict.

Apple Intelligence. Local by default, yes: 3B on-device model, explicit PCC switch for heavy queries. Public cryptographic attestation, yes: transparency log, dedicated research environment (VRE), server code published on GitHub. Cloud opt-in, half and half: implicit and invisible PCC, explicit and confirmed ChatGPT requests. Third-party LLM integrated, OpenAI ChatGPT, opt-in, OFF by default, no-logs as long as you don’t link your OpenAI account. Server jurisdiction, USA, Apple custom-silicon data centers.

Microsoft Copilot+/Recall. Local by default, partial: Recall makes its snapshots locally and never sends them to the cloud, Copilot general runs in Azure. Public attestation, no: local VBS encryption plus TPM, no opposing auditable server. Cloud opt-in, depends on the feature: Recall purely local, Copilot general cloud by design, the user doesn’t always distinguish which triggers what. Third-party LLM integrated, Azure OpenAI GPT-4, commercial integration without separate opt-in. Server jurisdiction, USA plus global Azure regions.

Google Gemini. Local by default, no: cloud Google by default, Gemini Nano local exists but remains limited to high-end Pixel devices. Public attestation, no. Cloud opt-in, the opposite: cloud by default, partial opt-out via Activity, and you lose features along the way. Third-party LLM integrated, none, Google’s stack locked down. Server jurisdiction, EEE/Switzerland via Google Ireland for EU accounts, rest of the world via Google LLC (USA).

A quick read: on this specific dossier, Apple does better. Recall version 2025 is solid locally but remains an attack vector on shared devices (Kevin Beaumont has documented it repeatedly). Gemini keeps a subset of chats for up to three years for human review, even when you turn off activity. Apple is the only one to publish its server code and pay $1 million to have it broken.

Apple spent $1 million to have its code broken. The others spent $1 million on TV spots. That doesn’t make PCC an E2EE. It makes it the least opaque cloud IA option on the market in 2026.

Mack’s verdict

Apple has built the most auditable cloud IA architecture on the mass market. That’s a fact. Trail of Bits, Matthew Green, and Schneier all recognize it, each in their own way, while pointing out what’s wrong.

What’s wrong is three UX decisions that betray a marketing intent superior to privacy intent: the opt-out by default since 15.3, the complete absence of a visual indicator when a request switches to PCC, and the silent OpenAI account link trap. None of these three points is a bug. They’re choices.

What you can reasonably do: turn off the master if you don’t need it, keep the ChatGPT confirmation toggle on if you use it, never link your OpenAI account, check Improve Siri & Dictation after each major update. That’s five minutes of settings, to be redone two or three times a year.

Also read: The cloud, it’s someone else’s computer, Privacy macOS: the settings to change immediately, and Convergence of digital freedoms.

Sources

Apple, primary sources

Apple Machine Learning Research, Introducing Apple’s On-Device and Server Foundation Models, official publication of the on-device model specifications (June 10, 2024).
Apple Machine Learning Research, Foundation Models Tech Report 2025 and arXiv 2507.13575, technical details of the 2-bit QAT, PT-MoE, 15 languages (July 17, 2025).
Apple Security Research, Private Cloud Compute: A new frontier for AI privacy in the cloud and Security research on PCC, the complete PCC doc and the bug bounty.
Apple Legal, ChatGPT Extension and Privacy and Apple Support, Use ChatGPT with Apple Intelligence on Mac, reference source for IP masking and conditional no-logs.

Independent analyses

Trail of Bits, PCC: a bold step forward, not without flaws, recognized security firm, the most cited technical analysis of PCC’s limits (“data decrypted on Apple’s server”).
Matthew Green, Mastodon/X thread on PCC, cryptographer at Johns Hopkins University, on the absence of a visual indicator when a request switches to PCC.
Kevin Beaumont (DoublePulsar), Microsoft Recall privacy implications, Windows security expert, on the residual risks of Recall version 2025.
MacRumors, macOS 15.3 enables Apple Intelligence automatically, coverage of the opt-in to opt-out switch (January 21, 2025).
IronCore Labs, Privacy Guide to Apple Intelligence with ChatGPT, for the OpenAI account link trap.

Comparison with competing IAs

Microsoft Support, Privacy and control over your Recall experience, Microsoft’s official Recall doc after the April 2025 relaunch.
Google Gemini Apps Privacy Hub, Google’s doc on retention, activity, and human review.

Domestic stalkerware, the jealous partner's malware

Mac Souverain — Tue, 26 May 2026 17:09:58 GMT

Public stalkerware (Spyzie, Cocospy, Spyic, mSpy) has over three million victims just within the Cocospy/Spyic/Spyzie family. Thirty to seventy dollars a month, operated by Chinese operators. On iPhone, your spouse knows your Apple ID and drains iCloud from the web. Less commonly, a hidden MDM profile installed by a close one in just two minutes. On Android, a hidden app. Premium modules: real-time GPS tracking and remote microphone activation. The victim never searches for the term “stalkerware” and doesn’t even know it exists.

What you need to do

1. Check Settings, General, VPN and Device Management. Any profile you didn’t set yourself, especially vague ones like “iOS Update”, delete it. Check Screen Time, disable any password you didn’t set.

2. Change your Apple ID password, enable two-factor authentication, remove unknown devices from your list, and enable Advanced Data Protection to switch your iCloud backups to end-to-end encryption.

3. Switch to Signal for sensitive messages, Bitwarden or KeePassXC for passwords, never a shared vault.

4. If you suspect active installation, act from another device and network. The Coalition Against Stalkerware lists resources by country.

On May 26th, Joseph Cox of 404 Media interviewed Zack Whittaker, the journalist who’s been leaking pretty much all the major consumer stalkerware cases for the past five years. Verdict? It’s not a niche market, it’s a mass market. Hundreds of thousands of victims on just one network. Targets iPhones and Androids. Installation by your partner, ex, roommate, in two minutes while you’re in the shower.

The Deal

Stalkerware is spyware sold to Joe and Jane Public. Not Pegasus, not Predator, not the mercenary spyware grade that Citizen Lab tracks from Toronto. The stuff you install on your girlfriend’s phone to read her messages, listen to her calls, track her location, and turn on her mic remotely. Brands like Spyzie, Cocospy, Spyic, mSpy, TheTruthSpy.

Whittaker’s been leaking these since 2021. The latest wave, February 2025, exposed 518,000 Spyzie clients including at least 4,900 compromised iPhones, and 2.65 million email addresses on the twin network Cocospy + Spyic. That’s over three million victims just from this one family of operators.

Monthly subscription? Thirty to seventy dollars for the standard plan, more if you add premium modules like mic and cam access. Companies live in offshore holdings, Cyprus, British Virgin Islands, or straight out of China. Cocospy, Spyic, and Spyzie are all the same team, traced back to one Chinese operator by Whittaker.

mSpy runs the same business model under a separate brand, legacy Cyprus-Ukraine. When leaks expose them, they shut down and reopen under a new name. Market size? Around $145 million a year, according to Future Market Insights.

On the iPhone side, the dominant method doesn’t even need physical access. Your partner knows your Apple ID password because you shared it, they’ve seen your iPhone unlock a hundred times, or you’ve used the same one for fifteen years. They log in to iCloud via browser, download your backups, and the stalkerware app does its thing server-side. No app on your phone, nothing to detect locally. Exactly how Whittaker documented Cocospy, Spyic, and Spyzie in 2025.

Rarer but more comprehensive variant: a configuration profile MDM, the mechanism designed for managing business fleets. The close one installs the stalkerware app via Apple Configurator on their Mac, supervising your phone with a Lightning or USB-C cable. The profile’s marked removalDisallowed, named something innocuous like “iOS Update” or “Battery Optimizer”. A Screen Time password your partner set hides the “Device Management” entry in Settings. You’re clueless. On Android, it’s the app disguised as a system tool, hidden behind a generic name, with accessibility turned on to read everything for you.

Why This Matters to You

Here’s where the usual cybersec press coverage drops off. We hear a lot about the mercenaries, NSO, Intellexa, Paragon, the billion-euro budgets and diplomatic targets. But the statistical danger for you? It’s not some state watching you, it’s your ex stalking you. States have their part too, pushing for mass control legislatively, as I’ve broken down in Six Months and Nineteen Global Texts, the Terrible Convergence. But the sheer frequency of domestic victims trumps all.

Whittaker’s been saying since 2021 that domestic stalkerware outdoes all mercenary spyware combined. The press ignores it because it’s dirty, intimate, lacks Pegasus’ geopolitical cachet.

Information asymmetry is total. Buyers find these products in three clicks: fake “Top 10 spy apps” sites owned by sellers, SEO on jealous searches, Reddit with affiliate accounts, TikTok in “POV I hooked my guy” format, Google Ads hijacked on “Find My iPhone” or “family locator”.

Marketing facade: “parental control for kids” quickly pivots to “monitor your spouse”. Potential victims never search for “stalkerware”. They don’t even know it exists. That’s the definition of a threat you don’t see coming.

You’re the target. Couple with iPhone and Mac, integrated Apple ecosystem, shared iCloud family, common passwords “because we trust each other”. When trust cracks, siphoning takes a few clicks from a browser, or two minutes MDM installation while you’re out. You’ll only know reading this.

What You Do Now

1. Check your iPhone, configuration profiles, and Screen Time.
Settings, General, VPN & Device Management. If you see a profile you didn’t install, especially with a vague name like “iOS Update”, “Battery Saver”, “Profile Service”, delete it. Then Settings, Screen Time. If a password’s active and it’s not yours, disable via your Apple ID. That password often hides the VPN & Device Management entry. If the delete button’s greyed out or the profile returns after “Reset All Settings”, it’s removalDisallowed with active DEP supervision: need Apple Store server-side break. Apple reference: remove a configuration profile.

2. Take back control of your critical accounts.
Change your Apple ID password immediately and enable two-factor authentication with a number your close circle doesn’t control. Check the list of devices connected to your Apple ID in Settings, top. Any unknown device, delete it. Enable Advanced Data Protection for end-to-end encrypted backups, server-side exfiltration becomes useless.

3. Switch to E2EE tools for sensitive stuff.
Critical messages on Signal, not iMessage. Passwords in your own manager, Bitwarden self-hosted or KeePassXC local file, not a shared Apple Keychain. Local encrypted backups on external drive, not just iCloud.

4. If you suspect active installation, leave the physical perimeter before acting.
Stalkerware with mic and GPS rats you out in real-time. Contact specialized help services from an unsurveilled device and network. The Coalition Against Stalkerware lists resources by country and a response kit for victims.

Sources

Millions of people are installing malware on their partner’s phones, with Zack Whittaker, 404 Media, 26/05/2026 (primary source)
Spyzie stalkerware spying on thousands of Android and iPhone users, TechCrunch, 27/02/2025 (Whittaker’s investigation, 518k clients + 4,900 iPhones)
Cocospy and Spyic exposing phone data of millions of people, TechCrunch, 20/02/2025 (market architecture, 711.icu China link)
Cocospy stalkerware apps go offline after data breach, TechCrunch, 19/05/2025 (post-leak rebranding pattern)
Stalkerware apps escape Google’s ad ban, TechCrunch, 11/08/2020 (Google Ads workaround)
Coalition Against Stalkerware, victim resources

Tech terms? Check the glossary.

The U.S. cyber regulator let its AWS keys slip six months ago.

Mac Souverain — Tue, 26 May 2026 13:39:33 GMT

**CISA, the U.S. federal cyber agency, just found out that one of its subcontractors left a public GitHub repository full of AWS GovCloud admin keys, tokens, and cleartext passwords for six months. External detection by GitGuardian, not internal. The keys remained valid for 48 hours after the repo was removed. If the federal cyber regulator can’t even keep its own secrets, how are you supposed to? Let me explain!

What you need to do

1. Inventory what you’re currently entrusting to a third-party cloud, and for each item ask yourself who has the decryption key. At-rest encryption with server-side keys equals zero.

2. Choose your cloud providers based on one criterion: end-to-end encryption, client-side keys (Proton, Tuta, Mullvad for EU).

3. What happens at home stays at home: backups on encrypted APFS external disk, double offsite encrypted copy.

The Deal

On May 22, 2026, Brian Krebs published the investigation. An employee of Nightwing, a historic subcontractor of CISA based in Dulles, Virginia, created a GitHub repository named “Private-CISA” on November 13, 2025. The word “Private” in the name, the public setting in the parameters. The repo remained online, accessible to anyone, until mid-May 2026. Six months.

Inside, there’s heavy stuff. Three sets of admin keys for AWS GovCloud accounts, Amazon’s cloud environment dedicated to US federal agencies, certified FedRAMP High for hosting non-classified sensitive data (CUI).

Access tokens, SSH keys, internal logs, and clear-text passwords following the “platform-year” pattern that a third-year intern wouldn’t dare to try. Plus some internal documents about the agency’s software development processes. Almost nothing, huh!

And the detection? Neither CISA internal nor Nightwing audit. It’s Guillaume Valadon, a researcher at GitGuardian, who continuously scans public repos for forgotten secrets, who found the repo. Krebs and the consulting firm Seralys notified CISA, which had the repo taken down. The cherry on top: the AWS keys remained valid for 48 hours after the repo was removed before the agency decided to revoke them.

CISA’s official statement is one sentence we’ve seen a hundred times: “At this stage, there’s no indication that sensitive data has been compromised.” Nightwing refers to CISA, CISA refers to the investigation. Krebs qualifies the incident as “one of the most scandalous government data breaches in recent history,” and Bruce Schneier repeats the phrase without qualification.

Why it matters to you

You’re not CISA, you don’t have a Nightwing subcontractor, you don’t use AWS GovCloud. Great. Now, do the cold calculation. The agency that sets the cybersecurity standards for US administrations, that publishes “secure by design” guides and CVE alerts followed by the entire industry, just left its own cloud admin keys open for six months without noticing. Not some dodgy subcontractor or some third-rate SaaS: the cyber regulator itself.

The argument is structural, not anecdotal. When you entrust your secrets to a third party, no matter how serious they claim to be, you inherit their entire supply chain. CISA entrusts to Nightwing, Nightwing employs someone, that someone pushes to GitHub. The weak link compromises the entire chain in an instant. That’s bad enough on its own, but add the IA threat surge, and you’ve potentially got a backdoor into more confidential systems.

Let’s get back to you. You have a personal GitHub repo? You’ve ever pasted an API key into a commit for “quick testing” before forgetting to remove it from history? You use a cloud-owned password manager for creds that open your infrastructure? You trust a SaaS editor under foreign jurisdiction to keep your secrets securely encrypted for you? The CISA radar is you in miniature, but with fewer zeros on the consequences.

The MacSouverain angle doesn’t change by a millimeter from the first article. Keep your secrets with you. On your machine, in your local vault, under your key. You can delegate the formatting, syncing, encrypted backup. You don’t delegate security itself. Because the day your provider screws up, and they will, you want the blast radius to stop at them.

What you do now

1. Inventory what you’re currently entrusting to a cloud third party.
Grab a sheet of paper. Passwords, emails, contacts, files, notes, photo backups. For each one, write where it’s stored and who has the decryption key. If the answer to “who has the key” is “the provider, or one of their subcontractors,” you’re in exactly the same position as CISA. You’re trusting a chain you don’t control a link of.

2. Choose your cloud providers based on “end-to-end encrypted, key on client side”.
For what you have to put in the cloud (multi-device sync, sharing, backup), only accept providers who can’t read your content, even if they wanted to or were asked to.

For email and storage: Proton or Tuta, European jurisdiction, end-to-end encrypted by default. For VPN: Mullvad or Proton VPN, no logs. The difference from AWS, Google Drive, iCloud non-ADP: you don’t have to take the provider’s word for it, the architecture makes unauthorized access technically impossible.

3. What happens at your place stays at your place.
Whatever you can keep local, keep it local. Photos, archives, sensitive documents, backups: an encrypted APFS external drive at home, plus a second encrypted copy you store with a friend or in a safe. If you need to sync files between your own devices without going through a third party, Syncthing does direct P2P between your devices, period. You don’t go to the cloud by default, you go there deliberately. The CISA rule applies in miniature to everyone: the day your provider screws up, and they will, you want the blast radius to stop at them, not take you down with them.

Sources

CISA Admin Leaked AWS GovCloud Keys on GitHub, Krebs on Security, May 22, 2026 (primary source)
CISA Security Leak, Schneier on Security, May 22, 2026 (commented repost)
GitGuardian, scanner of secrets in public repos

Your Mac was patched by XProtect without your knowledge, it's for your own good

Mac Souverain — Tue, 19 May 2026 07:25:30 GMT

While you were sleeping, on the evening of May 11th, 170 software packages, used by half of the web, became malicious in just six minutes. The next day, Apple pushed an XProtect signature onto your Mac, without telling you.

The two events are likely connected. However, you’ll never know for sure. This incident has a name, TanStack. The mechanism that may have reacted on your Mac is called XProtect. You didn’t see anything, neither did I. Apple makes sure of that.

Welcome to the silent defense system of your Mac.

The TanStack Incident in 30 Seconds

On the evening of May 11th, 2026, the TanStack ecosystem, an ultra-popular JavaScript toolkit used by millions of developers (including those from OpenAI, Netflix, Shopify), was compromised. In six minutes, 170 packages were released with malicious versions. The most visible one, react-router, is downloaded 12 million times a week. In other words, a significant portion of the web that updates this week is getting infected without knowing it.

The malware is called Mini Shai-Hulud, a variant of the npm worm that has been around since 2024. Its target is whatever is on the developer’s Mac: passwords, cloud access keys, GitHub tokens, session files. On macOS, it installs itself discreetly and relaunches every time a session is opened. Clean, professional.

The worrying detail is the vector. The attacker didn’t steal any passwords or exploit any code flaws. They just submitted a false contribution to the open-source TanStack project, exploiting an imprudent automation system configuration.

Any contribution was executed with the real publication rights. A malicious pull request was enough to retrieve the signature token and publish 170 packages under the legitimate identity of the project. On npm’s side, everything seemed normal, signed, and verified. Stamped by TanStack itself.

OpenAI was affected by association, via one of its dependencies. Officially, there’s no proof of any product or user data compromise. But they still rotated all their applicative signature keys on macOS, iOS, Windows, and Android, and republished all their apps under new certificates.

You don’t do that when everything’s fine.

Apple reacted the next day. No communiqué, no notification, no tab in Settings. An XProtect signature was silently pushed. Macs picked it up over the hours, one by one, without telling anyone.

XProtect, Apple’s Silent Antivirus

XProtect is macOS’s integrated antivirus. It’s been there since Snow Leopard, and most users don’t even know it exists. That’s by design.

It works in two parts. The first is the signature engine: a file that macOS consults before executing a downloaded app to check if it matches a known malware. The second is XProtect Remediator, XPR, a scanner that runs in the background and inspects your disk for threats that are already installed. When it finds one, it neutralizes it.

Signatures are pushed by Apple via CloudKit, the same silent pipeline that synchronizes your iCloud photos and keychain. When a significant malware emerges, Apple compiles a signature, signs it, deposits it on CloudKit. Your Mac picks it up during the next check, usually within 24 to 72 hours.

No notification. No restart. No “your Mac has been updated” message. Apple made an editorial choice not to alarm users. The downside is that you have no way of knowing, at a glance, if you’re properly patched for the recent incident.

That’s where it gets interesting.

The Push 5344, May 12th, the day after TanStack

The XProtect version published on May 12th, 2026, is called 5344. The previous one, 5342, was from May 5th. Perfect temporal match with TanStack, one day later.

Except Apple never publicly documents the content of an XProtect signature. Howard Oakley, who dissects each release on eclecticlight.co, notes on 5344 “some adjustments on known malware families”. No TanStack or Shai-Hulud signature. Nothing officially saying “this is the response to yesterday’s incident”.

Coincidence or targeted reaction? Apple isn’t saying. That’s precisely what justifies looking into it.

Check in 30 Seconds if Your Mac is Patched

On macOS 15 Sequoia and macOS 26 Tahoe, Apple moved XProtect to a new location and provides a native command. That’s the recommended way. On macOS 14 Sonoma and earlier, the old location is still valid. I’ll give you both.

1. The XProtect signature version

On Sequoia and Tahoe:

sudo xprotect version

You’ll get a number like 5344 or 5347. That’s the signature base. The higher the number, the more recent it is.

On Sonoma and earlier:

defaults read /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info CFBundleShortVersionString

The old path still exists on Sequoia and Tahoe, but macOS doesn’t consult it first anymore. You can read it and get an outdated version while sudo xprotect version gives you the real one. That’s exactly the kind of trap that makes you think your Mac is behind when it’s not.

2. The XProtect Remediator version

defaults read /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/Info CFBundleShortVersionString

You’ll get a number like 157. That’s the scanner itself, updated much less often than the signatures.

3. The installation history

system_profiler SPInstallHistoryDataType | grep -A 2 -i xprotect

You’ll see all the XProtect versions installed with their dates. Great for checking if your Mac isn’t stuck on an old base because CloudKit has a problem.

To compare your version with what Apple publishes in real-time, the public tracker on Howard Oakley’s eclecticlight.co keeps the list up-to-date. Oakley is a British engineer who’s been dissecting macOS for fifteen years. He’s the reference on the subject.

And if your Mac is behind, force the check:

sudo xprotect update

On Sonoma and earlier, the old command sudo softwareupdate --background-critical still works.

At the time of publishing, the latest version is 5344, on May 12th, 2026. If your Mac shows less, your CloudKit channel is slow.

The Sovereign Downside

XProtect is a black box signed by Cupertino. You don’t know which signatures are pushed, what telemetry is sent back, or who decides that a binary is malicious. Apple decides, Apple pushes, your machine executes.

The mechanism is useful, very useful even. Blocking known malwares before they execute is the base of modern defense, and doing it without bothering you will prevent you from disabling it when you’re fed up with that rognutudju!! pop-up (look it up, if you’re under 50, you won’t get the reference).

The three commands above give you a minimal right to look into what your OS does without asking. It’s a small step towards sovereignty, not taking control back, just knowing.

The difference between a passive user and a sovereign user isn’t just in the tools they use. It’s also in the questions they ask. What version do I have? When was it pushed? What’s in it?

Apple answers the first two with three Terminal lines. On the third, they stay silent. It’s Howard Oakley who dissects the content afterwards and publishes the diffs on eclecticlight.co. You’ll never know directly what Apple has stamped as malicious that night.

Every month, I still check the XProtect versions on my Macs. Nothing heroic, just a habit. The day CloudKit’s channel screws up, I’ll have a reference point.

Read also: The macOS settings to change immediately

In Summary

XProtect is useful, silent, and out of your control. The topic is knowing that it exists, knowing the three commands that tell you where you stand, and understanding that in the 2026 JavaScript supply chain, like others, it patches the leaks.

Run the three commands. Note your numbers. Compare them to eclecticlight.co every now and then. It takes thirty seconds, and it lets you know if you’re properly patched and up-to-date.

Read also: Lockdown Mode vs. Coruña, the government spy toolkit

Technical terms? Check the glossary.

Five years of defending memory M5 down in five days

Mac Souverain — Tue, 19 May 2026 07:23:49 GMT

Three researchers took full control of a Mac M5 in five days, with a helping hand from Mythos, Anthropic’s specialized IA vulnerability AI. In the process, they took down MIE, Apple’s five-year-old memory protection. Apple patched it in macOS Tahoe 26.5 on May 11. First public kernel exploit on M5 silicon, and a real-world show that AI can speed this kind of work by a factor of ten.

What you need to do

1. Update macOS Tahoe 26.5 immediately (System Preferences, Software Update).

2. Enable Lockdown Mode if you’re professionally exposed (journalist, activist, executive).

3. Avoid all unverified user binaries. Strict Gatekeeper, signatures on Homebrew.

The Deal

On May 14, 2026, Calif.io spilled the beans on how they did it. Three researchers (Bruce Dang, Dion Blazakis, Josh Maine) found two bugs in the macOS kernel on a brand-new Mac M5. They chained them together. Result: a regular user, with no special privileges, gains full control of the machine (root). Reading all memory, accessing the Keychain, disabling protections. Everything.

What makes this historical is what came out alongside it. The M5 chip debuts MIE (Memory Integrity Enforcement), a protection hard-coded into the silicon. In other words, Apple tagged every piece of memory used by the kernel, and the hardware refuses tampering. Five years of work. Unveiled last year as the new frontier of Mac security. Calif bypassed it in five days.

The game-changer: Mythos. It’s Anthropic’s frontier model, restricted access for vulnerability research. The researchers clarify that Mythos didn’t find the exploit alone. Bypassing MIE requires sharp human expertise. But Mythos spotted the bugs fast, where humans alone would’ve taken weeks. Months of work now takes days.

Calif handed the details to Apple in Cupertino. Apple released the fixes in macOS Tahoe 26.5 on May 11, 2026. The release notes credit “Calif.io in collaboration with Claude and Anthropic Research”. The full technical report (55 pages) is under embargo until the patches roll out everywhere. Apple hasn’t publicly commented on the exploit chain.

Why it matters to you

If you’ve got a Mac M5, your hardware was sold as the high-water mark of Apple security. Five days after the exploit was released, the frontier moved. Hardware protection alone isn’t enough; a well-equipped human can bring it down in a week.

Good news: it’s not a remote attack. To exploit the bugs on your Mac, the attacker needs a foothold. A booby-trapped binary you ran yourself (compromised Homebrew, app grabbed outside the App Store, file opened from a sketchy shared drive). From there, though, they’re root and can do whatever they want.

The bigger picture: Mythos is making waves. On May 11, curl maintainer Daniel Stenberg confirmed a flaw in his code found by Mythos (Stenberg’s still skeptical, but acknowledges the result). Three days later, Calif.io took down MIE. The window between ‘bug discovered’ and ‘functional exploit’ is closing. Apple, Google, and Microsoft have all publicly acknowledged that the latest AI models are changing the threat model. We’re seeing it in practice now.

What you do now

1. Update macOS Tahoe 26.5 right now, on all your Macs (M5, M4, M3, M2, M1, Intel). The update covers bugs beyond just the M5. System Preferences, General, Software Update. If you’re still on macOS Sequoia 15.7.7 or macOS Sonoma 14.8.7, they got the cousin fixes the same day.

2. Turn on Lockdown Mode if you’re professionally exposed (journalist, activist, executive, researcher). Lockdown Mode severely cuts the kernel memory attack surface, exactly what Calif exploited. System Preferences, Privacy & Security, Lockdown Mode. Beware, there’ll be friction.

Read: Lockdown Mode, why to turn it on

3. Avoid binaries from nowhere. No out-of-App Store apps without audit, no random executables. Verify signatures (GPG, SHA256) on sensitive tools, Homebrew included. Set Gatekeeper to strict in System Preferences, Privacy & Security, allow only the App Store.

4. Stay tuned: Calif’s 55-page tech report comes out once the patches are widely deployed. When it’s public, expect a wave of copies on GitHub and a full Mac fleet scan by security teams. Until then, just stay updated.

Sources

Also see

Anthropic Mythos: unauthorized access identified

Google Ads and real cat Claude share your credentials

Mac Souverain — Thu, 14 May 2026 11:58:10 GMT

A malicious ad campaign is hijacking Google Ads and Claude.ai’s Share function to promote MacSync, an info-stealing macOS malware that empties your Keychain with a simple terminal command you paste yourself. The pattern combines two trust signals (official claude.ai domain + fake Apple Support) to lure you into running base64 without suspicion.

What you need to do

1. Never paste a terminal command dictated by a website, AI chat, or an “official” PDF.

2. Enable Little Snitch or LuLu and monitor unexpected network traffic.

3. If already executed: disconnect from Wi-Fi, change all your browser passwords, and scan with KnockKnock.

You’re searching “Claude mac download” on Google. The first sponsored result points to claude.ai, so the URL is legitimate. Except it’s a shared Claude chat where a fake “Apple Support” dictates a Terminal command to paste. You paste it, and MacSync steals your Keychain, cookies, and browser credentials.

The Fact

Berk Albayrak (Trendyol Group) and BleepingComputer have been documenting since May 10, 2026, an active macOS malvertising campaign that exploits two legitimate mechanisms simultaneously. First, Google Ads: a sponsored ad for “Claude mac download” points to claude.ai, Anthropic’s official domain. Then, Claude.ai Share: this feature is used to host a fake installation guide signed “Apple Support” that tells the user to paste a base64-encoded command into Terminal.

The command downloads a polymorphic shell script from the attacker’s infrastructure, checks the keyboard layout (exits immediately if Russian or CIS), then executes the second-stage payload via osascript (macOS’s native AppleScript engine) for fileless delivery. The malware is called MacSync, an infostealer that collects browser credentials and cookies, exfiltrates the macOS Keychain, and fingerprints the victim (IP, hostname, OS version, keyboard language).

The indicators of compromise published are payload customroofingcontractors[.]com/curl/ and bernasibutuwqu2[.]com/debug/loader.sh, exfiltration to briskinternet[.]com. The two identified Claude.ai Share URLs are claude[.]ai/share/9aac1046-a39e-4618-8265-f54c4be863f7 and claude[.]ai/share/eb2db455-1d47-4baf-8671-0a689e165902.

Don’t worry, the links are disabled here, but Anthropic hadn’t disabled the Share mechanism at the time of BleepingComputer’s publication.

Why This is a Game-Changer

Two things, really. First, the “shared chat” feature of a public AI platform becomes a malware distribution surface. Claude.ai’s shared pages are public, indexable, and notably, not moderated like typical user content. They inherit Anthropic’s visual trust, and at the time of BleepingComputer and GBHackers’ publications, both compromised share URLs were still online.

Second, AI brand hijacking joins known malvertising schemes (Homebrew, Loom, Notion, AnyDesk), with Claude Code being a recent dev tool, its official installation page isn’t yet a muscle memory reflex, leaving an exploitable window.

This is also a case study on Google Ads, despite announced controls, ads impersonating brands continue to slip through, exploiting the legitimate display URL while pointing to a compromised page on the editor’s own site.

Domain validation isn’t enough when the editor hosts user content. Responsibility is shared, Anthropic needs to beef up shared chat moderation (detect chats posing as official support of other brands, banner on chats containing shell commands, visual watermark distinguishing a shared chat from a product page), Google needs to go beyond display domain in Ads validation. But the last line is you, never paste a Terminal command blindly.

Why This Matters to You

The social engineering pattern here is ruthless because it chains two usually legitimate trust signals. The claude.ai official domain, native Anthropic Share feature, fake “Apple Support” in a supposedly serious AI environment. You’re not clicking on some obscure download site, you’re clicking on what looks like official documentation brought up by a search engine, exactly the kind of attack that slips under usual vigilance.

The target is wide. Not just developers (Homebrew, GitHub), but any Mac user curious to try Claude desktop. The malware doesn’t require any system elevation, no 0day, no TCC bypass, the user does all the work themselves by pasting the command. And since osascript is a native, signed Apple binary, it slips under most commercial EDRs and even XProtect.

The angle that concerns you directly: it’s the offensive return of the macOS Keychain as a prime target. You’ve learned to protect your Mac’s user password, enable FileVault, use Touch ID. But a Terminal command launched by yourself circumvents all that, because you’re the one opening the door.

What You Do Now

1. Never paste a Terminal command dictated by a website, AI chat, or “official support” PDF. If you must install a tool like Claude desktop, go directly to claude.ai/download by typing the URL yourself, never via a sponsored Google result. The universal rule: if someone tells you to paste anything into Terminal, it’s a no.

2. Enable Little Snitch or LuLu in hardened silent mode. Both log and block unexpected outgoing network connections to the published IOCs (customroofingcontractors[.]com, bernasibutuwqu2[.]com, briskinternet[.]com). If you suspect a hasty command, check outgoing connections in the minutes after.

3. If you’ve run a suspicious command recently: disconnect from Wi-Fi immediately, change all your browser passwords (from a clean device), revoke all active cloud session tokens (mail, sync, password manager), scan with KnockKnock or ReiKey from Objective-See, check launch agents in ~/Library/LaunchAgents/.

4. Monitor your Keychain. security dump-keychain | grep -i password tells you what’s inside. For the future, migrate sensitive passwords to Apple Passwords or Proton Pass, not the general iCloud Keychain by default.

Sources

Apple patches iOS and macOS CVE vulnerabilities: fixes, then tweaks Safari profiles

Mac Souverain — Wed, 13 May 2026 14:15:25 GMT

iOS 26.5 and macOS Tahoe 26.5, released on May 11, fix 98 CVEs each (including 21 and 22 in WebKit). Global Lockdown Mode is overkill for daily use. Safari profiles, available since iOS 17, segment usage for you.

What you need to watch out for

1. Install iOS 26.5 and macOS Tahoe 26.5 today.

2. Create a “Cautious” Safari profile with only privacy extensions enabled, use it for banking, webmail, suspicious links, and medical research. Keep your default profile untouched for everything else.

Apple Publishes iOS 26.5 and macOS Tahoe 26.5, Fixing 98 CVEs

On May 11, Apple released iOS 26.5 and macOS Tahoe 26.5. These updates address 98 security vulnerabilities on iOS (including 21 on WebKit, Safari’s engine) and 98 on macOS (including 22 WebKit). Several of these vulnerabilities allowed malicious websites to execute code or bypass sandbox protections. As usual with Apple releases, WebKit takes the biggest hit, as it’s the largest attack surface on an iPhone or Mac.

Patch now. That’s a no-brainer. The real question is, what do you do between patches, when clicking on mail links, conducting sensitive searches, or logging into online banking?

Why Lockdown Mode All the Time is Too Much

Lockdown Mode is robust. MacSouverain praised it in article 29. It’s perfect for journalists, dissidents, or lawyers handling sensitive cases.

But for freelancers or small businesses just checking email, doing online accounting, or watching recipes, it’s overkill. Disabled JIT JavaScript, cut Safari extensions, restricted media formats, filtered Messages attachments. Too much friction, too many websites breaking. The usual result: you enable it for a few days, find it annoying, disable it, and end up with nothing.

What are Safari Profiles?

Since iOS 17 and macOS Sonoma (September 2023), Safari supports multiple profiles within the same app. It’s been quiet, never highlighted in keynotes. Most people you talk to don’t know it exists.

Each profile has its own history, cookies, enabled extensions, search engine, favorites, and tab groups. No mixing: Google’s session cookie from your “Personal” profile isn’t seen by your “Sensitive” profile. Privacy extensions active on “Sensitive” don’t slow down “Personal” navigation. Switch in two taps (tap on tabs on iPhone, Safari menu on Mac), syncs with iCloud between Mac and iPhone.

It’s the usage segmentation we’ve advised for years in security, without installing a second browser.

What to Do Now

1. Install iOS 26.5 and macOS Tahoe 26.5. Settings, General, Software Update. Twenty minutes, including restart.

2. Create a “Sensitive” Safari profile. On Mac: Safari, menu, Create Profile. On iPhone: Settings, Apps, Safari, Profiles, New Profile. Name, icon, color.

3. Configure the “Sensitive” profile: DuckDuckGo or Qwant search engine (setting per profile), empty favorites, and add two or three privacy extensions active only on this profile: AdGuard for Safari (free on App Store, network and cosmetic filtering), Vinegar if you want a clean YouTube (one-time purchase), StopTheMadness Pro if you already have its license. Your default profile remains untouched, no slowdown when surfing normally.

4. What the profile doesn’t isolate: advanced Safari settings (block all cookies, disable JavaScript, tracking block) are global, applying to all profiles. If you want to toughen these toggles, do it globally in Settings, Apps, Safari, knowing it’ll affect your default profile too.

When to Switch to the “Sensitive” Profile

Clicking on a link from an unknown sender. Medical or legal research. Bank or broker login. ProtonMail on the web from a less-used device. Any site you’re unsure about and don’t want to cookie your main profile with. Two taps, switch, do what you need to do, switch back.

Usage segmentation, not global hardening. Keep your comfort on your default profile, have a “clean navigation” mode on hand.

What It Doesn’t Replace

Safari profiles aren’t Lockdown Mode. JIT JavaScript remains active on all profiles. If you’re a journalist handling sensitive sources, a lawyer on a sensitive case, a dissident, or if you’ve received an Apple threat notification, use global Lockdown Mode. Safari profiles are a tool for daily use, not state actor protection.

Basic hygiene doesn’t change: patch (iOS 26.5 now), don’t open unexpected attachments, verify URLs before entering passwords.

Sources

kSuite vs Google Workspace, the honest comparison

Mac Souverain — Sun, 10 May 2026 14:27:21 GMT

Introduction

Every month, you fork out cash for Google Workspace. You’re a MacSouverain reader, so privacy’s a big deal for you. Eventually, the cognitive dissonance gets unbearable.

The question isn’t “Is Workspace bad?” It’s great, it’s the gold standard. The question is: what exactly are you paying for, and what are you trading for it? And is there an alternative that gives you your Mac, your jurisdiction, and your data back, without forcing you to downgrade?

kSuite, brought to you by Infomaniak from Geneva, makes that very promise. Let’s see if it delivers.

The Criteria That Matter

Comparing two collaborative suites without a grid is like doing a PR piece. Here are the six criteria I’ve chosen, and what I’ve deliberately left out.

Jurisdiction and Data Sovereignty. Where data is stored, under which law, who can access it legally. This criterion trumps everything else for MacSouverain because it’s structural and non-negotiable with features.

Real Encryption. Not “encrypted” in general. At-rest, in-transit, and especially end-to-end: who holds the keys. This is the only grid that withstands a warrant.

Price and Transparency. How much you pay per user, what you get, what changes when the editor does a “pricing update”.

Native macOS and iOS Integration. Apple Mail, Calendar, Contacts, Files. Can you work without installing a single app from the editor on your Mac. This is the “practical sovereignty” marker.

Professional Functional Coverage. Pro mail, shared drive, video conferencing, collaborative docs, admin console, SSO, MDM. A suite that forces you to keep another one nearby is a half-suite.

Exit Strategy. Export, standard formats, import from the competitor. You’re not married to your cloud provider, unless you choose to be.

What I DID NOT evaluate: very specific use cases (Workspace for Education, HIPAA compliance in the US, FedRAMP). If you’re an American hospital, this comparison isn’t for you. If you’re a European SME, a freelancer, or a family office, we continue.

kSuite, by Infomaniak

The philosophy in two sentences. A collaborative suite edited by a Swiss hosting provider of 316 employee-owned people, ISO 27001 and 14001 certified, operating its own datacenters in Geneva and Winterthur. Not a reseller slapping a UI on third-party bricks, a vertically integrated editor.

The strengths.

Swiss, no FADP, outside CLOUD Act. Infomaniak is under Swiss jurisdiction, governed by the new Federal Act on Data Protection (FADP, in effect since 01/09/2023). No CLOUD Act applies. Switzerland benefits from an adequacy decision for GDPR transfers. For an EU client or anyone attached to keeping their data from making a legal detour to Washington, that’s argument enough.

Built-in, free, transparent OpenPGP in kMail. Infomaniak enabled end-to-end encryption via OpenPGP in kMail webmail on June 17, 2025, for all plans, no add-on required. You enable, you exchange keys with your contact, your emails are encrypted end-to-end. Among major suites, only Proton and kSuite offer free OpenPGP in webmail. Google Workspace, Microsoft 365, and Zoho reserve their native encryption for Enterprise plans.

OnlyOffice under the hood of Docs, Grids, Points. The office suite engine in kSuite is OnlyOffice, AGPLv3, open source. High-fidelity compatibility with.docx,.xlsx,.pptx, better than Google Docs with native Office files. If your accountant sends you a.xlsx with macros and a wonky layout, OnlyOffice renders it correctly.

Open protocols everywhere. IMAP, SMTP, CalDAV, CardDAV, WebDAV. You configure Apple Mail, Calendar, Contacts, and Files.app without installing a single Infomaniak executable on your Mac. That’s rare, and it’s the purest integration criterion a cloud suite can tick.

kMeet with optional, free E2E. WebRTC video conferencing with optional end-to-end encryption activable when creating the meeting (shared key), documented by Infomaniak. Limited to Chromium browsers and desktop app, but it exists. Google Workspace’s equivalent (CSE) requires Enterprise Plus.

Transparent, stable pricing. kSuite Pro at 7.90 €/user/month for 3TB storage and full mail pro. No documented price increase since launch in 10/2022. The pricing promise holds.

The weaknesses.

MDM and Apple Business Manager: the gaping hole. No official ABM integration for kSuite. If you deploy a fleet of iPhones and Macs for business with federated authentication via Managed Apple ID, Workspace does it natively. kSuite requires a third-party MDM (Jamf, Mosyle, Kandji) with classic IMAP/CalDAV auth. It works, it’s less integrated.

Limited third-party marketplace. Google Workspace Marketplace has over 4,500 connected apps. kSuite has mostly Infomaniak suite and standard integrations. If your workflow relies on fifteen SaaS connected to Google Calendar, plan for a transition.

Mobile apps: solid, not reference. Infomaniak Mail and kDrive iOS are clean, but Gmail and Google Drive iOS remain the UX reference. It’s an experience gap, not a blocker.

Real-time co-editing: good, not excellent. OnlyOffice handles multi-user co-editing, but Google Docs is the absolute reference for latency and collaborative undo. If you spend all day simultaneously editing the same document with six people, you’ll feel the difference. Otherwise, not so much.

Euria vs Gemini. Infomaniak has its sovereign AI (Euria) for kMeet transcription and assistance. It’s decent, it’s not Gemini. If advanced AI-driven office suite is your top criterion, Google Workspace wins this point hands down.

Who it’s for. The freelancer, the SME, the family office, the liberal profession that wants a complete pro suite without CLOUD Act and without installing another proprietary app on their Mac. The MacSouverain profile, in short.

Prices (excerpts, real editor page on infomaniak.com/en/ksuite/ksuite-pro/prices).

my kSuite : free, 20GB, 1 @ksuite.infomaniak.com address, kMeet included. No personal domain.
my kSuite+ : CHF 5.75/month, 2TB, 1 domain + 5 aliases.
kSuite Standard : 1.90 €/user/month, 15GB per user, pro mail with domain.
kSuite Pro : 7.90 €/user/month, 3TB per user, pro mail + aliases, SSO SAML.
kSuite Enterprise : 14.90 €/user/month, 6TB per user, advanced admin.

Google Workspace, by Google LLC

Philosophy in two sentences. The collaborative suite that redefined the standard since 2006. Market reference for Gmail, Docs, Sheets, and Meet, integrated with almost every SaaS worldwide, under US jurisdiction and CLOUD Act.

Strengths.

Reference anti-spam email. Gmail filters better than anyone else, period. Fifteen years of machine learning feedback on billions of messages, that’s hard to beat. If you switch email providers, your spam folder will miss you for two months.

Co-editing Docs, Sheets, Slides. The inventor of the genre is also the master of it. Latency, suggestions, mentions, granular history: Google Workspace’s online office suite remains the reference, and all other suites measure up to it.

Giant third-party ecosystem. Google Workspace Marketplace, 4,500+ apps. Your CRM, your billing, your HR tool, your ATS: they all have a native Google connector. For kSuite, expect manual CalDAV/IMAP integrations when the third-party app allows it, or nothing when it doesn’t.

Official Apple Business Manager. Federated authentication with Managed Apple ID, DEP token, MDM deployment Workspace Endpoint Management covering macOS, iOS, ChromeOS, Android, Windows. For an SME managing a heterogeneous fleet, this is a real operational argument.

Gemini AI integrated into all plans. Since March 17, 2025, Google has bundled Gemini into the core tariff of Workspace. NotebookLM, Gemini in Docs, Gemini in Sheets, Meet transcription: it’s powerful, and it’s available without additional add-ons.

Vault, eDiscovery, DLP, BigQuery audit. If your profession has legal retention, legal hold, or serious data loss prevention obligations, Workspace Plus and Enterprise are mature on these topics for ten years. kSuite has audit logs, not the full regulatory stack.

Weaknesses.

CLOUD Act, the structural argument. Google LLC is a US company, subject to the 2018 CLOUD Act, which allows US authorities to demand data stored anywhere in the world from a provider under US jurisdiction. “European datacenter” doesn’t change anything: Microsoft France confirmed this under oath to the Senate. Workspace is not qualified SecNumCloud by ANSSI. The partnership with Thales S3NS to carry a qualification is underway, Workspace itself does not carry it.

Price increase in 03/2025, Gemini bundle imposed. Google increased the core tariff of all Workspace plans by integrating Gemini into the package: +16.7% on Business Starter and Standard (annual), +22.2% on Business Plus. You don’t have generative AI in your workflow? You’re still paying. This is the second global increase after 2023, Workspace pricing is continuously increasing.

End-to-end encryption reserved for Enterprise Plus. S/MIME hosted and CSE (Client-Side Encryption) are only available in Enterprise Plus and Education Plus, with an external KMS to configure (Thales, Fortanix, Stormshield, Flowcrypt). On Business Starter, Standard, and Plus, you have TLS in-transit and AES-256 at-rest with Google keys. That’s not E2E.

Native Apple apps: it works, but not great. Apple Mail with Google Account works, but Gmail labels become IMAP folders, the experience is degraded. CardDAV is officially deprecated by Google in favor of People API (still functional via native Google Account iOS, but long-term signal). In practice, the Workspace user ends up opening Gmail web and Drive iOS app: the “100% native Apple apps” argument falls apart.

Gmail lock-in. Gmail’s labels, filters, categorization are specific. Google Takeout exports everything (.mbox, EML), but reformatting on the new provider’s side isn’t trivial. You can leave, but it won’t be comfortable.

Customer data vs AI training. Google contractually commits not to use Workspace B2B data to train Gemini. That’s a contractual commitment, evolvable, separate from the commercial Gmail consumer engagement (which does share signals). Keep an eye on this over time.

Who it’s for. The company whose critical workflows depend on the Marketplace, the large group with serious eDiscovery needs, the US client where local compliance requires Google certifications, the team already set up with no operational argument to move.

Prices HT (annual, editor page workspace.google.com/pricing).

Business Starter: €6.80/user/month (annual), 30GB per user, Meet 100 participants, max 300 users.
Business Standard: €13.60/user/month, 2TB pooled, Meet 150 + recording.
Business Plus: €21.10/user/month, 5TB pooled, Vault eDiscovery, Meet 500.
Enterprise: quote-based, 5TB+, Meet 1,000, CSE, advanced DLP.

Launch promotion: 50% off for the first 3 months for the first 20 users, then standard pricing applies.

Face-to-face on the criteria that matter

Instead of a flat table that levels everything, let’s look at the six criteria one by one.

Jurisdiction and sovereignty

kSuite is Swiss, under the Swiss Federal Act on the Surveillance of Post and Telecommunications (FADP), hosted in Switzerland (datacenters in Geneva and Zurich region), outside the CLOUD Act, outside the GDPR (but with a valid EU adequacy decision). Workspace is US, under the CLOUD Act, global datacenters with the “data regions” Europe option in Enterprise plans. On this criterion, it’s not a comparison, it’s a difference in nature. If jurisdiction is decisive for you, the subject is already settled.

Real encryption

kSuite: Native and free OpenPGP E2E in kMail, optional in kMeet, AES-256 at-rest on kDrive with Infomaniak keys. No native E2EE drive. Workspace: TLS and AES-256 at-rest everywhere, hosted S/MIME and Customer-Supplied Encryption in Enterprise Plus only, BYOK with external KMS in Enterprise Plus. For email, kSuite wins hands down and for free. For the drive, both ask for a compromise: Infomaniak keeps the keys, or you pay for Workspace Enterprise Plus to have CSE.

Price and transparency

At equivalent tiers, kSuite is cheaper everywhere. Solo 2 To: my kSuite+ at 5.75 € against Business Starter at 6.80 € for 30 Go (a factor of 70 in storage). SME standard: kSuite Pro at 7.90 € against Business Standard at 13.60 € (kSuite 42% cheaper, 50% more storage). SME premium: kSuite Enterprise at 14.90 € against Business Plus at 21.10 € (kSuite 29% cheaper). And Workspace pricing goes up, kSuite’s hasn’t changed since 10/2022.

Native macOS and iOS integration

kSuite exposes IMAP, SMTP, CalDAV, CardDAV, WebDAV. Apple Mail, Calendar, Contacts, Files.app work natively without a single proprietary app installed. It’s the “100% Apple” scenario pure and simple. Workspace also works natively, but the real experience pushes the user towards Gmail web and Drive iOS. On the criterion of “installing nothing from the vendor”, kSuite wins without moving; on the criterion of “polished experience”, Workspace keeps the lead with its own apps.

Professional functional coverage

Both suites cover email, drive, calendar, contacts, video conferencing, collaborative docs, admin console, SSO. Workspace adds native MDM, official ABM, Marketplace with 4500 apps, advanced DLP, Vault eDiscovery. kSuite adds high-fidelity OnlyOffice, free OpenPGP, E2E kMeet. On pure coverage, Workspace has more depth; on functional sovereignty, kSuite has an edge.

Exit possibility

kSuite exports EML, MBOX, vCard, iCal, native OnlyOffice files. Workspace exports via Takeout (mbox, vCard, ics,.docx via conversion). Both let you leave. kSuite makes arrival easier: it has a documented Workspace import in the Manager console. The reverse (leaving Workspace for something else) works technically but isn’t guided.

Mack’s Recommendation

I’ll say it straight up because that’s my job: if you have a choice, kSuite is better than Workspace for your Privacy.

Not because Workspace is bad. Workspace is an excellent collaborative suite. But the MacSouverain user isn’t the average Workspace user. The reader of this site is a freelancer, a European SME, a family office, an independent who pays for a service and wants to know who can read their files, who can force them to be communicated, and what happens when an audit arrives. On these three questions, Workspace answers “Google, the CLOUD Act, we’ll handle it”, and kSuite answers “you, nobody, and an export EML file”, total Privacy.

If you’re a freelancer or solo and budget matters. my kSuite+ at CHF 5.75/month for 2TB is an obvious choice over Business Starter and its 30GB.

If you’re a 5-50 person SME in Europe. kSuite Pro at €7.90/user. You save 42% compared to Business Standard, keep your pro mail with domain, can configure Apple Mail and Calendar on the whole fleet without installing an app, and you’re out of the CLOUD Act. The only question to ask: does your fleet need federated MDM via ABM? If yes, seriously evaluate the cost of a Mosyle or Jamf as a complement.

If you’re already on Workspace with your whole workflow tied to it. A migration costs. You don’t have to do it this quarter. But there are two moments when reconsidering it makes sense: every time Workspace raises its prices (the next one is coming), and when a critical workflow breaks due to a Google change. Both moments will happen, statistically.

If you’re a family office in Switzerland, Germany, or elsewhere in the EU and US jurisdiction bothers you. You don’t pay an American cloud to store your pro correspondence and financial documents, it’s as simple as that. kSuite is the shortest answer.

For my personal use, I made a different choice, Proton Workspace, which makes the same sovereignty promise from a different angle (E2E everywhere by default, complete Proton ecosystem). If you’re hesitating between the two sovereign worlds, remember this grid: kSuite has the edge on pure native Apple integration (standard CalDAV, CardDAV, IMAP) and high-fidelity OnlyOffice; Proton has the edge on systematic E2E and the cohesive app suite. Neither brings you back to the CLOUD Act, that’s the essential part.

In summary

kSuite is cheaper than its equivalent, more sovereign by design (Switzerland, nFADP, employee-owned, ISO 27001), exposes open protocols that make native Apple apps fully usable, and includes free OpenPGP encryption in mail. Workspace is more polished on Gmail, Docs, and third-party ecosystems, more integrated with Apple Business Manager, and much more mature on Vault and DLP topics, at the cost of a US jurisdiction and continuous price increases.

In practice:

Freelance or solo, budget-conscious → my kSuite+ at CHF 5.75/month.
European SME 5-50 people → kSuite Pro at €7.90/user/month, with a third-party MDM if needed.
Critical Workspace workflow already in place → stay, prepare migration for the next pricing update.
Heavy US regulatory compliance → stay on Workspace.
EU family office, non-negotiable jurisdiction → kSuite, no hesitation.

Transparency: MacSouverain is affiliated with Infomaniak. Subscribing to kSuite via the links in this article supports the site, without changing the price you pay. If you want to help, it’s this way.

The Editors Themselves

Infomaniak, the employee-owned Swiss hoster from Geneva, has been editing kSuite since 10/2022. Product page, prices, and public ISO 27001 / 14001 / 5001 certifications.
Google Workspace, Mountain View, under US jurisdiction and CLOUD Act. Pricing page, security whitepaper, public ISO 27001.

Technical Documentation

kMail’s free OpenPGP announcement, picked up by Yahoo Finance on June 17, 2025.
Apple Business Manager × Workspace, Apple’s official guide. Native Managed Apple ID federation on Google’s side, not kSuite’s.

Independent Analyses

Wire, CLOUD Act vs EU sovereignty, Swiss messaging app Wire explains why a European datacenter isn’t enough if the company is US-based.
9to5Google, Workspace price hike 03/2025, tech press documenting the forced Gemini bundle and updated pricing grid.

Also see

Digital sovereignty, in practice: the general grid of which kSuite is a case study.
The cloud, it’s someone else’s computer: the mental framework behind this comparison.
DNS, the Achilles heel of your privacy: same logic of jurisdiction on another layer.

Proton Mail switches to post-quantum encryption (and it's free)

Mac Souverain — Wed, 06 May 2026 06:39:41 GMT

Proton Mail now offers an encryption option that’s quantum-resistant. Available on all plans, even the free one. You’ll need to turn it on yourself, and it only works for new emails.

What you need to watch out for

1. Enable the option in Settings, Encryption and keys, but don’t think it’ll protect your old emails, it only works for new ones.

2. The benefit is maxed out when the person you’re sending to is also on Proton. If they’re on Gmail or elsewhere, it’s back to classic encryption for that send.

3. End-to-end encrypted forwarding is temporarily incompatible. If you’re using it, pick one or the other until it’s fixed.

Proton Mail has just activated an option that protects your new emails against decryption by a future quantum computer. It’s available on all plans, including the free one, and you can enable it yourself. And it’s not just marketing.

The Fact

On May 5, 2026, Proton pushed a new option into Proton Mail’s settings: « Enable post-quantum protection ». Once enabled, new emails you send are encrypted with a combination of classical plus post-quantum algorithm, a type of cryptography designed to resist even a quantum computer of tomorrow. Available on all plans, including free, which is rare enough in the industry to warrant mention.

The option is not enabled by default. You go to Settings, Encryption and keys, and check it yourself. Proton justifies this caution due to the still-experimental status in the external ecosystem.

The idea behind it is to counter what’s called « harvest now, decrypt later ». In plain terms: an attacker could intercept and store your encrypted emails today, unable to read them, hoping to decrypt them in ten or twenty years when a powerful enough quantum computer exists. Today’s classical encryption (RSA, elliptic curves) would crumble like a house of cards. Post-quantum is the insurance that even this scenario yields nothing to the attacker.

Why It Matters to You

Several things to know before you rush to enable it.

The protection applies only to new emails. Anything already in your mailbox, sent or received before enabling, remains encrypted as before. Proton says so: « Post-quantum protection applies to new encrypted emails going forward. It does not retroactively re-encrypt emails that are already in your mailbox, for now. » If your old emails have already been intercepted by someone, this option doesn’t change anything for them. The « for now » suggests a retroactive re-encryption is on the roadmap, but it’s not delivered yet.

The recipient matters. The best scenario is Proton to Proton, where both sides have post-quantum keys. If your correspondent is elsewhere (Gmail, a classic OpenPGP client, etc.), Proton falls back on the usual encryption for that send, which is the only reasonable thing to do while waiting for others to adopt the same standard.

Some friction. If you’re using Proton’s end-to-end encrypted forwarding, it’s temporarily incompatible with the new option. You choose one or the other for now. There’s also a slight performance impact on sending, barely noticeable on recent hardware according to Proton.

The Game-Changer Angle: Open Standard vs Silos

Proton isn’t the first email service to offer post-quantum. Tuta (ex-Tutanota) did so since 2024, with its own proprietary scheme. Apple deployed PQ3 on iMessage in February 2024. Signal did the same with PQXDH in September 2023.

Proton’s difference is that it does so on OpenPGP, the open standard others can adopt. Apple PQ3 remains locked in the Apple ecosystem, Signal PQXDH doesn’t leave Signal, and Tuta’s scheme is proprietary to Tuta. Proton, meanwhile, bets on standardization, announced collaboration with the Thunderbird project, so tomorrow your sovereign email client (Thunderbird, GnuPG, or another) can read and write post-quantum emails compatible with Proton without going through the Proton app itself.

That’s the sovereignty angle. An open standard is what prevents your communication security from depending on the whim of a single provider. Today in practice, interop is still largely Proton-to-Proton, the external ecosystem isn’t there yet. But the direction is set, and that’s what distinguishes this announcement from mere marketing.

What You Do Now

1. Go to Proton Mail, Settings, Encryption and keys, and enable « Enable post-quantum protection ». Read the warning banner (forwarding, etc.) before validating.

2. Keep in mind that it only protects your new sends. If you have sensitive conversations archived, consider sorting them out. Retroactive re-encryption is coming later, but for now, it’s pure conditional.

3. If your correspondent is also on Proton, encourage them to enable it on their end. Until both ends are equipped, the benefit remains partial.

4. If you’re using Proton Bridge with Apple Mail (see the dedicated article), ensure your Bridge is up-to-date, or new post-quantum emails might not be readable on the local client side.