Skip to content

Add an append-only audit log of memory operations #32

Description

@himanshu231204

Problem

There's no record of what an agent did. If a memory turns out to be wrong, or something was stored that shouldn't have been, there's no way to answer when did this get here, and what put it there.

For anyone using this in a work context, that question comes up eventually — and "we don't know" is a poor answer.

What to consider

An append-only audit_log table recording tool calls: operation, memory id, timestamp, and a caller identifier where available.

Acceptance criteria

  • Records store, update, and delete operations
  • Append-only in practice — the log isn't rewritten when a memory changes or is deleted
  • Survives deletion of the memory it references, otherwise it can't answer the question that matters most
  • Off by default, enabled by config
  • Queryable from the CLI, with tag/date filters
  • Bounded growth — retention, rotation, or a size cap. An unbounded log on a long-lived store is a slow leak
  • Tests including "memory deleted, log entry survives"
  • Documented, including in docs/guide/privacy.md

Why this needs discussion first

An audit log is a second copy of your memory content. If it stores content, deleting a memory no longer deletes the text — which directly contradicts "delete the file and the memory is gone" and complicates the privacy model this project sells.

Options:

  1. Metadata only — operation, id, timestamp, no content. Keeps the privacy story intact; answers "when did this change" but not "what did it say".
  2. Content included — genuinely useful for recovery, but needs its own deletion story and a clear note in the privacy docs.
  3. Configurable, defaulting to metadata-only.

I lean toward 3 with metadata-only as the default. But this is a real tension between two things the project claims — auditability and deletion actually deleting — and it should be settled here before code.

Also worth resolving: does MCP give us a usable caller identity? If every entry says "an agent did it", the log is much less useful, and that should shape whether it's worth building.

Pointers

  • src/localmem_mcp/store.py_SCHEMA
  • docs/guide/privacy.md — the claims this must not undermine

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: storageSQLite schema, persistence, migrationsenhancementNew feature or requestneeds discussionDirection isn't settled — comment before buildingv0.5: trustEncryption, audit log, provenance, no-network proof

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions