Projects and Access

An agent vault is a context graph your code reads and writes. 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. Adding a member directly needs them to have signed in at least once: the exact-email lookup resolves against accounts, so it returns nothing for a stranger. For someone who has never heard of xysq, send an invite from the same panel instead. It emails them a link, and they get the role you picked when they accept. Accepting requires their verified email to match the invited address, so an invite cannot be walked into by someone who signed up with a lookalike.

​

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 resolver, and its first question is always the same: 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. Two checks run on every SDK call, and both have to pass. First, do you hold a sufficient role on this vault, from a project or a direct grant. Second, does this key carry a grant covering it, at a level that permits what you asked for. So a key you scoped to one project reaches that project and nothing else, even where you personally hold more; a read-only key stays read-only on a vault you own. Losing membership closes the door regardless of what the key says.

​

Where to go next