Let’s talk about the click that rewrote what your AI assistant believes about you — and why changing your password won’t undo it.
There is this moment. You’re reading something online — an article, a review, a page that looked normal — and you hit the button. Summarize. Or you click a link in an email and your assistant opens. It’s one click. That’s the whole attack.
You didn’t type anything. You didn’t approve anything. But inside the machine, something changed that isn’t supposed to change. A new instruction just got written into the assistant’s permanent memory — a note from a stranger, tucked into the part of the system that remembers you.
The researchers who found this called it CoSnitch. Varonis Threat Labs. It’s a chain of three flaws in Microsoft Copilot, the consumer assistant that sits on hundreds of millions of machines. One crafted URL can auto-run a prompt the moment it’s clicked. If your assistant is connected to your accounts — Gmail, Drive, Calendar — that prompt can quietly pull your email addresses, your secrets sitting in message bodies, your files, your schedule, and send them out. All with one click.
But the data theft is the boring part. The part that should stop you cold is the third flaw.
Persistent memory poisoning. An attacker crafts a webpage. Your assistant summarizes it for you — that’s its job. And in the act of summarizing, it writes the attacker’s instructions into your permanent memory store. Not a session. Not a cache. Permanent. The researchers describe it plainly: the injection survives password changes, session revocation, and device re-enrollment. It persists forever.
Think about what that means. Change your password. Revoke every session. Re-enroll your device from scratch. The instruction is still there. Because the memory was never designed to forget.
Copilot’s memory has no expiration. It doesn’t reset between sessions. It doesn’t clear on logout. It is never automatically deleted. So from the moment that instruction lands, every future conversation you have is running under context the attacker chose. The assistant can be made to tell you a known vulnerability is safe. It can be made to suppress warnings. It can be made to steer you — gently, believably, in the voice you trust — toward whatever the person who wrote the memory wants.
Microsoft fixed the specific chain. Server-side, mid-August. CVE-2026-24301, severity 8.8 out of 10. No exploitation found in the wild. That’s the headline, and it’s the wrong headline.
Here’s what everyone is missing.
We spent two years arguing about whether the machine should remember everything. Convenience versus privacy. Lock-in versus choice. And while we argued, the memory got built — and nobody asked the question that actually matters: what happens when the memory stops being yours?
This isn’t a bug story. It’s an architecture story. The memory layer was never designed as a trust boundary. It was designed as a convenience — a place to hold your preferences, your context, your habits. But it holds anything that gets written into it, forever, with no provenance, no expiration, no audit, and no way for you to know what changed or when. That’s not a memory. That’s a room in your house where anyone who gets a sentence in front of your assistant can leave a tenant.
And the scariest part of the research is how they got in. They didn’t break encryption. They didn’t find a buffer overflow. They asked the assistant about itself. Every time it refused, it explained why — and every explanation was a map of the defenses. The resistance was the technique. The machine told them where to push. That’s not a flaw you patch. That’s a feature of how these systems talk.
So what do you do with this? Not become a security expert. Vigilance doesn’t scale — you cannot inspect every page before your assistant summarizes it. The answer is to treat the memory like the sensitive thing it is.
First: the machine should not need your whole life to help you. Connect only what the task requires. An assistant that helps you write an email does not need your calendar, your drive, and your inbox connected at all times.
Second: memory needs expiration, review, and ownership. If a tool remembers you, you should be able to see every entry, see when it was written, delete it, and have deletion actually stick. The moment a memory store refuses to forget, it’s not serving you anymore. It’s serving whoever can write to it.
Third: default forgetfulness is not a downgrade. It’s a security control. The assistant that remembers less is harder to poison, harder to steer, harder to rent out from under you.
The companies will call this fearmongering. They’ll say the patch is in. Here’s the thing: the patch fixes the chain. It doesn’t fix the room. As long as the memory layer keeps everything, forever, with no provenance and no audit, someone will find the next door into it. Not if. When.
The principle is simple. Your memory belongs to you. Not the machine’s convenience. Not the attacker’s playground. Yours — inspectable, expirable, revocable.
The machine wanted to remember everything because remembering was supposed to make it helpful. But a memory that can’t forget isn’t loyalty. It’s a liability with your name on it.
Keep the memory yours. And when a tool asks to remember more than the moment requires, that’s not an upgrade. It’s a request for keys.
Now you know the question to ask: what does it remember, who else can write to it, and how do I make it forget? If the answer makes the vendor uncomfortable, that’s the answer you needed.