Projects and Access

An agent vault is one agent’s memory. Once you have more than a few, you want two things: a way to organize them, and a way to let teammates in. Projects and access management give you both.

​

Projects group vaults

A project is a named set of vaults plus one member list. Add someone to the project with a role, and they get that role on every vault in it. Standalone vaults (not in any project) stay private to their owner until you grant access directly. You pick the current project from the switcher in the top nav. It defaults to No Project (your standalone vaults); pick a project to scope the vault list to it, and new vaults you create land in that project. “All projects” opens the management page where you add members and see every vault in the project.

​

The four roles

Every grant, whether from a project or directly on a vault, is one of four roles:

• Reader. Can pull and read the vault’s context. Cannot write.
• Writer. Reader, plus can push new context into the vault.
• Admin. Writer, plus can manage the vault’s members and settings.
• Owner. Full control, including transfer and delete. Each vault has exactly one owner.

Roles are additive. If a project makes you a writer and someone also grants you admin directly on one vault, you get admin on that vault. Your effective role is always the highest grant you hold.

​

Two ways to grant access

• Through a project. Add a member to the project and they get their role across all its vaults at once. This is the bulk case: onboard a teammate once, they reach everything the project holds.
• Directly on a vault. Open a vault’s Members tab and add someone to just that vault. This is the exception case: one person needs one vault, no project involved.

Both stack. A vault shows its direct members (editable) alongside any members it inherits from its project (shown read-only, tagged with the project they came from), so the Members tab always answers “who can touch this vault, and why.”

​

Restricted vaults

Sometimes a vault inside a project should not be visible to the whole project, for example a vault holding sensitive context. Flip it to restricted in the vault’s Settings and project-derived roles stop flowing in. The vault then honors only its own direct members. Turn it off and project access resumes. Restricting cuts project members’ access; it does not touch anyone you granted directly. Those direct grants are the point of restricting, they survive.

​

Adding people

When you add a member, you search your collaborators, the people you already share a project or vault with. To bring in someone new, type their exact email and we resolve it to their account. We never show you a list of everyone on the deployment, so adding a teammate never leaks who else exists. The person has to have signed in at least once before you can add them. If they haven’t, the exact-email lookup returns nothing, and they need to log in first.

​

Transfer and removal

• Transfer ownership. An owner can hand a vault to another user from the vault’s Settings. Ownership is a single seat; the new owner takes full control immediately.
• Remove a member. Take someone off a project or a vault and their access ends on their next request. There is no session to expire and no key to rotate, access is computed fresh every time. Offboarding is deactivating the account and removing memberships; every vault they could reach goes dark at once.

​

How access is checked

Every read and write flows through one check: does this caller hold a sufficient role on this vault? The role is computed per request from your current memberships, which is why a change takes effect immediately. A vault you have no role on is invisible, it responds the same as a vault that does not exist, so membership never leaks through error messages. Your agent API key still authenticates you as a person; membership decides which vaults that key can reach. One key now opens every agent vault you can access, not only the ones you own.

​

Where to go next