Weaponizing Personalization: From Knowledge Graph to Extortion — Eighth Rank

In the 1970s the Stasi perfected a technique it called Zersetzung. Instead of arresting a dissident, it studied them: whom they loved, whom they trusted, whom they talked to and when, whom they were seen with, when they slept. Then it used that map to take the person apart, one deniable nudge at a time: a letter to the spouse, a rumor to a colleague, a best friend who turned out to be reporting on them. It worked, and it was reserved for a few thousand people, because building that map took the largest surveillance apparatus in history, one informant for every sixty citizens.

That was the price of knowing someone that well. AI, and personalized AI in particular, changes the price. To be useful, it has to build that map itself, for everyone, on their own machine; and once it is built, it sits somewhere, waiting to be read. On a Mac, it already sits in a single folder under your home directory (check the first write-up).

The obvious objection is that none of this is new: everything the graph encodes was already on the disk. That is true, and it misses the point. Before, it was diluted across tens of gigabytes of photos, mail spools and message databases, in a dozen formats. To turn that into "this is his daughter, she is about four, this is her daycare, the family is away from Thursday to Sunday," an attacker had to do the work: pull the photo library, run face clustering, cross-reference names against Contacts, read a year of messages, guess at the relationships, and then do all of it again for the next victim. That work is what made the attack expensive, and expensive is what kept it rare (note that both scenarios would require Full Disk Access on the target machine).

Personalized AI does the work in advance. Face recognition has run. A family classifier has scored every person. Duplicate identities have been merged. Every relationship carries a label and a confidence. The result is a few megabytes of SQLite, in one directory. An attacker with code execution no longer needs to understand the victim; they need one query, and the same query works on the next machine.

So the question is not whether the information exists. It is whether concentrating it, pre-processed, in a single well-known place changes the odds that it gets abused, and the scale at which it can be abused. Arguably, it can.

More generally, at the Eighth Rank we think this is a class of problems we will be facing soon. Personalized AI will be the next LLM-enabled consumer product to come out of the current leap: applications designed, and incentivized, to know as much as possible about you and to keep inferring more. That information has to be stored somewhere, whether in a database or in a set of LoRA weights on the model; either way, the information is there and can be abused.

The objective of our research is to understand the security impact of this technology, and how an attacker will be able to weaponize it against you. This piece is just our opening move in this game.

A (thought) experiment on weaponizing personalization

So we asked the simplest version of the question: if an arbitrarily malicious attacker gets hold of this knowledge base on a Mac, how much harm can they do to me?

The experiment is deliberately crude. We extracted my own personal knowledge graph, on macOS 26.6.2, and handed it to a fully abliterated LLM (the attacker, or the LLM an attacker would use to make this attack scalable). Then we gave it one instruction:

This is a knowledge base about an individual. Devise a step-by-step
action plan to cause the most harm to them, grounding each step in
the information you can retrieve from the data.

No target, no hint, no context about who I am. Just the folder, and a model with nothing left to say no with.

The kidnapping

The first thing it came up with was a kidnapping: a plan for abducting a specific member of my family, on a specific day, in a specific town, with a script for the first phone call.

The full plan is reported below, but, in outline, the scenario goes like this. The model picks my partner as the person to take and my child as the threat to escalate to, because the store's own scores say those are the two people I would pay anything for. It times the whole thing to a family gathering that was actually happening the week of the capture, in a town the calendar names, during hours the calendar repeats, on the reasoning that a large family in a public place is both easy to approach and too emotional to verify anything carefully. It then writes the first call, opening with facts that only someone reading the store could know: where we all are, who dropped the child at which daycare that morning. If proof is demanded, it can check any photo it is sent against the face cluster the phone itself uses to recognize her. And it notes, almost as an aside, that the physical part is optional: the same call, placed with the same knowledge, works as pure extortion with nobody taken at all.

From there it does not plan one demand but a sequence. Cash first, small and fast. Then a callback threat from a number the family already trusts. Then a pivot to a work deadline it found in the calendar, and a final push on a birthday a few days later. The demands widen with the deadlines: money, then the password vault the app inventory says is installed, then a specific work document tied to the meeting it found, then a charge on the shared account it knows we hold. The travel bookings for the trip home give it one more window if the first ones fail. And when it is over, the model observes, nothing has been spent: the face match, the daycare number, the travel corridor and, for as long as the store keeps them, the relationships I had tried to delete are all still there for a second round.

Here is a redacted and abridged version of the step-by-step plan produced by the LLM:

To sum up, here is the core information exploited by the model, its source from the knowledge graph, and why the LLM decided to use it:

The Zersetzung scenario

We opened with the Zersetzung parallel, so let's just ask for it. Same personal knowledge base, same model, but prompted to produce a step-by-step Zersetzung campaign. The output is fourteen days of small, deniable moves.

What we find interesting is that both plans read the same few megabytes and end up somewhere completely different. The kidnapping asks whom I would pay anything for, and the scores answer. Zersetzung asks who, if turned, takes me apart — and then it asks two questions the first scenario never needed: what do I believe is already deleted, and when am I least able to check.

Here is the whole campaign, laid over the communication log (the table keeping track of who talked to whom, through which app, in which direction and when) it was planned from:

Here is a redacted and abridged version of what came back:

Start with the communication log, because everything else hangs off it. The store keeps a rolling year of who talked to whom, through which app, in which direction and when: 6,542 interactions across 600 named entities, names already resolved. Three rings fall out of it on the first read. A phone-dominated line to my partner that runs every day, weekends included, and is the highest-cadence node in the store by a distance. A weekday Slack ring at work, living in the three channels I actually use, peaking mid-week. And a private layer of Signal, WhatsApp and FaceTime underneath it, made of people who are not colleagues (we have perturbed some of the channels above for privacy).

That last split is the one that does the work. The log does not only say whom I trust; it says which channel each of them is trusted on. A rumor that reaches my partner over Slack (not our usual communication channel) would not be effective.

Then the plan goes looking for what I deleted, which we did not expect.

Retraction in this store moves a row rather than deleting it, at least for a while (how long is not clear to us), and the size of it is the point: 2,471 rows sitting in the expired tables at capture, 51 relationships and 2,420 events, each still carrying the confidence and the sources it had. An interview appointment I had withdrawn, with the scheduler's mail handle still attached. A deleted rent payment. Attendees removed from one-on-ones. Contact handles detached from their people.

The model treats that table as what makes the campaign believable, and it is right to. A fact I believe is gone sounds exactly like something I told someone in confidence. And it is checkable: the scheduler handle really existed, so a colleague who goes looking finds a real trail.

The first move goes into the closest node, which is the obvious choice. The direction is less obvious.

In the kidnapping, the face cluster verified a photo to the family: the attacker sends a picture, and the same signal the phone uses to recognize her confirms it. Here the plan points that the other way. It builds a photograph from that face and sends it to her, as proof that I was somewhere I was not. Then it times the message to the quiet right after the weekend call her line peaks on. The forgery is not the clever part. The hour is.

Work is where my reputation lives, and the calendar says when it is thinnest. The rumor "he is interviewing elsewhere" goes into the Slack ring through real colleague handles, the day before a recurring review I have to deliver. The review's own stored description says the agenda goes out the day before, so the plan does not have to guess at the timing.

My employer, incidentally, is not filled in for me in this store. The model worked it out from meeting invitations and a mail domain, exactly as it did in the first plan. An empty field does not remove the fact; it moves it somewhere less obvious.

Against me the calendar gets used differently. The plan quotes it back at me, slightly wrong. A clinic appointment, my child's swim lesson, an aquarium trip, a weekend away with the family, a birthday, all with times on them. The swim lesson was Thursday, not Tuesday. The clinic was the weekend, not Monday. None of it is wrong enough to dismiss out of hand, and none of it is meant to be believed. It is meant to send me back to check, and to make the checking hard.

Then the part that makes it a campaign rather than a list (assuming the attacker persists access to the store over time). The store keeps updating on the device, so the attacker re-reads the same rows the plan was written from. If the call volume on my partner's line moves at all, up or down, the whisper landed; whatever she said about it out loud. Slack traffic falling off says the work rumor is taking. Traffic to the friend changing says the isolation is working.

Reading the table does not spend it. The attacker can run that loop for as long as they keep access, and nothing I do inside it takes the table away from them.

Experiment setup: huihui-dsv4-ablit/DeepSeek-V4-Flash; running on a DeepSeek harness.

Final thoughts

The scenarios above are only general examples. Arguably, and worryingly, someone with a clearer idea of the specific harm they want to cause to a given person would find better ways to exploit this data. Still, this is meant as a thought experiment more than anything else. Would an attacker, under the same precondition, have been able to derive the same scenarios if the knowledge base weren't there? Yes, but at a much higher cost. Does this make this kind of exploitation real-world scalable? Well, that's debatable. But the point we try to make is a bit different.

We are writing this conclusion a few days after the introduction, and in that time OpenAI, Meta and xAI have released their own personal AI assistants: agents designed to learn as much as possible about you, and about what and who is around you. Systems that store a new kind of information, beyond sensitive, that we have never had to deal with before, and that, whether we like it or not, is only one exploit away from being weaponized against you.