Shared memory, with permissions

Most LLM memory is a private notebook: one person, one app, one model. An Ontonym memory is a shared graph — your team and every AI they use read and write the same structured knowledge — and sharing anything real needs real permissions. This page explains how they work. For connecting a client, see Connect your AI.

Why shared memory

Chat histories die with the chat, and per-app memories silo what a team knows into whichever tool each person happens to use. Ontonym keeps knowledge as a graph of typed objects — people, deals, decisions, events — that outlives any one conversation. Because it is one graph rather than everyone's private notes, the question “who may see what?” has to have a precise answer. Everything below is that answer.

Memories & organizations

  • A personal memory has exactly one reader: you. It cannot be shared — there are no members to manage and nothing here applies to it.
  • An organization is the directory: the set of people who can ever be granted anything. Being in the organization grants no access by itself— “works here” and “may read the board's memory” are different questions, kept deliberately separate.
  • A memory created in an organization belongs to the organization, whoever created it. Organization owners keep owner access to all of its memories, so a graph never leaves with a departing employee.

Roles

Each member holds one role per memory:

  • reader — sees the graph (subject to the visibility rules below), writes nothing.
  • writer — also ingests and edits: saving conversations, extracting, updating objects.
  • owner — also manages people, rules and settings, and can delete the memory. Owners are never restricted by any visibility rule.

Organization roles (member / admin / owner) are a separate scale about the container — inviting people, creating memories — not about reading any particular graph.

Visibility rules — who sees what, inside a memory

Roles decide what someone may do; visibility rules decide what they may see. Four layers, from broad to surgical:

  1. The default. Each memory chooses what a member with no specific rules sees: everything (right for most team memories) or nothing until granted— a legal or HR graph fails closed, so forgetting to restrict the eleventh member can't leak anything.
  2. Class & property grants. Limit a person or group to selected classes — and within a class, to selected properties. Sales sees Customers and Deals but not Salaries; recruiters see Candidates without the compensation column.
  3. Per-object rules. Hide one object (or one value on it) from named people, or restrict it to a named few. An allow on an object makes it visible only to those named; deny always wins over any allow, and object rules beat class grants in both directions.
  4. Groups. Access groups belong to the organization and work across every memory in it — grant Financeonce instead of five people five times, and new joiners inherit the group's access the day they're added.

Counts are corrected too: a class list never shows “Invoices (1,248)” to someone allowed to open 400 of them — publishing the size of what's withheld would answer a question they weren't supposed to be able to ask.

What your AI sees

This is the part that makes permissions mean something in an LLM-memory product: every read — the web app, the MCP tools your AI calls, even SQL composed by the chat agent — resolves through the same rules. An MCP key is scoped to the person who minted it, so their AI sees exactly what they see: same classes, same properties, same objects, nothing more. Keys are revocable at any time, and read-only keys exist for clients that should never write.

Previews, SSO & history

  • Check what someone sees. Layered rules interact, so the Access screen can run the real resolver for any member, group, or an outsider — and show the outcome: which classes, which properties withheld, which objects hidden. No more asking a colleague to log in and describe their screen.
  • Ask for access. A link into a private memory isn't a dead end: the visitor can request access, the owner approves or declines with a role, and both sides are notified.
  • SSO keeps it centrally managed. An organization can plug in its own identity provider (Entra ID, Okta, AD FS, Keycloak — plain OIDC). The IdP's groups map to organization roles and access groups on every sign-in; what SSO granted, SSO can take away, while anything an admin set by hand is left alone and labeled accordingly.
  • Access history. Every permission change — grants, role changes, request decisions, group edits, SSO syncs — is recorded with who did it and when, and shown to owners in the memory's and the organization's settings. Answering “why can she see this?” is a lookup, not an investigation.

Personal use is free without limits; a paid plan is what adds other people — the organization, the roles, and everything on this page. Start free.