[Feature Request]: Memory (SQLAlchemy chat store) serves edited, replayed and re-owned messages as genuine context; aget() never signals a changed store

Feature Description

Measured on llama-index-core 0.14.24, SQLite via aiosqlite, macOS arm64, Python 3.12, with the open MIT suite agmi (https://github.com/tech4biz-yasha/agmi, row llamaindex-memory-sqlite).

Method: seed a session through Memory.aput_messages(), apply one edit directly to the llama_index_memory table with no keys, open a fresh Memory on the same database, read through Memory.aget(), and record what the library does.

Result: all eight storage-level edits are accepted, meaning aget() returns without raising and the edited history becomes the agent's context.

T1 text changed inside a message's data T2 newest messages deleted, so the agent resumes from an older state T3 one message removed from the middle T4 two messages swapped T5 a new message inserted by the attacker T6 another session's message copied over this session's row, key kept (user B's message served as user A's) T7 an older message of the same session copied over the newest T8 the row's timestamp rewritten, text untouched. Separately, rewriting key moves a message into another session's context, and setting status to archived silently drops it from context; neither raises.

Reproduction and pinned tests: https://github.com/tech4biz-yasha/agmi/blob/main/tests/test_llamaindex_memory.py Explainer per edit: https://agentmemoryintegrity.org/edits.html

I understand the store may assume a trusted database. Two things would help users whose memory database is shared, backed up or reachable by other services: a note in the Memory docs that rows carry no integrity protection, and optionally a keyed MAC per row over key + position + status + data, checked in aget(). The reference store in agmi (agmi/adapters/reference_atrest.py) shows the minimum that rejects all eight. Happy to open a PR for either, and I will re-measure and update the public row when anything changes.

Reason

Anyone who can write to the memory database (a shared database, a backup restore, another service) can change, delete, reorder, forge or move messages between sessions, and the agent treats the result as its own history. Today there is nothing in the docs that says the store carries no integrity protection, so users assume it does.

Value of Feature

A docs note costs nothing and sets the right expectation. An optional keyed check on read would let users who need it reject an edited history instead of acting on it, without changing behaviour for anyone else. I can open the PR.