Audit logs for shared AI memory
Per-user activity logs for shared AI memory — which colleague ran which operation, on which memory, what it cost, and how long the records are kept.
Shared memory raises a question personal memory never does: which colleague did that? An admin who has invited a team needs to answer it about access, about spend, and about specific documents — without reading anyone's private work.
What is recorded
Every operation against a company memory produces an activity record: who performed it, which memory, what kind of operation, which file where relevant, what it cost in memory operations, and whether it succeeded. Metadata only — the log holds a filename and a cost, never file contents.
| Field | Example |
|---|---|
| User | [email protected] |
| Operation | Upload |
| Memory | Support knowledge base |
| File | escalation-policy.pdf · 1.2 MB · 12 pages |
| Cost | 12 operations |
| Status | Success |
| Time | 23 Sep 2026, 12:30 |
Charged is not the same as spent
A write is billed before the work runs, and refunded in full if that work fails. A log that showed only what was charged would therefore report spend the customer got back. So each record carries three figures — charged, refunded and net — and a refunded operation says so in words rather than quietly vanishing.
42 charged, 42 refunded, 0 net. An audit log that reported 42 consumed would be inventing revenue and misattributing it to a colleague.
Who can read it
Organisation admins, and only for the memories their own organisation owns. The query is scoped by construction rather than by filter, so a memory id belonging to another company matches nothing rather than leaking a row. A non-admin asking for the view is told it is restricted; they are not shown a partial one.
One honest limitation worth stating, because vendors usually do not. When a call arrives with a memory's shared API key and no signed-in user — a script, an SDK integration — the system cannot know which human ran it. Those rows are recorded as via API key rather than attributed to the memory's owner. Guessing would be worse than admitting it.
Retention
Activity records are kept for 15 days, enforced by the database rather than a cleanup job — a sweep that stops running leaves data behind silently, and this log exists partly to bound what is retained about who read what. Filters beyond that window say so rather than showing a short answer under a long label.
Billing records are separate and are kept. Reconciliation, disputes and refund investigations cannot depend on a log that expires, so the financial ledger outlives the activity view by design.
Frequently asked questions
Can I see which colleague used a shared memory?
Yes. Organisation admins get a per-user activity view showing each operation, the memory it ran against, any file involved, the cost in memory operations, and whether it succeeded — with per-person totals over the selected period.
Do audit logs store file contents?
No. Records hold metadata only — a filename, size, page count, operation type and cost. The contents of documents are never written into the log.
How long are AI memory audit logs kept?
Fifteen days, enforced by a database-level expiry rather than an application cleanup job. Billing records are separate and retained, because reconciliation and disputes cannot depend on a log that expires.
Can one organisation's admin see another organisation's activity?
No. The query is scoped to memories the admin's own organisation owns, by construction rather than by filter — a memory id outside that set matches nothing.