macOS daemons build a personal graph that scores who is family, 8rank.ai says

Security researchers at 8rank.ai published an analysis of what they describe as a pair of daemons that ship on every Mac since macOS 13 (2022). By their account, the daemons exist to build a graph about the user: who you are, who you know, how those people relate to you and to each other, how you communicate with them, where you go and what you do and when. The graph is built on the device by cross-referencing Contacts, Calendar, Photos, Messages, Mail, location, Screen Time and a long tail of behavioral signals. The authors add, with the hedge "allegedly", that it is held as a queryable store that LLMs retrieve from. They say documentation is thin: the closest thing to an official description is the man page for knowledgeconstructiond (man 8 knowledgeconstructiond). Apple's own researchers published a paper on the techniques behind the graph construction in 2023, but the authors say there is next to nothing on how it is integrated into macOS, what exactly is collected and inferred, or the "kinship" inference the post focuses on. Everything in the post was collected on macOS 26 (26.6.2 at the time of writing). The authors came across the system during security research on the Apple Intelligence bundle in macOS 26 in August 2026. Nic Lydon had found the same database a few months earlier and written it up, and in September 2026 Alexis Brignoni taught the forensics tool iLEAPP to read the same store on iOS.
The daemons keep their work in ~/Library/IntelligencePlatform, a directory of fifty-one SQLite databases. They are stored in plaintext but sit in a zone protected by TCC Full Disk Access. The main one, graph.db, is a triple store (every row is a subject, a predicate and an object) with a vocabulary of 181 entity classes and 278 predicates. Into it go Contacts, faces from Photos, Calendar titles and attendees, Family Sharing (including the age of every member), the Medical ID emergency contact in Health, events and contacts that Siri Suggestions finds in Mail and Messages, people donated by apps through App Intents, and installed apps. Beside it, in separate tables, sit who appears with whom in your photos, a communication log (who, when, which app, which direction; no content) that also pulls from other devices, location and movement, and device signals such as screen lock, Wi-Fi, Bluetooth, charging and ambient light. One stream, ContextualUnderstanding.PhysicalSocial, has a record format listing people by name, phone and email with start and end times; it reads like a log of who was physically around you, but the authors never saw it filled in. Fifty-seven of the 181 entity classes describe an activity such as sleeping, exercising, commute or dining. The authors caution that some classes may be declared and never filled, and that their "implemented" flag is inference, not ground truth.
Most of the vocabulary is filled by plain copying and rules, but the interesting rows come from models. A pair of XGBoost classifiers decides who is family from 144 mostly behavioral features. Two embedding models are one of ten signals used to decide when two records are the same person. Twelve analyzers in Photos score partner, parent, child, coworker and friend from who appears in your pictures with you and on which trips and holidays. Apple's on-device LLM reads your messages to put a name and a relationship on a face, if Apple Intelligence is active. Every row lands in the graph with a confidence between 0 and 1. The two family models, EntityTagging_Family.mlmodelc and EntityTagging_FamilyAndFriends.mlmodelc, take 144 features and return a class and a probability. Their scores go into a separate table, entityTagging.db, with one row per person and seventeen relationship columns (from family to mother to coworker), recomputed every day. Only two of the seventeen columns have a shipped model behind them; the authors could not trace what fills the other fifteen, or how the probabilities become a graph confidence. The feature names sit in plain text in each model's metadata.json. The identity group (same surname, same home address, an iCloud Family flag) is the smaller part. The bulk is who you message and who appears in your photographs, conditioned on day of week and time of day, and then on both. One shipped feature is named photosPersonPosteriorProbabilityGivenSaturdayNight.
Deletion does not remove everything. The live graph forgets: delete a contact and nothing re-derives them, and the next run replaces the table wholesale. But a second table, expired_stable_graph, receives the retracted row and keeps its confidence and sources. How long it stays is unclear to the authors. It seems to go after about 48 hours, judging by a prune watermark and a recent snapshot, yet on the author's own Mac very old records were still readable. A conclusion can also outlive its evidence: on that Mac the scorecard still scored two people the graph had dropped the day before, both known to it only from a calendar invitation. The authors joke that anyone wanting a partner not to find deleted contacts should also drop rows from expired_stable_graph, which has to be done manually.
The authors stress that the store is not only about the Mac's user. Family and friends are in it too, none of them asked, and the store links them to the user and to each other through shared events and groups. By correlating across their own store, they say an LLM working for them could easily work out that there is a child in the household and roughly how old; which daycare the child attends and the numbers that reach it, copied from contact cards (though not the drop-off hour, since the calendar had no school-run event); where the family will be, on which days and between which hours; which family members will be there; and, from the same file, what is installed on the machine, down to the password manager. They call the store a "privacy single point of failure" and describe a hypothetical scenario with an abliterated LLM in a second write-up. They note the knowledge is meant to stay local, protected by Full Disk Access, though it can be consumed by other services, and it is not entirely clear to them how or what can be accessed. To let users look, they open-sourced a local dashboard called iKnow that reads the personal knowledge graph on a Mac, including the scorecard from entityTagging.db.
Key facts
- 8rank.ai says two daemons on every Mac since macOS 13 (2022) build an on-device graph of the user and the people around them from Contacts, Calendar, Photos, Messages, Mail, location and Screen Time.
- The data sits in fifty-one plaintext SQLite databases in ~/Library/IntelligencePlatform behind TCC Full Disk Access; graph.db is a triple store with 181 entity classes and 278 predicates.
- A pair of XGBoost classifiers decides who is family from 144 mostly behavioral features; one feature is named photosPersonPosteriorProbabilityGivenSaturdayNight.
- Deleted contacts move to an expired_stable_graph table that keeps confidence and sources; retention appears to be about 48 hours but old records were still readable on the author's Mac.
- The authors open-sourced iKnow, a local dashboard for reading your own graph; their findings come from macOS 26 (26.6.2) and several claims, such as LLM retrieval, are hedged by them.
Why it matters
The post describes a system with little public documentation: the only official description the authors found is a man page, plus a 2023 Apple research paper on the underlying techniques. If their account holds, the Mac keeps a structured, daily-updated model of the user's household, including inferred relationships such as family, partner, parent, child and coworker. The authors single out the family classifier's features, which lean heavily on who you message and who appears in your photos at which days and times, as the clearest statement of what the system is.
Who it affects
Mac users on macOS 13 or later, Intel and Apple silicon, according to the authors. They also stress the people around the user: family, friends and anyone the user has talked to through the device are in the store without having been asked, and the store links them to the user and to each other.
How to use it
The authors open-sourced iKnow, a local dashboard that reads the content of your own personal knowledge graph on your Mac, including the family scorecard from entityTagging.db. The databases live in ~/Library/IntelligencePlatform, and the man page is available with man 8 knowledgeconstructiond. The authors mention that rows in expired_stable_graph can be dropped manually; they present this half in jest and do not give a procedure in the visible text.
How solid is it
This is an independent investigation by a security team, not an Apple statement, and no Apple response appears in the text. The authors repeatedly mark their limits: the 'implemented' flag on entity classes is inference, some classes may be unused placeholders, they could not trace what fills fifteen of the seventeen relationship columns, and they say retention of expired rows is unclear. All findings were collected on macOS 26 (26.6.2). The claim that LLMs retrieve from the store carries the authors' own 'allegedly'. The authors are not named in the visible text, and the post is truncated before its end.
Risks and caveats
The main risk the authors raise is concentration: one store that correlates household, children, locations, schedules and installed apps becomes a single point of failure if it ends up in the wrong hands. They say the data is meant to stay local behind Full Disk Access but can be consumed by other services, and they do not know how or what can be accessed. Their misuse scenario is explicitly hypothetical. Deleting a contact does not clear everything, since a retracted row keeps its confidence and sources in expired_stable_graph, and a family score can outlive the graph entry it came from.
“photosPersonPosteriorProbabilityGivenSaturdayNight is a shipped feature name in a shipped classifier whose job is deciding whether someone is family.”
— 8rank.ai