In May 2026, a user on Microsoft’s own support forum reported that Copilot had spontaneously returned a block of their Edge tab metadata mid-conversation, tabs they had not mentioned, from a session they thought was closed. Microsoft’s public incident guidance never quite addressed why the assistant had that context sitting around to leak in the first place. For forensic examiners, the incident was more interesting for what it confirmed than for what it exposed: browser-integrated AI assistants are persistent, storage-backed subsystems, not stateless chat widgets bolted onto a toolbar, wired directly into the browser process, and they leave artifacts accordingly. Most browser forensic methodology, including a fair amount of tooling still in daily use, was written before this layer existed.

cover

In brief

  • Copilot in Edge and Gemini in Chrome persist conversational state and session context in IndexedDB, Service Worker caches, and browser-native SQLite/ESE databases, not just in cloud logs.
  • Edge’s legacy WebCacheV01.dat ESE database still captures HTTP-level traces of Copilot API calls even when the conversational content itself lives elsewhere.
  • Malicious AI-assistant browser extensions have been documented harvesting LLM chat histories directly from IndexedDB, confirming the attack surface is already being exploited, not just theorized.
  • Standard “clear browsing data” actions frequently leave IndexedDB leveldb fragments and cached model/session data recoverable through carving.
  • Correlating AI assistant activity requires cross-referencing at least four artifact classes: IndexedDB object stores, Service Worker script cache, browser history/network logs, and extension storage, since no single database holds the full picture.
  • Existing browser forensic suites (Hindsight, ArtiFast, browser-specific parsers) were largely designed before this AI layer existed and require manual extension to cover it properly.

Why AI Assistants Break the Traditional Browser Model

Traditional browser forensics rests on a stable mental model: history is in one SQLite database, cookies in another, cache in a fourth structure, and everything maps to a URL a user visited. Copilot in Edge and Gemini in Chrome break that model: they are first-party browser subsystems with privileged access to page content, tab state, and (in Copilot’s case) explicit “Actions” that let the assistant operate other tabs on the user’s behalf, not merely rendering a webpage the user navigated to.

Copilot Actions in Edge documents this directly: the assistant can read, summarize, or act on open tabs as part of its normal operation. For an examiner, conversational state does not stay inside a single “AI feature” bucket; it bleeds into session data, tab restore structures, and potentially the extension storage of anything with permission to interact with the assistant surface.

Academic researchers have started cataloguing these artifacts formally. A 2024 SSRN case study on conversational AI forensics across ChatGPT, Gemini, and Copilot noted in Conversational AI Forensics: A Case Study on ChatGPT, Gemini, and Copilot:

“For Windows 11, traces of Copilot usage can be found through Edge browser artifacts. The app data for Edge is located at %AppData%\Local...”

A reasonable start, but the actual artifact set runs much deeper. You quickly find data in places the paper does not discuss.

Where Copilot artifacts actually live in Edge

Edge is Chromium under the hood, which means the assistant’s local storage follows Chromium conventions layered on top of Edge-specific structures inherited from its Internet Explorer/Spartan lineage. The relevant paths on Windows: %LocalAppData%\Microsoft\Edge\User Data\Default\IndexedDB %LocalAppData%\Microsoft\Edge\User Data\Default\Service Worker\CacheStorage %LocalAppData%\Microsoft\Edge\User Data\Default\Local Storage\leveldb %LocalAppData%\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC…\WebCacheV01.dat

text

The IndexedDB directory stores conversation-adjacent data as LevelDB key-value stores, which means examiners need a LevelDB-aware parser, not a generic hex viewer, to get anything useful out of it. Each object store inside a given IndexedDB origin can hold session metadata, cached responses, and in some observed configurations, fragments of prompt/response pairs pending sync.

The WebCacheV01.dat ESE database predates Copilot entirely and still catches data that newer tooling overlooks. As documented in Microsoft Edge Forensics – Where to Find Artifacts?:

“The Edge browser stores data i.e. artefacts in the ESE database… The Container_n table in the history stores all these.”

Copilot’s backend calls traverse the same network stack as regular browsing, which means HTTP-level metadata about assistant API calls, timestamps, endpoint hosts, response sizes, ends up recorded in the Container_n tables of WebCacheV01.dat even when the conversational payload itself is encrypted or stored elsewhere. Investigators gain a fallback timeline even when the primary IndexedDB stores have been cleared or corrupted.

A practical extraction sequence using ESEDatabaseView or a Python ESE parser like python-ntfs/libesedb bindings:

import pyesedb

esedb = pyesedb.file()
esedb.open("WebCacheV01.dat")

table = esedb.get_table_by_name("Container_1")
for i in range(table.get_number_of_records()):
    record = table.get_record(i)
    url = record.get_value_data_as_string(2)
    if "copilot" in url.lower() or "sydney" in url.lower():
        print(record.get_value_data_as_string(0), url)

The sydney string check matters because Copilot’s internal codename still appears in some historical endpoint references, making it a useful keyword for triaging Edge network artifacts.

Where Gemini artifacts actually live in Chrome

Chrome’s implementation follows the same Chromium substrate but with Google-specific service worker registrations and a different IndexedDB origin structure tied to gemini.google.com and the in-browser side panel integration. Relevant paths: %LocalAppData%\Google\Chrome\User Data\Default\IndexedDB\https_gemini.google.com_0.indexeddb.leveldb %LocalAppData%\Google\Chrome\User Data\Default\Service Worker\ScriptCache %LocalAppData%\Google\Chrome\User Data\Default\Sync Data\LevelDB

text

The Sync Data LevelDB store is the artifact most examiners overlook. If the user is signed into Chrome with sync enabled, session and preference data related to Gemini interactions can be staged there before propagating to Google’s servers, giving you a local, pre-sync snapshot of state that may differ subtly from what a cloud-side legal request would return. Cross-jurisdiction cases often require reconciling local artifacts with cloud-obtained records, and the discrepancy between the two can be significant, a problem structurally similar to what I covered in cloud forensics and the jurisdictional labyrinth.

A basic LevelDB dump for triage, using the plyvel Python bindings:

import plyvel

db = plyvel.DB('/path/to/IndexedDB/https_gemini.google.com_0.indexeddb.leveldb', create_if_missing=False)
for key, value in db.iterator():
    if b'prompt' in value or b'response' in value:
        print(key, value[:200])
db.close()

Chromium’s IndexedDB LevelDB format wraps values in its own serialization envelope (a mix of IndexedDB blink-specific tags and V8 serialized objects). Raw string matching gives you a triage signal, but not a clean parse. Full reconstruction requires a proper IndexedDB deserializer; the Hindsight project’s architecture is a reasonable starting point to extend, even though it does not natively cover AI assistant object stores yet.

The Active Attack Surface of Browser AI Assistants

This artifact class is not hypothetical. Microsoft’s own security research team documented in Malicious AI Assistant Extensions Harvest LLM Chat Histories how malicious AI browser extensions harvest LLM chat histories from the browser storage layer:

“Malicious AI browser extensions collected LLM chat histories and browsing data from platforms such as ChatGPT and DeepSeek.”

Two points follow from this: the IndexedDB/Service Worker storage model for AI assistants is now stable and predictable enough to target reliably through extension-based malware, and any incident response involving a compromised browser extension should verify whether AI assistant storage fell within that extension’s declared permissions, alongside the usual cookies and history review. A third-party audit of a local-LLM browser extension reached a similar conclusion from the defensive side, explicitly cataloguing IndexedDB and Cache API usage as the expected, auditable storage surface for legitimate AI extensions in its NativeMind extension security report.

DFIR teams building extension-compromise playbooks should add IndexedDB origin enumeration and Service Worker cache inventory to the standard extension-scoping checklist, alongside the usual chrome.storage and cookie access review.

What Survives “Clear Browsing Data”

Chromium’s data-clearing routine does not delete IndexedDB LevelDB files atomically. It marks records for deletion and relies on LevelDB’s own compaction process to actually reclaim space, which means unallocated LevelDB blocks frequently contain recoverable fragments of “deleted” conversation data for a period after the user believes it is gone. The same applies to Service Worker script caches, which Chromium treats as a caching optimization rather than user data in some clearing flows, leaving cached assistant UI scripts and occasionally embedded response templates behind.

Session restore files add a second recovery path. If the browser crashes or is force-closed mid-conversation with Copilot or Gemini, the session restore mechanism (Edge’s Sessions/Tabs directories, Chrome’s equivalent Session Storage) can retain a snapshot of tab state that includes the assistant side panel’s last rendered content, independent of whatever cleanup ran on the primary storage.

This mirrors a pattern I have already documented in a different context: Windows 10 Timeline forensics showed years ago that Microsoft’s own activity-tracking databases were never designed with forensic purposes in mind, and that lack of intent is precisely what makes them valuable to investigators. The same holds here: neither Microsoft nor Google built Copilot’s IndexedDB storage with forensic intentions, and that is precisely why investigators find it useful.

Practical checklist for examiners

For any case involving suspected misuse of a browser AI assistant, whether data exfiltration through Copilot Actions, prompt injection via a compromised page, or a malicious extension harvesting chat history, the minimum artifact set to collect is:

  • Full IndexedDB directory for the relevant browser profile, parsed with a LevelDB-aware tool, not just string-searched.
  • Service Worker CacheStorage and ScriptCache contents, checked for residual assistant UI payloads.
  • WebCacheV01.dat (Edge) or equivalent network log correlation for HTTP-level assistant API call metadata.
  • Sync Data LevelDB store, if signed-in sync was active, cross-referenced against any cloud-obtained account data.
  • Installed extension manifests and their declared permissions, checked specifically against IndexedDB and storage API access scope.
  • Session restore and crash dump artifacts, which can retain assistant content independent of standard clearing routines.

Cloud-side legal requests for the assistant provider’s server-side logs remain the gold standard when that avenue is open. But when the device is in hand and provider cooperation is slow, uncertain, or blocked by jurisdictional barriers, these local artifacts are often the only evidence available, and most examiners do not yet know where to look.

FAQ

Where does Copilot in Edge store conversation data locally? Copilot conversation state and session metadata are cached primarily in the Edge profile’s IndexedDB and Service Worker storage under the WebStorage directory, with additional traces in the WebCacheV01.dat ESE database and in Edge’s own SQLite-based History and Sync databases.

Can AI browser assistant activity be recovered after cache clearing? Partially. Clearing browsing data through the standard UI often leaves IndexedDB leveldb fragments and Service Worker script caches intact due to how Chromium schedules deletion, and session restore files and crash dumps can retain prompt fragments even after a full cache clear.

Why do browser AI assistants complicate traditional browser forensics? Because they introduce a new data flow, the prompt/response pair, that does not map cleanly onto existing browser artifact categories like history or cookies, forcing examiners to correlate IndexedDB object stores, network fetch logs, and extension-level storage that most browser forensic tools were not built to parse.