macOS Has Been Profiling Your Contacts and Routines Since 2022

⏱️ Reading time: 13 min

Since 2022, every Mac running macOS 13 or later has been running two background processes whose only job is to build a personal knowledge graph about you: who you talk to, where you go, who you live with, and when. Security researchers documented in October 2026 how this mechanism works under the hood, something Apple never explained in detail beyond a three-paragraph man page.

📑 En este artículo

1. TL;DR
2. What Is Apple’s Personal Knowledge Graph?
3. Why This Mechanism Matters
   1. What This Means for macOS Developers
4. How It Works Under the Hood
5. Practical Examples: Inspecting Your Own Graph
   1. Step 1: Confirm the Databases Exist
   2. Step 2: List graph.db’s Tables
   3. Step 3: Verify You Have Real Read Access
6. Use Cases and Risks: When the Graph Falls Into the Wrong Hands
7. Common Mistakes and Best Practices
8. Comparison With Other Personalization Approaches
9. Going Deeper: What Still Isn’t Documented
10. Frequently Asked Questions
    1. Can Apple’s Personal Knowledge Graph Be Fully Disabled?
    2. Does intelligenceplatformd Send Any of This Data to Apple’s Servers?
    3. Do I Need to Install Anything to See What graph.db Stores About Me?
    4. What Happens to graph.db When I Sell or Give Away My Mac?
    5. Do Windows or Linux Have an Equivalent to This On-Device Triple Store?
11. References

The finding matters because graph.db and its neighboring databases aren’t a lab experiment: they’re the memory Apple Intelligence uses to give Siri and other on-device features context, spread across 51 SQLite databases that any app with the right permission could read.

TL;DR

• knowledgeconstructiond and intelligenceplatformd run on macOS 13+ (2022) and write to ~/Library/IntelligencePlatform.
• graph.db is a triple store with 181 entity classes and 278 predicates that model relationships.
• Full Disk Access protects the folder, but sqlite3 can open it if you grant that permission to Terminal.
• The official man page (man 8 knowledgeconstructiond) is nearly the only public documentation of the mechanism.
• Apple Intelligence queries graph.db to give Siri personal context without leaving the device.

What Is Apple’s Personal Knowledge Graph?

The personal knowledge graph is the database macOS builds on every Mac to model the user and their environment: contacts, events, messages, locations, and usage patterns, automatically cross-referenced in a local triple store that feeds Apple Intelligence without leaving the device.

The simplest analogy is a private investigator’s corkboard, that board of photos connected with red strings marking who knows whom. macOS does something similar, but automatically: instead of strings it uses rows in a database, and instead of an investigator there are two system daemons, knowledgeconstructiond and intelligenceplatformd, which process every new contact, every message, and every visit to a place to decide which relationship best describes the people and places that appear in your life.

Why This Mechanism Matters

It matters because it’s a quiet shift in scope: Apple went from storing loose data, a contact list, a calendar, to maintaining an explicit network of personal relationships, with its own inferences about who your partner, your boss, or your doctor is. That leap never appeared in any press release or keynote.

The Apple Platform Security Guide describes dozens of data protection mechanisms in iOS and macOS, but doesn’t mention this on-device context database by name. The only public reference is the man page for knowledgeconstructiond, which says the daemon analyzes device content “to help build a general-purpose knowledge graph that represents the device and the user”.

What This Means for macOS Developers

If you’re building a macOS app and at some point ask the user for Full Disk Access or Automation permission, you’re asking for access to the same protected folder where macOS’s triple store lives, even if your app never touches it. Clearly explaining why you need that permission, instead of requesting it just in case, matters more every day: users in Latin America who are starting to understand what’s behind that dialog box will distrust an app that requests it without a visible justification in its flow.

For teams working with App Sandbox or Endpoint Security, it’s worth auditing what entitlements your own binary declares before publishing, with a command like codesign -d --entitlements - /path/to/your.app, to confirm you’re not carrying a broad permission you don’t actually use.

How It Works Under the Hood

The data comes from Contacts, Calendar, Photos, Messages, Mail, location, Screen Time, and a long list of behavioral signals. knowledgeconstructiond does the heavy analysis work; intelligenceplatformd coordinates the result and writes it to disk. This personal knowledge graph doesn’t live in the cloud: it lives locally, in ~/Library/IntelligencePlatform, a folder with 51 SQLite databases protected by TCC’s (Transparency, Consent and Control) Full Disk Access permission, the same system that asks whether an app can access your Photos or microphone.

flowchart TD
    A["Contacts, Calendar, Photos, Messages, and Mail"] --> B["knowledgeconstructiond"]
    C["Location, Screen Time, and usage signals"] --> B
    B --> D["intelligenceplatformd"]
    D --> E[("graph.db and the other 50 SQLite databases")]
    E --> F["Apple Intelligence and Siri"]

The most interesting of the 51 databases is graph.db, the triple store proper. A triple store stores each fact as three columns: subject, predicate, and object. For example, “me” is the subject, “employer” is the predicate, and an organization is the object. graph.db defines 181 entity classes (person, app, event, organization) and 278 distinct predicates that describe how those entities relate to each other.

There’s a design detail worth understanding because it explains why the schema is so large: a relationship like “employer” doesn’t point directly from subject to object. Instead, it creates an intermediate node representing the relationship type, and two rows share the same relationshipId: one row states what kind of bond it is (employment, family, friendship) and the other states which entity it points to. That indirection lets the system reclassify a relationship without rewriting the entire graph, useful when it infers that two contacts stopped being a couple.

flowchart LR
    S["Subject: me"] -- "PS500 employer" --> R{"Relationship node"}
    R -- "PS1 type" --> T["employment relationship"]
    R -- "PS45 member of" --> O["Organization: Company X"]

Each row in the triple store also stores its own metadata: a confidence value (how certain the inference is), a list of sources (which app the data came from), a sourceDuplicates counter, and a timestamp. This design is classic of probabilistic reasoning systems: the graph doesn’t assume an inference is true, it assigns a degree of certainty and revises it as new evidence arrives.

Practical Examples: Inspecting Your Own Graph

You don’t need third-party tools to see what your Mac stores. macOS ships with sqlite3 preinstalled, and the only extra requirement is granting Terminal Full Disk Access permission. These three steps build on each other: first you confirm the databases exist, then you list their tables, and finally you verify whether you actually have access.

Step 1: Confirm the Databases Exist

ls -la ~/Library/IntelligencePlatform/

This command lists the folder’s contents. If your Terminal doesn’t have Full Disk Access you’ll see Operation not permitted for each file; if it does, you’ll see several dozen .db files, including graph.db.

Step 2: List graph.db’s Tables

sqlite3 ~/Library/IntelligencePlatform/graph.db ".tables"

Apple doesn’t document the internal schema, so table names vary between macOS versions. Run .schema table_name on each result to see its actual columns on your machine.

Step 3: Verify You Have Real Read Access

sqlite3 ~/Library/IntelligencePlatform/graph.db "SELECT COUNT(*) FROM sqlite_master WHERE type='table';"

With Full Disk Access granted, this command returns a number: the total count of tables in the database. Without that permission you’ll see Error: unable to open database file, which is how TCC blocks access even before sqlite3 manages to open the file.

⚠️ Heads up: granting Terminal Full Disk Access gives it access to your entire user folder, not just IntelligencePlatform. Revoke the permission in System Settings once you’re done inspecting your graph.

Use Cases and Risks: When the Graph Falls Into the Wrong Hands

The use case that justifies all of this, from Apple’s perspective, is reasonable: Siri can tell you when your child’s next game is without any app having to send your contacts to a server. The problem appears when that same system, already resolved and structured, ends up in the hands of someone who isn’t its owner.

The scenario doesn’t require a sophisticated attacker. In cases of domestic abuse or devices shared within a family, physical access is already a given: someone with that closeness doesn’t need to steal the Mac, they just need a moment with an unlocked session and, eventually, the same Full Disk Access permission an advanced user grants to install a legitimate tool.

8rank poses a concrete thought experiment: if an attacker with physical or remote access to an unlocked Mac extracts graph.db and loads it as context for an LLM with no safety filters, what’s often called an “abliterated” model, they don’t need to manually reconstruct who the victim’s family is, where they live, or who they work with. The graph already did that work. What used to take hours of social engineering is now a single text query, because the system is, in effect, already a complete map of family ties.

sequenceDiagram
    participant A as Attacker
    participant M as Compromised Mac
    participant G as Graph database
    participant L as Unfiltered LLM
    A->>M: gains physical or remote access
    M->>G: inherits Full Disk Access permission
    G-->>A: exposes entities and relationships
    A->>L: loads the graph as context
    L-->>A: returns a profile of the victim and their environment
    Note over A,L: the attack doesn't break encryption, it abuses legitimate context

💭 Key point: the risk isn’t breaking disk encryption, it’s that an already-resolved graph turns hours of intelligence work into a single query to a language model.

FileVault, macOS’s disk encryption documented in Apple’s official security guide, doesn’t protect against this scenario: it encrypts data at rest, but while the session is unlocked it has already done its job and the file reads in plain text. The only active barrier in this case is TCC, and TCC depends on which apps you’ve already authorized, not on whether the session is open or locked.

Common Mistakes and Best Practices

• Confusing FileVault with in-use protection. FileVault encrypts the disk when it’s powered off; with the session open, any process with Full Disk Access reads the databases without asking for a password again.
• Not checking which apps already have Full Disk Access. Every app with that permission can read the same folder you inspected with sqlite3 in the previous section.
• Thinking that clearing Siri’s history clears the graph. Apple doesn’t document a single button to fully purge graph.db; turning off individual sources, like location or Screen Time, only stops future growth.
• Assuming a used Mac arrives “clean”. Migration Assistant can copy these databases from one machine to another; only a wipe with “Erase All Content and Settings” removes them with certainty.

The equivalent best practice is simple: check Settings > Privacy & Security > Full Disk Access every so often, and treat that permission with the same caution as an administrator password.

Comparison With Other Personalization Approaches

Going Deeper: What Still Isn’t Documented

Apple published a technical paper in 2023 on the techniques behind this graph construction, according to 8rank’s research; the full catalog of Apple Machine Learning Research publications is available on its official site. What that paper doesn’t cover is the actual integration into macOS: exactly which versions activate it, the complete inventory of the other 50 databases besides graph.db, and the family-relationship inference the system makes between contacts without the user ever declaring it explicitly.

That documentation gap isn’t new. Months before 8rank’s analysis, another independent researcher had found the same database while building his own personal notes system, and stumbled, without looking for it, onto the one Apple already had running on his laptop. The coincidence sums up the problem well: two different people, working separately, arrived at the same finding because there’s no official source to check first.

For anyone who wants to go beyond sqlite3, the 8rank team released a local dashboard called iKnow for browsing the graph without using the command line; you can track it down from the original article cited in References.

Your next step: grant Terminal Full Disk Access in System Settings and run sqlite3 ~/Library/IntelligencePlatform/graph.db ".tables" to see, with your own data, what tables exist in your graph right now.

Frequently Asked Questions

Can Apple’s Personal Knowledge Graph Be Fully Disabled?

Apple doesn’t offer a single switch. The closest thing is checking Settings > Privacy & Security and turning off specific data sources, like location or Screen Time, although that only stops new entries and doesn’t delete what’s already been inferred.

Does intelligenceplatformd Send Any of This Data to Apple’s Servers?

According to the official man page and 8rank’s analysis, the processing described happens on-device. Apple Intelligence uses Private Cloud Compute for tasks that exceed the device’s capacity, but that’s a separate mechanism from graph.db.

Do I Need to Install Anything to See What graph.db Stores About Me?

No. sqlite3 comes preinstalled on macOS; you just need to grant Terminal Full Disk Access, as shown in the practical section of this article.

What Happens to graph.db When I Sell or Give Away My Mac?

A factory wipe with “Erase All Content and Settings” removes the entire ~/Library folder, including IntelligencePlatform. Manually copying files or restoring from a backup without that step can leave the previous owner’s graph intact.

Do Windows or Linux Have an Equivalent to This On-Device Triple Store?

Neither officially maintains a local context database with this structure. Android personalizes assistants mainly through the Google cloud account, not with an equivalent local graph.

References

• 8rank.ai: original research on knowledgeconstructiond, intelligenceplatformd, and graph.db.
• Apple Platform Security Guide: official documentation of data protection mechanisms in macOS.
• SQLite CLI Documentation: reference for the sqlite3 command used to inspect the databases.
• Wikipedia: Triplestore: explanation of the subject-predicate-object data model.
• Apple Machine Learning Research: catalog of Apple’s technical publications, including the 2023 paper on graph construction.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Luke Chesser en Unsplash