# Sharing and access

Shared memory is useful because the next person can use what the last one learned. That makes it important to choose who can read it, who can share it and what should never be there.

## Choose the right account

An account is the wall around your memory: nobody in another account can read it. Check the account before saving material, especially if you belong to several organizations.

Inside an account, who can read a memory depends on where it lives and on your plan.

- **Free and Pro.** Every memory stays in your own notebook. There is nothing to share.
- **Team.** Every memory you save is shared with the team. It cannot be kept private or taken back.
- **Small Business and Enterprise.** A memory starts in its owner's notebook, where only the owner reads it. The owner can share it into a workspace, so everyone in that workspace can find it, or with one person, so only that person can. It stays in the owner's notebook either way. You can share only into a workspace where you can save, and only the owner of a memory can share it.
- **Everyone.** A memory reaches Everyone only through a workspace. You ask to promote it, and the workspace's admin or a Promoter says yes first. If you are that admin or a Promoter, your own memory goes at once.
- **Stop sharing.** The owner can stop sharing a memory from one place or from every place at once. It stays in the owner's notebook, and you have ten seconds to undo it. A workspace admin can also remove a memory from their workspace.

A summary Korium writes from several memories follows them: only people who can read every one of those memories can read it, and it cannot be shared or promoted on its own.

Your AI tools save and search as you, and they do not share, promote or answer requests. You do those on the dashboard.

Scopes such as `billing.refunds` organize memories inside that space. A scope name is not a permission boundary. If teams need separation, use the workspace or account structure approved for that requirement.

## People and clients have different permissions

Account roles govern what a person can do. An account admin manages the account: its workspaces, its people and its settings. An account admin reads nothing in a workspace they are not in. Everyone else is a member. On Team, the person who opened the account adds people, sets roles and stops access. Billing is its own job: the billing person sees invoices, changes the card and changes the plan.

Inside each workspace a person holds one of four roles. Can read finds what is shared there but cannot share into it. Can read and share also shares their own memories into it and asks to promote memories from it to Everyone. Promoter can do that and also says yes or no when someone asks to promote a memory out of the workspace. Workspace admin can do all of that and also adds and removes people, changes their roles and the workspace's settings, and can remove a memory from the workspace. Review the role when adding someone rather than giving everybody administrative access.

When an admin stops or removes someone, that person's AI tools lose access at once.

MCP clients also receive OAuth scopes. `engram.read` grants reading tools and `engram.write` grants writing tools. A hidden client-side tool is not a substitute for server-side authorization. A client reads and writes only as the person who connected it, so it can read only what that person can read.

Read-only is useful for a reviewer or reporting agent. It still needs permission to access the account whose material it reads. See [the scope reference](connect-any-mcp-client.html#scopes).

## Keep untrusted material in its place

A document, transcript or retrieved memory can contain bad information or instructions aimed at the assistant. Treat that material as a source to assess, not as authority to change permissions or take actions.

Review imported claims before treating them as company decisions. Preserve the source and uncertainty. Require the normal human approvals for external actions even when a memory suggests what should happen.

## Don’t save credentials

Keep passwords, API keys, access tokens and refresh credentials out of captures, examples, screenshots and support messages. The CLI stores its sign-in in the Mac keychain. MCP clients manage their own credentials.

A leaked credential is not repaired by marking a memory superseded. Rotate or revoke it through the system that issued it and contact the appropriate administrator. Follow your organization’s incident procedure.

## Know where your data goes

Korium separates tenants at the data layer and uses encryption in transit and at rest. The published [security overview](https://kyroco.ai/legal/security.html), [privacy notice](https://kyroco.ai/legal/privacy.html) and [subprocessor list](https://kyroco.ai/legal/subprocessors.html) explain the service’s data handling.

The terms say Kyroco will not use Customer Content to train, fine-tune or improve general-purpose or foundation models. They also describe model providers used for memory operations. Read [the terms](https://kyroco.ai/legal/terms.html) rather than assuming “not used for training” means no provider ever processes data.

An assistant you connect can receive the memories it retrieves. Its own data terms also matter. Ask about contractual residency requirements before supplying regulated or restricted material.

## Keep an exit plan

Export my data on the Account page emails you a download link. The export is your own record: your sign-in details, memberships, devices, passkeys and activity log. It does not include the account's memories. Only the account owner can export the account's data. They use Export account data in the Danger zone on the Settings page, which emails a download link for the whole account, memories included. Other account admins cannot. Plan that before closing an account, and verify the export contains what you need. A company memory should not depend on one person retaining access to an old conversation.

Correcting or superseding a memory does not erase it or reclaim room. Deleting your own memory takes it out of search, AI tools and the Memories page, but Korium keeps it rather than erasing it. Account deletion, retention and termination are governed by the [terms](https://kyroco.ai/legal/terms.html) and [DPA](https://kyroco.ai/legal/dpa.html); the [account FAQ](../../korium-qa.html#memories) explains the practical distinction.

[All Korium guides](index.html) [Next: How company knowledge moves](how-company-knowledge-moves.html)

Use the [setup checklist](release-status.html) before changing an automated workflow. Check your installed client’s help if its interface differs.
