# How ai-memory Implements Multi-User Attribution and Team-Wide Knowledge Sharing

> ai-memory enables multi-user attribution and team-wide knowledge sharing by linking requests to user records, ensuring accountability in collaborative environments.

- Repository: [Fabio Akita/ai-memory](https://github.com/akitaonrails/ai-memory)
- Tags: how-to-guide
- Published: 2026-09-12

---

**`ai-memory` implements comprehensive multi-user attribution by associating every authenticated request with a persistent user record, stamping each write operation—from wiki pages to audit logs—with the originating user ID to enable full accountability in collaborative team environments.**

The `akitaonrails/ai-memory` repository provides a Rust-based knowledge management system designed for collaborative workflows. This article examines how the codebase implements **multi-user attribution and team-wide knowledge sharing** through database schema design, session management, and API-level identity propagation.

## Architectural Foundation for Multi-User Attribution

The attribution system rests on a dedicated authentication layer introduced in database migration V14. Every piece of data written to the system carries an identity marker, enabling teams to track contributions and maintain audit trails.

### The Users Table and Authentication

The foundation begins with the `users` table created in migration V14 ([`crates/ai-memory-store/migrations/V14__users.sql`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-store/migrations/V14__users.sql)). This table stores credentials and identity metadata, supporting multiple authentication methods including bearer tokens, API keys, and password-based sessions.

When a user authenticates, the system resolves the credential to a `UserId` that persists throughout the session. This identifier becomes the attribution key for all subsequent operations.

### Wiki Page Attribution

In [`crates/ai-memory-wiki/src/wiki.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-wiki/src/wiki.rs), the write path explicitly handles user attribution. The code contains a comment marking "Multi-user attribution (P1.6)" around lines 2060-2090, where the system stamps either `last_modified_by` or `author_id` columns during page creation and edits.

The migration V15 ([`V15__pages_author_id.sql`](https://github.com/akitaonrails/ai-memory/blob/main/V15__pages_author_id.sql)) added the `author_id` column to the pages table with an `ON DELETE SET NULL` constraint. This ensures that historical contributions remain recorded even if a user account is later removed, preserving the knowledge history without breaking referential integrity.

### Tamper-Evident Audit Logging

Every mutation generates an audit entry via migration V16 ([`V16__audit_log_author_id.sql`](https://github.com/akitaonrails/ai-memory/blob/main/V16__audit_log_author_id.sql)). These entries carry the `author_id` alongside operation metadata, creating an immutable history of who performed each action. This satisfies compliance requirements for teams needing to track changes to critical documentation.

### Core Actor Propagation

The attribution key flows through the system via [`crates/ai-memory-core/src/actor.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-core/src/actor.rs) (lines 50-60). The core actor propagates the user identity through write commands, ensuring that observations, handoff events, and auto-improvement decisions maintain their link to the originating user across asynchronous operations.

## Team-Wide Knowledge Sharing Mechanics

While attribution tracks individual contributions, the sharing model enables collective access to institutional knowledge.

### Shared Markdown Store

The wiki operates as a shared markdown store where all authenticated users access the same page namespace. Each page carries front-matter metadata including the `author_id`, allowing the UI to render attribution strings like "last modified by Alice" and enabling query filters such as "show only pages edited by Bob."

### Session-Sticky Attribution Model

Attribution is **session-sticky**: once authenticated, all events in a session inherit the same user identity unless explicitly overridden. The CLI supports the `--as-user` flag (implemented in [`crates/ai-memory-cli/src/commands/install_hooks.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-cli/src/commands/install_hooks.rs), lines 360-380) for administrative impersonation or service account operations, while the web API defaults to the authenticated session identity.

### API-Level Visibility Controls

The web layer in [`crates/ai-memory-web/src/routes/api.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-web/src/routes/api.rs) (lines 1240-1250) handles attribution visibility. Authenticated requests receive full attribution metadata in responses, while anonymous callers receive sanitized responses with hidden identity fields. This allows public read access where configured while maintaining internal accountability.

## Practical Implementation Examples

### Creating Users and Writing Pages

Configure multi-user mode in your [`.ai-memory.toml`](https://github.com/akitaonrails/ai-memory/blob/main/.ai-memory.toml):

```toml
[auth]
root_username = "admin"
bearer_token = "s3cr3t-root-token"

```

Create users via the CLI:

```bash
ai-memory user add --email bob@example.com

```

Write pages with explicit attribution:

```bash
ai-memory write-page --path notes/todo.md --as-user $USER_ID

```

### HTTP API Usage

Authenticated HTTP requests automatically capture user attribution:

```http
POST /api/v1/wiki/write
Authorization: Bearer <user-token>
Content-Type: application/json

{
  "path": "project/overview.md",
  "content": "# Project Overview\nTeam knowledge base entry..."

}

```

The server extracts the bearer token, resolves it to a `UserId`, and stamps both the page record and the corresponding audit log entry.

### Programmatic User Creation

For embedded deployments, create users programmatically:

```rust
// Example: creating a new user
let user_id = ai_memory::store::create_user("alice@example.com", "secure-password")?;

```

## Summary

- **Database-level attribution**: Migration V14 introduced the `users` table, while V15 and V16 added `author_id` columns to pages and audit logs respectively.
- **Immutable history**: The `ON DELETE SET NULL` constraint preserves page history even when users depart.
- **Session propagation**: The core actor in [`crates/ai-memory-core/src/actor.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-core/src/actor.rs) ensures user identity flows through all write operations.
- **Flexible authentication**: Supports bearer tokens, API keys, and password sessions with a four-rung privilege ladder.
- **Collaborative visibility**: Shared wiki storage with per-user filtering and optional anonymity for public endpoints.

## Frequently Asked Questions

### How does ai-memory handle attribution when a user leaves the organization?

The system uses `ON DELETE SET NULL` constraints on the `author_id` foreign keys. When a user account is deleted, the attribution column on existing pages and logs is set to NULL rather than cascading the deletion. This preserves the historical record of edits while removing the user identity, maintaining knowledge continuity without orphaned references.

### Can multiple users edit the same page simultaneously?

The [`crates/ai-memory-wiki/src/wiki.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-wiki/src/wiki.rs) implementation stamps `last_modified_by` on each write operation. While the source analysis does not indicate real-time collaborative editing (like operational transformation), the system records sequential edits with individual attribution. Teams should coordinate edits through the CLI or API to avoid overwrites, with the audit log providing a complete history of who made which changes.

### What authentication methods does ai-memory support for multi-user environments?

According to the source code and configuration schema, ai-memory implements a four-rung bearer ladder supporting root tokens, database users, human login sessions, and API keys. The [`crates/ai-memory-web/src/routes/api.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-web/src/routes/api.rs) handles bearer token extraction, while [`crates/ai-memory-cli/src/commands/install_hooks.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-cli/src/commands/install_hooks.rs) supports the `--as-user` flag for explicit identity assertion in scripted workflows.

### Is user attribution visible in the web interface?

Yes. For authenticated users, the API endpoints return full attribution metadata including `author_id` and `last_modified_by` fields. The UI can render this as human-readable strings (e.g., "Last modified by Alice"). For anonymous or unauthenticated requests, the system optionally hides attribution details while still returning the content, enabling public knowledge bases with private accountability trails.