People and access

Access works at three levels: your organization, each workspace, and individual pages and folders. Most teams only ever use the first two. The third is there for when someone should see or own one part of a workspace and not the rest.

And one rule ties it all together: an agent never gets more than the person or key behind it. A teammate's Claude sees what that teammate can see. A key limited to two folders sees those two folders. So getting people's access right is also how you control what their agents read.

Organization roles

Everyone in your organization has one of three roles.

Owners can do everything: read, edit and publish in every workspace, manage people, change anyone's role (except their own), and create workspaces. The person who sets up the organization is its first owner, and an organization always keeps at least one.

Admins can read, edit and publish in every workspace, invite and remove members, make members admins, and create workspaces. Only an owner can remove or demote an admin.

Members see nothing until they're given access. That's deliberate: it means you can bring in someone to own one folder without them seeing everything else.

You can see everyone, and change roles, on the Members page.

Workspace access

For each member, the Members page shows a dropdown with their access to the current workspace:

• No access. They can't see this workspace (unless they've been given individual pages or folders; see below).
• Can read. They see every shared page and folder, and their agents can read every published page.
• Can edit. Everything above, plus editing anything in the workspace, importing, and managing tags, packs, agent instructions and workspace API keys. Their changes are drafts until someone with publish access makes them live.
• Can edit and publish. Everything above, plus publishing and unpublishing pages, so their changes (and the ones they review) reach agents.

Owners and admins don't need workspace access; they already have it everywhere.

Editing and publishing are separate on purpose. A team can let many people, and their agents, suggest changes while a few decide what agents actually get. The same split applies to agents: a connection publishes only where the person or key behind it can.

Page and folder access

You can also give someone access to a single page or folder, as can read, can edit or can edit and publish. Open the page (or open the folder from its menu in the sidebar) and use the Access row to add people from your organization.

A few things to know:

• Folder access covers everything inside, including subfolders and pages added later.
• It adds to workspace access, it doesn't replace it. Someone who can read the whole workspace and can edit the Support folder can read everything and edit Support.
• Someone with no other access sees just what they've been given, plus the folders above it so they can find their way. Their agents see the same.
• Anyone who can edit a page or folder can change who has access to it. This is how ownership spreads: give the head of support access to the Support folder, and they can bring in their own team. Nobody hands out more than they have, though: publish access is given only by someone who can publish there.
• Inherited access is shown, too. On a page inside a shared folder, people with access through the folder appear with a dashed outline and the folder's name.

Page and folder access is the right tool for ownership. Give the product manager publish access to the Product folder and the support lead the Support folder, and each of them maintains what they know best. Their changes, and their agents' suggested changes, are theirs to publish; give the rest of their teams edit access, and everything those people add waits for the owner's review.

What people with access to only part of a workspace can't do: create pages at the top level, import, change tags, packs or instructions, mark pages as rules or always included, or create workspace API keys. Those affect the whole workspace, so they need someone who can edit all of it.

Inviting people

On the Members page, owners and admins can invite someone by email with one of:

• Can read this workspace,
• Can edit this workspace (changes stay drafts),
• Can edit and publish in this workspace,
• Admin of the organization.

They get an email, and the access applies the first time they sign in with that address. Pending invites are listed with the members, and can be cancelled until they're accepted.

To give someone just a page or folder, invite them to the workspace, add them on the page or folder once they've joined, and then set their workspace access to No access. They'll keep the page or folder.

Removing people

Removing someone from the organization takes away everything that came with being in it, all at once:

• their access to every workspace, page and folder,
• their personal API keys, which are revoked,
• their private notes, which are deleted, since nobody else could ever see them,
• their default workspace setting.

Pages they wrote, edits they made and things they published all stay. If they had private notes worth keeping, ask them to share them with the team first.

Workspace keys they made don't depend on them, so they don't have to go. If they made any, you'll see them listed when you click Remove, and you pick who takes them over: an owner, an admin, or someone who can edit every workspace the keys are in. The keys keep working as they were. Choose Nobody: revoke them if they should stop.

Setting someone's workspace access to No access is gentler: they lose that workspace, but keep any individual pages and folders they've been given, and stay in the organization.

Several workspaces

An organization can have as many workspaces as it needs. Each has its own pages, tags, packs, instructions, keys and connection URL, and members have separate access to each. Owners and admins can create one from the workspace switcher at the top of the sidebar, starting blank or from the Sales & Marketing template.

Common reasons to split:

• Brands or product lines that shouldn't bleed into each other's writing.
• Clients, if you're an agency: one workspace per client keeps every account's context apart, and each client's freelancers can have a key to theirs alone.
• Very different audiences, like an internal engineering workspace and a customer-facing one.

Don't split just to organize. Folders do that better, and one workspace means one connection for everyone.

People who sign in from their AI tool reach every workspace they have access to, through one connection. Their agent uses their default workspace unless it asks for another, and each person can set their default from the Connect agents page.