Access Control permite que admins da organização definam grupos de permissão que restringem o que cada conjunto de usuários pode fazer — quais provedores de modelo de IA podem usar, quais blocos de workflow podem colocar e quais recursos da plataforma ficam visíveis. Grupos de permissão são escopados à organização. O grupo padrão da organização governa todo mundo na org; todo outro grupo mira um conjunto específico de workspaces e, por padrão, governa todos os membros daqueles workspaces (incluindo membros externos) — ou só membros específicos depois que você os adiciona. Um usuário é governado por exatamente um grupo em qualquer workspace. Restrições são aplicadas tanto no executor de workflow quanto no Mothership, com base na organização que possui o workspace do workflow.
Como funciona
Access control é construído em torno de grupos de permissão. Cada grupo pertence a uma organização específica e tem um nome, uma descrição opcional, um escopo de workspace, uma lista opcional de membros e uma configuração que define o que seus membros podem e não podem fazer. O único grupo padrão da organização é org-wide; todo outro grupo mira um conjunto específico de workspaces. Um grupo não padrão sem membros governa todos os membros dos seus workspaces (incluindo membros externos); adicionar membros o restringe só àquelas pessoas. Workspaces pessoais que não pertencem a uma organização não têm grupos de permissão.
O Zoen resolve o grupo governante para um usuário num workspace de forma determinística:
- um grupo não padrão mirando aquele workspace do qual o usuário é membro explícito tem precedência; caso contrário
- um grupo não padrão mirando aquele workspace que não tem membros (então governa todos os membros do workspace, incluindo externos) se aplica; caso contrário
- o grupo padrão da organização se aplica (se houver um); caso contrário
- nenhuma restrição se aplica.
Checagens no momento da atribuição mantêm isso sem ambiguidade: um workspace tem no máximo um grupo all-members, e um usuário é membro explícito de no máximo um grupo por workspace.
Quando um usuário roda um workflow ou usa o Mothership, o Zoen lê a configuração do grupo resolvido e a aplica:
- No executor: Se um workflow usa um tipo de bloco ou provedor de modelo não permitido, a execução para imediatamente com um erro. Isso se aplica a execuções manuais e a deployments por schedule ou API.
- No Mothership: Blocos não permitidos são filtrados da lista de blocos para que não possam ser adicionados a um workflow. Tipos de tool não permitidos (MCP, custom tools, skills) são pulados se o Mothership tentar usá-los.
Setup
1. Abra as settings de Access Control
Vá em Settings → Enterprise → Access Control a partir de qualquer workspace da sua organização. Grupos de permissão são definidos uma vez no nível da organização e se aplicam a todos os workspaces sob ela. Só owners e admins da organização podem gerenciá-los.
2. Crie um grupo de permissão
Clique em + Create e informe um nome (obrigatório) e uma descrição opcional. Um grupo ou mira um conjunto específico de workspaces (escolha-os no multi-select) ou é o grupo padrão da organização. Um grupo escopado a workspace se aplica a todos os membros dos seus workspaces por padrão, incluindo membros externos — você pode restringi-lo a pessoas específicas depois. Marcar o grupo como default faz ele governar todos os workspaces da organização e todo membro não coberto por outro grupo (incluindo membros externos); só um grupo por organização pode ser o default, e o default sempre se aplica a todos os workspaces.
3. Configure as permissões
Clique em Details num grupo e abra Configure Permissions. Grupos não padrão têm uma aba Members mais três abas de restrição; o grupo padrão tem só as abas de restrição.
Members
Um grupo escopado a workspace sem membros se aplica a todo mundo nos seus workspaces (incluindo membros externos). Adicione membros aqui — buscando na organização por nome ou e-mail — para restringir o grupo só àquelas pessoas; remover todos os membros o devolve a governar todo mundo. O grupo padrão ignora membros e não tem aba Members.
Model Providers
Controla quais provedores de modelo de IA os membros deste grupo podem usar.
A lista mostra todos os provedores disponíveis no Zoen.
- Todos marcados (padrão): Todos os provedores são permitidos.
- Subconjunto marcado: Só os provedores selecionados são permitidos. Qualquer bloco de workflow ou agente usando um provedor fora da lista falhará em tempo de execução.
Blocks
Controla quais blocos de workflow os membros podem colocar e executar.
Os blocos são divididos em duas seções: Core Blocks (Agent, API, Condition, Function etc.) e Tools (todos os blocos de integração).
- Todos marcados (padrão): Todos os blocos são permitidos.
- Subconjunto marcado: Só os blocos selecionados são permitidos. Workflows que já contêm um bloco não permitido falharão ao rodar — não são modificados automaticamente.
O bloco start_trigger (o ponto de entrada de todo workflow) é sempre permitido e não pode ser restringido.
Platform
Controla a visibilidade de recursos e módulos da plataforma.
Cada checkbox mapeia para um recurso específico; marcá-lo oculta ou desabilita aquele recurso para membros do grupo.
Sidebar
| Recurso | Efeito quando marcado |
|---|---|
| Knowledge Base | Oculta a seção Knowledge Base da sidebar |
| Tables | Oculta a seção Tables da sidebar |
Workflow Panel
| Recurso | Efeito quando marcado |
|---|---|
| Copilot | Oculta o painel Copilot dentro do editor de workflow |
Settings Tabs
| Recurso | Efeito quando marcado |
|---|---|
| Integrations | Oculta a aba Integrations em Settings |
| Secrets | Oculta a aba Secrets em Settings |
| API Keys | Oculta a aba Zoen Keys em Settings |
| Files | Oculta a aba Files em Settings |
Tools
| Recurso | Efeito quando marcado |
|---|---|
| MCP Tools | Desabilita o uso de tools MCP em workflows e agentes |
| Custom Tools | Desabilita o uso de custom tools em workflows e agentes |
| Skills | Desabilita o uso de Zoen Skills em workflows e agentes |
Deploy Tabs
| Recurso | Efeito quando marcado |
|---|---|
| API | Oculta a aba de deployment de API |
| MCP | Oculta a aba de deployment de MCP |
| Chat | Oculta a aba de deployment de Chat |
| Template | Oculta a aba de deployment de Template |
Features
| Recurso | Efeito quando marcado |
|---|---|
| Zoen Mailer | Oculta o recurso Zoen Mailer (Inbox) |
| Public API | Desabilita acesso à public API para workflows deployados |
Logs
| Recurso | Efeito quando marcado |
|---|---|
| Trace Spans | Oculta detalhes de trace span nos logs de execução |
Collaboration
| Recurso | Efeito quando marcado |
|---|---|
| Invitations | Desabilita a capacidade de convidar novos membros para o workspace |
4. Escolha a quem se aplica
Um grupo escopado a workspace se aplica a todos os membros dos seus workspaces por padrão — incluindo membros externos. Para restringi-lo a pessoas específicas, abra Configure Permissions → Members e adicione membros buscando na organização por nome ou e-mail. Remover todos os membros devolve o grupo a governar todo mundo nos seus workspaces.
Um usuário é governado por um grupo por workspace, então adicionar um usuário é rejeitado quando conflitaria com outro dos seus grupos num workspace compartilhado (pulado em vez de adicionado em bulk). O grupo padrão ignora membros por completo — sempre governa quem não está coberto por um grupo de workspace.
Gerencie quais workspaces um grupo governa na lista Workspaces na visão Details do grupo (Add e Remove). Um grupo não padrão é criado mirando pelo menos um workspace, mas você pode depois remover todos — um grupo sem workspaces simplesmente não governa nada até você adicionar um de volta.
Membros externos de workspace (pessoas que têm acesso a um workspace mas pertencem a outra organização) não podem ser adicionados como membros nomeados, mas um grupo escopado a workspace sem membros — e o grupo padrão da organização — ainda os governa.
Enforcement
Execução de workflow
Restrições são aplicadas no ponto de execução, não no momento de salvar. Se a configuração de um grupo muda depois que um workflow é construído:
- Restrições de bloco: Qualquer execução de workflow que chega a um bloco não permitido para imediatamente com um erro. O workflow não é modificado — só a execução é bloqueada.
- Restrições de provedor de modelo: Qualquer bloco ou agente que usa um provedor não permitido para imediatamente com um erro.
- Restrições de tool (MCP, custom tools, skills): Agentes que usam um tipo de tool não permitido param imediatamente com um erro.
Isso se aplica independentemente de como o workflow é disparado — manualmente, via API, via schedule ou via webhook.
Mothership
Quando um usuário abre o Mothership, seu grupo de permissão é lido antes de qualquer sugestão de bloco ou tool:
- Blocos fora da lista permitida são filtrados do block picker por completo — não aparecem como opções.
- Se o Mothership gera um passo de workflow que usaria uma tool não permitida (MCP, custom ou skills), aquele passo é pulado e o motivo é anotado.
Regras de membership de usuário
- Um usuário pode pertencer a vários grupos de permissão, mas no máximo um grupo o governa em qualquer workspace.
- Para um dado workspace, um grupo não padrão do qual o usuário é membro explícito tem precedência sobre um grupo não padrão all-members (um sem membros) mirando aquele workspace, que tem precedência sobre o grupo padrão da organização.
- Um workspace tem no máximo um grupo all-members, e um usuário é membro explícito de no máximo um grupo por workspace. Adicionar um usuário, adicionar um workspace ou remover o último membro de um grupo é rejeitado quando violaria isso — memberships e escopos nunca são movidos silenciosamente.
- Um grupo escopado a workspace sem membros governa todo mundo nos seus workspaces (incluindo membros externos); adicione membros para restringi-lo a pessoas específicas.
- Usuários não cobertos por nenhum grupo de workspace caem sob o grupo padrão da organização se houver um; caso contrário nenhuma restrição é aplicada a eles.
- Só um grupo por organização pode ser o grupo padrão; ele sempre se aplica a todos os workspaces, ignora membros e também governa membros externos de workspace.
- Workspaces pessoais ou grandfathered que não pertencem a uma organização não têm grupos de permissão.
Common Questions
Setup self-hosted
Deployments self-hosted usam variáveis de ambiente em vez da checagem de billing/plano.
Variáveis de ambiente
ACCESS_CONTROL_ENABLED=true
NEXT_PUBLIC_ACCESS_CONTROL_ENABLED=trueVocê também pode definir uma allowlist de blocos no nível do servidor usando a variável de ambiente ALLOWED_INTEGRATIONS. Isso é aplicado como uma restrição adicional sobre qualquer configuração de grupo de permissão — um bloco precisa ser permitido tanto pela allowlist de ambiente quanto pelo grupo do usuário para ser usável.
# Only these block types are available across the entire instance
ALLOWED_INTEGRATIONS=slack,gmail,agent,function,conditionUma vez habilitado, grupos de permissão são gerenciados em Settings → Enterprise → Access Control da mesma forma que no Zoen Cloud.