MnemoverseDocs

Appearance

One API key for many people ​

The short version ​

A key has no scopes and no expiry. It reads and writes the whole memory of the account it was created in, and it gets every tool. When an admin enters one key in a tool that many people use, all of them work in that one memory, whoever is talking to the agent. The tools that read can return anything stored in that account to any of them.

A key cannot be limited to reading. The controls are in the host: switch off the tools that change data, or do not share the connection. If each person should have their own memory, give each person their own connection.

Who ends up sharing a key ​

A key is shared when an admin or a builder enters it once and many people or callers use it. Some hosts do this by default, and some only after a setting. For example:

If each person signs in to Mnemoverse in the browser in their own connection, that connection belongs to the account that completed the sign-in. On a host that shares one person's connection with others, as Lindy does for a workspace, the shared connection still acts as that one account, as a shared key does. The sign-in works only on the hosts listed in Remote MCP Server.

What everyone sharing the key can do ​

Everyone who uses the key can write and rate memories in the account's own memory and in rooms where the account is a read_write member, and can create, invite to and join rooms: memory_write, memory_feedback, memory_create_room, memory_invite_to_room and memory_join_room. These are the tools that change data. A rating changes what comes back next, so one person's feedback changes the results for the others.

Everyone can also read. memory_read finds what matches a query. memory_list_recent lists the newest memories without a query. memory_stats shows counts and the names of the account's domains. memory_graph shows the links between concepts. memory_list_rooms lists the rooms the account belongs to. vault_list shows the names of stored secrets, never their values. The tools are listed on MCP Server, and Where each tool works says where a host offers fewer.

A domain is a label inside one account, not an access boundary. The key can read and write every domain of its account, and that includes the memory of whoever created the key. It also reaches every room the account belongs to, when the room's address is given as the domain, with the scope of the account's membership: where the account is a read-only member it can read, and writes and ratings are refused.

What they share besides the memory ​

All API keys of an organization share the same limits, so everyone on a shared key shares them with each other and with the owner's other keys, and one person's heavy use counts against all. The daily total counts reads, writes and feedback together. Over the stored-memory limit and past its grace period, writes are refused while reads keep working. The figures for each plan are on Pricing and the enforcement is described on Security.

The risks ​

  • Everyone sees everything in the account: the key owner's own memory, the contents of rooms the account belongs to, the domain names and the names of stored secrets.
  • Everyone can change it, if the tools that change data are on. One person's wrong or careless entry is then in the memory everyone reads.
  • An agent that members of the public talk to can leak stored content to any caller, because the reading tools answer the agent and the agent answers the caller.
  • A host's guardrails or approval mode may not cover reads. Lindy says reads are never guarded.
  • Some hosts import every tool and cannot switch them off one by one. Vapi is one.
  • The owner of the key answers for what is done with it. Section 3 of the Terms of Service says: "Do not share a key outside the people and systems you trust with your account." and "You are responsible for activity under your account and API keys, including activity by the agents and clients you connect, until you revoke a key you know has been exposed."
  • A key is a secret. Treat it like a password and keep it in the host's secret store.

Choose a setup ​

The options are in order of how much separation they give.

SetupWhat it givesWhen it fits
Each person has their own connection: their own key, or their own sign-in on the hosts that allow itEach person works in their own memoryMemory that belongs to a person. Relevance AI per-user connection, LibreChat with a key per user and Microsoft Copilot Studio by default work this way
Each person has their own account, and the team shares through a roomA separate bucket; nothing private is shared by joining, and a member can be given read onlyA team that wants one shared pool next to private memory
A builder keeps one key on a server and sets a domain for each end user from the signed-in userSeparates how memory is used, not accessAn app with many end users. See Conversational Agent
One shared keyEveryone in one memory with one set of limitsA memory the team is meant to share

Set up a shared key sensibly ​

  1. Decide what the key should reach. A key reaches everything in its account, so a shared memory that should hold only what the team is meant to share needs a key from an account that holds nothing else.
  2. Create the key for this connection alone, on the API Keys page of the console, and keep it only in the host's secret store.
  3. Switch off in the host the tools that change data, unless every member should change the memory. The switch is in the host, because a key cannot be limited to reading. Where a host cannot switch tools off one by one, as in Vapi, attach the memory only to assistants whose callers may read and change it.
  4. Do not rely on a host's guardrails for reads.
  5. Attach the memory only to agents and apps whose users may see the whole account.
  6. If you build the app yourself, keep the key on a server you control and set any per-user domain there, never from model output or client input.

Revoking and replacing a key ​

Revoking the key in the console stops its memory calls at once; Remote MCP Server says how soon the hosted server stops accepting it. For a shared key this cuts off everyone who uses it. Replacing a key means entering the new one in every system that used the old one. A revoked key will not work again, and a lost key cannot be shown again, so create a new one. Resetting a password, with or without disconnecting connected apps, does not revoke API keys.