Policy

Security policy

eidetic-daemon reads user-private filesystem state (AI assistant session logs, editor history) and exposes it over a local socket. This document is the explicit threat model + reporting channel before W1 public release.

Reporting a vulnerability

Email: security@eidetic.works (or hi@eidetic.works as fallback)

Please include:

Response timeline:

Coordinated disclosure: please give us 30 days before public disclosure for high/critical issues. We’ll credit you in the fix release notes unless you prefer anonymity.

No bug bounty (yet) — we’re a 1-operator shop. We’ll consider a paid program once MRR supports it.

Scope

In scope:

Out of scope:

Threat model

Trust boundary

The daemon is a single-user, single-host process. Everything it reads, stores, and serves is private to the local user account.

The daemon does not authenticate callers. The Unix-domain socket is the trust boundary; filesystem permissions enforce it.

Storage

ItemPathModeNotes
SQLite store~/.eidetic/engrams.db0700 dir, 0600 filePlus WAL sidecars .db-wal, .db-shm — same modes
State offsets~/.eidetic/state.json0700 dir, 0600 fileAtomic-rename writes (state.json.tmp → state.json)
UDS listener/tmp/eidetic-daemon.sock (Mac) / /var/run/eidetic.sock (Linux)0600Daemon chmods after net.Listen
Logs (launchd)/tmp/eideticd.{out,err}.logOS defaultMay contain payload prefixes from parse-error paths — see Known limitations

EIDETIC_DATA_DIR overrides the data root; the daemon still creates parents at 0700.

Network exposure

Default: none. Daemon listens on a Unix-domain socket only.

Opt-in TCP: setting EIDETIC_TCP=1 makes the daemon listen on 127.0.0.1:9876. Loopback only — the listener does not bind to 0.0.0.0. There is no built-in authentication on the TCP path; treat EIDETIC_TCP=1 as “any local process can read every engram” and only enable it if you understand that.

Capture path

The daemon watches three default surface roots (paths shown for macOS):

Files are read with the daemon’s effective user, which means the daemon can read anything that user can read. There is no path-traversal protection on globs; configurations beyond DefaultSurfaces() are at the operator’s risk.

Parsers treat each newline-delimited record as opaque text. The daemon does not rewrite, exfiltrate, or upload captured content in W1. Cloud-sync is explicitly not in W1 scope (see docs/specs/eidetic-daemon-w1.md section 1; W2+).

What the daemon does NOT do

Known limitations (W1)

  1. Captured content may contain secrets. Claude Code session JSONLs and Cursor workspace storage can contain pasted API keys, passwords, file contents from secret-bearing files, etc. The daemon stores everything verbatim in engrams.db at 0600. There is no scrubbing, no allow/deny list, no per-record encryption. Treat ~/.eidetic/engrams.db as sensitive as your AI session history.
  2. No process isolation. The daemon runs as the user, with full filesystem access. A bug allowing path-injection into the parser configuration would let a caller read any user-readable file.
  3. No rate limiting on the API. A local process making a fast request loop will not be throttled. This is acceptable on the trust model (any caller already has same-uid privilege) but means the daemon cannot self-protect against a compromised co-resident process.
  4. launchd/systemd logs. When parsing fails, the parser logs capture: parse <surface> <path>: <error> to stderr, which goes to /tmp/eideticd.err.log (Mac) or systemd journal (Linux). The path is logged; the payload is not. Path itself may be sensitive depending on the user’s directory layout.
  5. No signing / verification on installer. curl -fsSL https://eidetic.works/install.sh | sh trusts TLS. Verify the binary’s GitHub release checksum against the source-built binary before relying on it for sensitive workflows.

Reporting a vulnerability

Email security@eidetic.works (route TBD; until then hello@nucleusos.dev). Please include:

We will acknowledge within 5 business days. There is no bug bounty in W1.

For non-sensitive issues, please open a GitHub issue.

Hardening for future releases (out of W1 scope)