Exploring Apple Intelligence Artifacts in iOS
In 2024, Apple introduced Apple Intelligence during Apple Worldwide Developers Conference 2024, describing it as a new AI system integrated into iOS, iPadOS, and macOS. This represented a progression beyond the capabilities previously associated with Siri, expanding the system’s ability to use contextual information from the device.
Apple states on its Apple Intelligence page that the system is “aware of your personal information without collecting your personal information.” With this in mind, I wanted to review artifacts in an iOS filesystem extraction to determine how Apple Intelligence data might be useful in an iOS forensic investigation.
I did not have a suitable dataset for testing until Magnet CTF 2026. I would like to thank Magnet Forensics for hosting the event and providing the data used in this research. I would also like to thank Jessica Hyde and her team for the tremendous work they put into creating the dataset and challenges.
As part of the CTF, an iPhone 15 full filesystem extraction was provided. The extraction contained artifacts related to the Apple Intelligence Platform (AIP). Artifacts associated with the AIP were located in:
/private/var/mobile/Library/IntelligencePlatform/
The dominant artifact format within this directory is SQLite databases, which appear to store data used by Apple Intelligence to build and maintain its internal knowledge.
I did not have a suitable dataset for testing until Magnet CTF 2026. I would like to thank Magnet Forensics for hosting the event and providing the data used in this research. I would also like to thank Jessica Hyde and her team for the tremendous work they put into creating the dataset and challenges.
As part of the CTF, an iPhone 15 full filesystem extraction was provided. The extraction contained artifacts related to the Apple Intelligence Platform (AIP). Artifacts associated with the AIP were located in:
/private/var/mobile/Library/IntelligencePlatform/
The dominant artifact format within this directory is SQLite databases, which appear to store data used by Apple Intelligence to build and maintain its internal knowledge.
Figure 1. Screenshots of the AIP directory and subdirectories (FTK Imager)
One of the first confirmations that Apple Intelligence references personal device information was found in graph.db. Within this database, the translated table contained entries representing a location labeled “home.” The entries included a full street address along with latitude and longitude coordinates. The final column in the table stores timestamps.
All entries in the translated table contained timestamps that were nearly identical, differing only by microseconds.
The most interesting table identified during the initial review was the stable_graph table within graph.db. This table contained more than one thousand entries and appears to store relationships between entities used by the AIP.
Sorting the table by the subject column grouped related entries together. One group referenced an entity labeled “SMS;-;6700.” This appears to represent an entity associated with SMS communication involving the phone number 6700. The actual message content was not recorded in AIP artifacts; however, evidence of the communication was present in sms.db.
As seen in Figure 4, the two entries highlighted in blue have predicate value of PS33. The meaning of this value is not recorded in the graph.db. I found the meaning of this predicate in the ontology.db database which can be found in the same directory as graph.db. The predicate table of the ontology.db database lists the label for PS33 as name.
Further review of the ontology database showed that it also contains the labels for many other predicate and relationshipPredicate values observed in the stable_graph table. This indicates that the ontology.db database serves as a reference for interpreting many of the coded values used by AIP when storing relationships within the graph.db database.
Figure 2. Screenshot of the translated table in graph.db (FQLite)
All entries in the translated table contained timestamps that were nearly identical, differing only by microseconds.
Figure 3. Screenshot of the timestamp column in the translated table in graph.db (FQLite)
The most interesting table identified during the initial review was the stable_graph table within graph.db. This table contained more than one thousand entries and appears to store relationships between entities used by the AIP.
Sorting the table by the subject column grouped related entries together. One group referenced an entity labeled “SMS;-;6700.” This appears to represent an entity associated with SMS communication involving the phone number 6700. The actual message content was not recorded in AIP artifacts; however, evidence of the communication was present in sms.db.
Figure 4. Screenshot of the stable_graph table in graph.db (FQLite)
Figure 5. Screenshot of SMS and iMessage communication (iLEAP)
As seen in Figure 4, the two entries highlighted in blue have predicate value of PS33. The meaning of this value is not recorded in the graph.db. I found the meaning of this predicate in the ontology.db database which can be found in the same directory as graph.db. The predicate table of the ontology.db database lists the label for PS33 as name.
Figure 6. Screenshot of the predicate table in ontology.db (FQLite)
Going back to the graph.db database, each unique subject in the stable_graph table has a unique timestamp associated with it; however, the timestamps does not correlate to the timestamps of the associated artifacts.
For instance, the SMS communication with 6700 occurred between 2025-11-04 17:19:08 and 2025-12-04 20:13:11. The timestamp recorded in the stable_graph for the “SMS;-;6700” entry was 2025-12-01 22:59:49, and did not match the timestamp of any of the messages exchanged with 6700. This further confirmed that timestamps stored in the stable_graph table does not appear to correspond directly to the time the underlying user activity occurred. Instead, it likely reflects the time the entries were inserted or updated within the graph.db.
Another example of user-related information present in the stable_graph table is contact information.
It is worth noting that the dataset for the CTF was created during November and December 2025. In real-world cases, where an iOS device has been used regularly for a longer period of time, I would expect to see a much larger volume of AIP data.
For instance, the SMS communication with 6700 occurred between 2025-11-04 17:19:08 and 2025-12-04 20:13:11. The timestamp recorded in the stable_graph for the “SMS;-;6700” entry was 2025-12-01 22:59:49, and did not match the timestamp of any of the messages exchanged with 6700. This further confirmed that timestamps stored in the stable_graph table does not appear to correspond directly to the time the underlying user activity occurred. Instead, it likely reflects the time the entries were inserted or updated within the graph.db.
Another example of user-related information present in the stable_graph table is contact information.
Figure 7. Screenshot showing contact information in the stable_graph table (FQLite)
It is worth noting that the dataset for the CTF was created during November and December 2025. In real-world cases, where an iOS device has been used regularly for a longer period of time, I would expect to see a much larger volume of AIP data.
A quick review of other AIP databases indicated that related or duplicate data may also be present in databases located within the Artifacts directory (see Figure 1). My next goal is to analyze these additional databases in greater depth and identify more artifacts that may provide forensic value during iOS investigations.