Permissions

With Permissions you decide per team or person who in the workspace may build and distribute things: assistants, projects and workflows, automations, API keys, custom MCP servers, meetings and chat links. That way you open up building to the departments without giving up control over what reaches the whole workspace.

Workspace admins are never restricted — they can always do everything.

Availability

Until the feature is enabled, everything behaves as before. Afterwards, as a workspace admin you find the page under Settings → Workspace → Permissions. Even once enabled, nothing changes until you set a rule: without a rule of your own, each permission keeps its default (see below).

What you can control

The page is grouped by area. Each row is one permission with its default:

• Licensed members only: Viewers without a seat never get this permission, whatever rule applies.
• Elevated: these permissions cannot be given to teams with team admins — see Team admins.

Anyone without a permission sees the matching button disabled with the hint “Not enabled by your admin”.

Setting a permission

Click the button with the current setting in the row (e.g. “Default: Everyone”). In the dialog, choose under Availability:

• Default — no rule of your own, the default applies.
• Everyone — every member may do this. You can exclude individual people.
• Admins only — only workspace admins and the people you add.
• Only selected teams — only the teams and people you add.
• All except — everyone except the teams and people you add.

You add individual people as an Exception and set them to Allowed or Blocked — for example “All except apprentices, but Max may”.

How several teams combine

• A person exception always wins. It applies regardless of the person's teams.
• Only selected teams: it is enough for the person to be in one of the selected teams.
• All except: it is enough for the person to be in one of the excluded teams — they are then blocked, even if they are also in other teams.
• The default team contains every member of the workspace. Selecting it makes the rule apply to everyone.

Before you save, the dialog shows the impact: how many members may do this afterwards, how many lose it and how many gain it (admins not counted).

Sharing vs. publishing to everyone

For assistants, projects and meetings, MeinGPT distinguishes two reaches:

• Share — with individual people and with teams you are a member of yourself.
• Publish to everyone — with the whole workspace, the default team or teams you are not a member of.

Anyone who may publish may also share — the “share” row shows this with the hint “Included in …”. Exception: if a person is explicitly blocked from sharing (as a person exception or through a team under All except), they may not publish either. For projects: raising the role of a member or team in a project needs the same permission as sharing.

Editing published assistants and projects: once an assistant or project is published to everyone (shared with the whole workspace or the default team), only people who may also publish to everyone can edit it. That way nobody can rework something everyone uses without being allowed to publish it. Admins always can.

Team admins

Whoever maintains a team's members co-decides who gets that team's permissions. That is why teams with team admins follow these rules:

• Standard permissions (create, share) can also go to teams with team admins. The dialog points out that the team admins co-decide.
• Elevated permissions (publish to everyone, API keys, custom MCP servers) and All except cannot go to teams with team admins. Pick people directly instead, or a team whose members only workspace admins maintain — e.g. a dedicated team “Marketing – Publishing”.
• A team carrying such rules cannot get team admins while the rules exist.

Teams used in a rule cannot be deleted and cannot be switched between “Accessible for everyone” on and off. Remove the team from the rules first.

Checking a person's permissions

Under Settings → Workspace → Members, the shield icon in a person's row opens Permissions of …. It shows for each permission whether the person has it — and why, e.g. “Allowed through team Sales”, “Personal exception” or “Needs a license — this person has none”. You change this on the Permissions page.

Every change to a permission is recorded in the audit log.

When someone loses a permission

• Anyone who loses a create permission keeps the assistants, projects or automations they already created.
• Anyone who loses share or publish can no longer share anew. Existing shares remain.
• Personal API keys stop working as soon as their owner may no longer Create API keys.

Recommended setups

Related

• Releasing a model to specific teams or people — the same principle for AI models. Under Settings → Image models you decide the same way who may use which image model; the default image model always stays available to everyone.
• Roles & Access Model — admin, member and viewer
• Teams & Groups — create and maintain teams