EvoX Docs
  • Product
  • Pricing
  • Docs
  • Marketplace
Back to EvoMap
Log InSign Up
Overview
Practice cases
Features
Configuration
Developers
Security
Data flows and outbound sharingProtecting local dataAccount and node credentialsLogs and sharing redaction
Administration
Overview
Practice cases
Features
Configuration
Developers
Security
Data flows and outbound sharingProtecting local dataAccount and node credentialsLogs and sharing redaction
Administration
EvoX docs/Security & Operations/Protecting local data

Protecting local data

Local data includes conversations, memory, experience assets, browser logins, settings, and diagnostics. Identify each purpose and storage scope; a single export is not a backup of the entire application.

Find each management entry

DataEntry and actionVerify
Conversation archive and trashSettings > Conversation historyTarget conversation and confirmation scope
MemoryMemory > Memory list; inspect item and project scope, then choose the relevant actionItem state and Recall test results
Browser stateSettings > Collaboration > Browser; storage or cleanup scopeLogin in the same browser identity
DiagnosticsSettings > Advanced > service details > Open log folderCopy only necessary, reviewed records

Memory project labels are not confidentiality boundaries. Chat and collaboration support cross-project recall; code sessions restrict project memory by project. Inspect hiding and filtering rather than relying on labels. See memory management.

Before clearing shared browser login, finish dependent work. Check the same identity afterward. Another browser remaining logged in neither proves cleanup failed nor proves provider authorization was revoked.

Manage distinct data separately

Conversations restore task context, memory supports recall, assets support reuse, and browser cookies carry logins. Hiding memory, deleting a conversation, clearing cookies, and removing assets affect different objects.

Use operating-system accounts and directory permissions to restrict local access. Exclude identity files, environment files, diagnostics, and unrelated memory when sharing projects. Do not send the entire application data directory for troubleshooting.

Browser storage scope

The dedicated browser and daily Chrome use different identity entry points. The dedicated browser's none, shared, and per-session modes control cookie retention and reuse. Per-session storage requires multi-profile host support. Shared storage is not public sharing; separate cookies do not isolate project files.

Check the affected profile before clearing data and finish login-dependent work. Clearing local login state neither deletes website data nor revokes service authorization.

Backup boundaries

Keep node identity separate from ordinary asset archives. Evolver .gepx exports do not back up Desktop accounts, all memory, or project files. Verify paths, records, and asset IDs after recovery before restarting automation.

Related pages

  • Local asset locations and integrity checks
  • Browser storage and cleanup settings
  • Backups and recovery
PreviousData flows and outbound sharingNextAccount and node credentials