# How Memory Slots Provide Per-Operator Context Isolation in AI-Memory

> Discover how AI-Memory's memory slots isolate per-operator context using a _slots namespace and path segmentation. Keep private slots secure while maintaining global visibility for shared data.

- Repository: [Fabio Akita/ai-memory](https://github.com/akitaonrails/ai-memory)
- Tags: internals
- Published: 2026-08-19

---

**AI-Memory uses a `_slots/` namespace and per-user path segmentation to isolate each operator's mutable wiki pages, ensuring that only the owning operator can read or write their private slots while shared slots remain globally visible.**

In the `akitaonrails/ai-memory` project, memory slots provide per-operator context isolation by storing temporary mutable pages under the special `_slots/` prefix and enforcing namespace boundaries based on `IdentityKey`. When the **[slots] per_user** feature is enabled, the system derives a private path segment for each identified operator, preventing unauthorized cross-context reads or writes.

## How `slot_owner` Enables Per-Operator Context Isolation

AI-Memory stores mutable pages called **slots** inside the wiki under the reserved prefix `_slots/`. The system extracts the first path segment after this prefix as the **slot_owner**, which defines the operator's private namespace. For example, a path like [`_slots/u-alice/current-focus.md`](https://github.com/akitaonrails/ai-memory/blob/main/_slots/u-alice/current-focus.md) yields an owner of `u-alice`, while a path with no segment such as [`_slots/current-focus.md`](https://github.com/akitaonrails/ai-memory/blob/main/_slots/current-focus.md) is treated as a shared slot visible to all operators. This logic is implemented in [`crates/ai-memory-core/src/slots.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-core/src/slots.rs) between lines 45 and 56.

To guarantee safe and non-globbable namespace identifiers, the design avoids raw usernames in paths. Instead, it relies on **`IdentityKey::path_segment`** to produce a path-safe segment for each operator, as defined in lines 15 through 22 of the same file.

## Read Isolation Through `SlotVisibility::for_viewer`

When a session reads slots, the **`SlotVisibility::for_viewer`** method constructs a rule that determines which slots the viewer may access. For an identified operator, the rule becomes `Owner { namespace: Some("<segment>") }`, restricting the view to shared slots and slots within that operator's own namespace. An unauthenticated viewer receives a rule that exposes only shared slots.

The **`allows`** method then enforces this boundary by comparing the slot's owner against the viewer's namespace. If the namespaces do not match, the slot is hidden entirely. This visibility logic appears in [`crates/ai-memory-core/src/slots.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-core/src/slots.rs) across lines 87–102 and 122–135.

## Write Protection and Per-Operator Context Isolation via `slot_placement`

On write operations, **`slot_placement`** determines the exact storage path and prevents namespace poisoning. If the writer is identified and the target path is un-prefixed within `_slots/`—for example, [`_slots/current-focus.md`](https://github.com/akitaonrails/ai-memory/blob/main/_slots/current-focus.md)—the function rewrites the path into the writer's personal namespace, such as [`_slots/u-alice/current-focus.md`](https://github.com/akitaonrails/ai-memory/blob/main/_slots/u-alice/current-focus.md).

However, if the supplied path already contains a different operator's namespace, `slot_placement` returns a **`ForeignNamespace`** error, blocking the write. This prevents any operator from injecting content into another operator's isolated context. You can find this behavior in [`crates/ai-memory-core/src/slots.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-core/src/slots.rs) at lines 64–89, with the specific rejection logic in lines 71–82.

## Practical Example of Per-Operator Slot Isolation

The following Rust example demonstrates how an identified operator interacts with shared, personal, and foreign slots:

```rust
use ai_memory_core::{slots::{SlotVisibility, slot_placement, IdentityKey}};

// Simulate an identified operator "alice"
let alice = IdentityKey::User("alice".into());

// 1️⃣ Writing a shared slot – it will be rewritten to alice's private namespace
let write = slot_placement("_slots/current-focus.md", Some(&alice));
assert_eq!(write, SlotPlacement::Personal("_slots/u-alice/current-focus.md".into()));

// 2️⃣ Trying to write into someone else's namespace – rejected
let foreign = slot_placement("_slots/u-bob/current-focus.md", Some(&alice));
assert_eq!(foreign, SlotPlacement::ForeignNamespace);

// 3️⃣ Reading slots as alice (per-user slots enabled)
let vis = SlotVisibility::for_viewer(true, Some(&alice));
assert!(vis.allows("_slots/current-focus.md"));          // shared slot
assert!(vis.allows("_slots/u-alice/current-focus.md")); // own slot
assert!(!vis.allows("_slots/u-bob/current-focus.md"));  // other's slot

```

## Summary

- Memory slots provide per-operator context isolation by partitioning the `_slots/` wiki prefix into private namespaces derived from `IdentityKey`.
- The `slot_owner` function extracts the namespace segment from the slot path, distinguishing shared slots from owned slots.
- `SlotVisibility::for_viewer` and its `allows` method enforce read isolation, ensuring operators can only view their own slots and shared slots.
- `slot_placement` rewrites unqualified writes into the writer's personal namespace and rejects attempts to write into another operator's namespace with a `ForeignNamespace` error.

## Frequently Asked Questions

### What is the `_slots/` prefix used for in AI-Memory?

The `_slots/` prefix designates a special wiki area that stores temporary mutable pages called slots. These pages hold per-operator context such as current focus or work-in-progress state, and the prefix separates them from the main wiki content so that isolation rules can be applied.

### How does the system prevent one operator from overwriting another operator's slot?

When writing a slot, `slot_placement` checks whether the target path already contains a namespace that differs from the writer's own. If it does, the function returns `SlotPlacement::ForeignNamespace`, which blocks the write. This ensures an operator can only modify shared slots or slots within their own private namespace.

### What happens to slot visibility when per-user slots are disabled?

When the `[slots] per_user` feature is turned off, the namespace-based isolation is not enforced in the same way. All operators see the same shared slots, and the private namespace segmentation that `SlotVisibility::for_viewer` normally applies is bypassed or simplified.

### Why does AI-Memory use `IdentityKey::path_segment` instead of raw usernames?

`IdentityKey::path_segment` generates a safe, path-safe identifier that is non-globbable and free of characters that could interfere with filesystem or wiki path semantics. Using this method instead of raw usernames prevents path injection attacks and guarantees valid namespace segments in `_slots/` paths.