Controle de acesso

O Access Control permite que admins da organização definam grupos de permissões que restringem o que cada conjunto de pessoas pode fazer — quais provedores de modelos de IA podem usar, quais blocks de workflow podem colocar e quais recursos da plataforma ficam visíveis para elas. Os grupos de permissões têm escopo de organização. O grupo padrão da organização governa todos em toda a organização; qualquer outro grupo tem como alvo um conjunto específico de workspaces e, por padrão, governa todos os membros desses workspaces (incluindo membros externos) — ou apenas membros específicos, se você adicioná-los. Uma pessoa é governada por exatamente um grupo em cada workspace. As restrições são aplicadas tanto no executor de workflows quanto no Chat, com base na organização dona do workspace do workflow.


Como funciona

O controle de acesso é construído em torno de grupos de permissões. Cada grupo pertence a uma organização específica e tem um nome, uma descrição opcional, um escopo de workspaces, 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 vale para toda a organização; qualquer outro grupo tem como alvo 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 restringe o grupo apenas a essas pessoas. Workspaces pessoais que não pertencem a uma organização não têm grupos de permissões.

O Studio resolve de forma determinística qual grupo governa uma pessoa em um workspace:

  1. um grupo não padrão que tem aquele workspace como alvo e do qual a pessoa é membro explícito tem prioridade; se não houver,
  2. aplica-se um grupo não padrão que tem aquele workspace como alvo e nenhum membro (portanto governa todos os membros do workspace, incluindo membros externos); se não houver,
  3. aplica-se o grupo padrão da organização (se algum estiver definido); se não houver,
  4. nenhuma restrição é aplicada.

Verificações no momento da atribuição mantêm isso sem ambiguidade: um workspace tem no máximo um grupo de todos os membros, e uma pessoa é membro explícito de no máximo um grupo por workspace.

Quando alguém executa um workflow ou usa o Chat, o Studio lê a configuração do grupo resolvido e a aplica:

  • No executor: se um workflow usa um tipo de block ou um provedor de modelo não permitido, a execução para na hora com um erro. Isso vale tanto para execuções manuais quanto para deployments agendados ou disparados por API.
  • No Chat: os blocks não permitidos são filtrados da lista de blocks, então não podem ser adicionados a um workflow. Tipos de ferramenta não permitidos (MCP, ferramentas customizadas, skills) são ignorados se o Studio tentar usá-los.

Configuração

1. Abra as configurações de Access Control

Vá em Settings → Enterprise → Access Control a partir de qualquer workspace da sua organização. Os grupos de permissões são definidos uma única vez no nível da organização e valem para todos os workspaces sob ela. Só owners e admins da organização podem gerenciá-los.

2. Crie um grupo de permissões

Clique em + Create e informe um nome (obrigatório) e uma descrição opcional. Um grupo tem como alvo um conjunto específico de workspaces (escolhidos no seletor múltiplo) ou é o grupo padrão da organização. Um grupo com escopo de workspaces vale por padrão para todos os membros desses workspaces, incluindo membros externos — você pode restringi-lo a pessoas específicas depois. Marcar o grupo como default faz com que ele governe todos os workspaces da organização e todos os membros não cobertos por outro grupo (incluindo membros externos); apenas um grupo por organização pode ser o padrão, e o padrão sempre vale para todos os workspaces.

3. Configure as permissões

Clique em Details em um 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 apenas as abas de restrição.

Members

Um grupo com escopo de workspaces e sem membros vale para todo mundo nos seus workspaces (incluindo membros externos). Adicione membros aqui — buscando na sua organização por nome ou e-mail — para restringir o grupo apenas a essas pessoas; remover todos os membros faz o grupo voltar a governar todos. O grupo padrão ignora membros e não tem aba Members.

Model Providers

Controla quais provedores de modelos de IA os membros deste grupo podem usar.

A lista mostra todos os provedores disponíveis no Studio.

  • Todos marcados (padrão): todos os provedores são permitidos.
  • Subconjunto marcado: apenas os provedores selecionados são permitidos. Qualquer block de workflow ou agente que use um provedor fora da lista falha no momento da execução.

Blocks

Controla quais blocks de workflow os membros podem colocar e executar.

Os blocks são divididos em duas seções: Core Blocks (Agent, API, Condition, Function etc.) e Tools (todos os blocks de integração).

  • Todos marcados (padrão): todos os blocks são permitidos.
  • Subconjunto marcado: apenas os blocks selecionados são permitidos. Workflows que já contenham um block não permitido falham ao executar — eles não são modificados automaticamente.

O block 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 caixa de seleção corresponde a um recurso específico; marcá-la oculta ou desativa aquele recurso para os membros do grupo.

Sidebar

RecursoEfeito quando marcado
Knowledge BaseOculta a seção Knowledge Base da barra lateral
TablesOculta a seção Tables da barra lateral

Workflow Panel

RecursoEfeito quando marcado
ChatOculta o painel do Chat dentro do editor de workflow

Settings Tabs

RecursoEfeito quando marcado
IntegrationsOculta a aba Integrations em Settings
SecretsOculta a aba Secrets em Settings
API KeysOculta a aba Studio Keys em Settings
FilesOculta a aba Files em Settings

Tools

RecursoEfeito quando marcado
MCP ToolsDesativa o uso de ferramentas MCP em workflows e agentes
Custom ToolsDesativa o uso de ferramentas customizadas em workflows e agentes
SkillsDesativa o uso das Studio Skills em workflows e agentes

Deploy Tabs

RecursoEfeito quando marcado
APIOculta a aba de deploy por API
MCPOculta a aba de deploy por MCP
ChatOculta a aba de deploy por Chat
TemplateOculta a aba de deploy por Template

Features

RecursoEfeito quando marcado
Studio MailerOculta o recurso Studio Mailer (Inbox)
Public APIDesativa o acesso à API pública dos workflows com deploy

Logs

RecursoEfeito quando marcado
Trace SpansOculta os detalhes dos trace spans nos logs de execução

Collaboration

RecursoEfeito quando marcado
InvitationsDesativa a possibilidade de convidar novos membros para o workspace

4. Escolha a quem o grupo se aplica

Um grupo com escopo de workspaces vale, por padrão, para todos os membros desses workspaces — incluindo membros externos. Para restringi-lo a pessoas específicas, abra Configure Permissions → Members e adicione membros buscando na sua organização por nome ou e-mail. Remover todos os membros faz o grupo voltar a governar todo mundo nos seus workspaces.

Cada pessoa é governada por um grupo por workspace, então adicionar alguém é rejeitado quando isso entraria em conflito com outro grupo dela em um workspace compartilhado (em operações em massa, a pessoa é ignorada em vez de adicionada). O grupo padrão ignora membros por completo — ele sempre governa todos os que não são cobertos por um grupo de workspace.

Gerencie quais workspaces um grupo governa pela lista Workspaces, na visão Details do grupo (Add e Remove). Um grupo não padrão é criado com pelo menos um workspace como alvo, mas você pode remover todos depois — um grupo sem workspaces simplesmente não governa nada até você adicionar um de volta.

Membros externos do 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 com escopo de workspaces e sem membros — e o grupo padrão da organização — continuam governando essas pessoas.


Aplicação das restrições

Execução de workflows

As restrições são aplicadas no momento da execução, não no momento de salvar. Se a configuração de um grupo mudar depois de o workflow ter sido construído:

  • Restrições de blocks: qualquer execução de workflow que chegue a um block não permitido para na hora com um erro. O workflow não é modificado — apenas a execução é bloqueada.
  • Restrições de provedor de modelo: qualquer block ou agente que use um provedor não permitido para na hora com um erro.
  • Restrições de ferramenta (MCP, ferramentas customizadas, skills): agentes que usam um tipo de ferramenta não permitido param na hora com um erro.

Isso vale independentemente de como o workflow é disparado — manualmente, por API, por agendamento ou por webhook.

Chat

Quando alguém abre o Chat, o grupo de permissões dessa pessoa é lido antes de qualquer sugestão de block ou de ferramenta:

  • Blocks fora da lista de permitidos são filtrados por completo do seletor de blocks — eles não aparecem como opção.
  • Se o Studio gerar uma etapa de workflow que usaria uma ferramenta não permitida (MCP, customizada ou skills), essa etapa é ignorada e o motivo é registrado.

Regras de participação

  • Uma pessoa pode pertencer a vários grupos de permissões, mas no máximo um grupo a governa em cada workspace.
  • Em um determinado workspace, um grupo não padrão do qual a pessoa é membro explícito tem prioridade sobre um grupo não padrão de todos os membros (um sem membros) que tenha aquele workspace como alvo, que por sua vez tem prioridade sobre o grupo padrão da organização.
  • Um workspace tem no máximo um grupo de todos os membros, e uma pessoa é membro explícito de no máximo um grupo por workspace. Adicionar uma pessoa, adicionar um workspace ou remover o último membro de um grupo é rejeitado quando isso violaria essa regra — participações e escopos nunca são movidos silenciosamente.
  • Um grupo com escopo de workspaces e sem membros governa todo mundo nesses workspaces (incluindo membros externos); adicione membros para restringi-lo a pessoas específicas.
  • Pessoas não cobertas por nenhum grupo de workspace caem no grupo padrão da organização, se houver um definido; caso contrário, nenhuma restrição é aplicada a elas.
  • Apenas um grupo por organização pode ser o grupo padrão; ele sempre vale para todos os workspaces, ignora membros e também governa membros externos do workspace.
  • Workspaces pessoais ou legados que não pertencem a uma organização não têm grupos de permissões.

Common Questions

Qualquer owner ou admin de uma organização com direito a Enterprise pode criar, editar e excluir grupos de permissões. A organização precisa estar no plano Enterprise.
O workflow não é modificado — ele continua existindo e pode ser editado. No entanto, qualquer execução que chegue a um block não permitido para na hora com um erro. O block precisa ser removido, ou a configuração do grupo da pessoa precisa ser atualizada, antes de o workflow poder rodar com sucesso.
Sim. Uma pessoa pode pertencer a vários grupos de permissões, mas só um a governa em cada workspace. Um grupo do qual ela é membro explícito tem prioridade sobre um grupo de todos os membros (um sem membros) naquele workspace, que por sua vez tem prioridade sobre o grupo padrão da organização. Um workspace tem no máximo um grupo de todos os membros, e uma pessoa é membro explícito de no máximo um grupo por workspace.
Por padrão, um grupo com escopo de workspaces vale para todos os membros desses workspaces, incluindo membros externos. Para restringi-lo a pessoas específicas, abra Configure Permissions → Members e adicione-as; o grupo passa a governar apenas esses membros. Remover todos os membros faz o grupo voltar a governar todo mundo nos seus workspaces.
Todo grupo não padrão tem como alvo um conjunto específico de workspaces — escolha-os ao criar o grupo ou na lista Workspaces, na visão Details dele. Só o grupo padrão da organização vale para toda a organização.
Em um workspace que tenha um grupo de todos os membros (um sem membros), esse grupo a governa. Caso contrário, o grupo padrão da organização a governa, se houver um definido. Se nenhum dos dois se aplicar, ela não tem restrições — todos os blocks, provedores de modelos e recursos da plataforma ficam disponíveis.
Sim. O Studio lê o grupo de permissões da pessoa na organização do workspace antes de sugerir blocks ou ferramentas. Blocks não permitidos são filtrados do seletor de blocks e tipos de ferramenta não permitidos são ignorados durante a geração do workflow.
Sim. Defina o escopo de cada grupo para os workspaces que ele deve governar e escolha entre aplicá-lo a todo mundo ali ou adicionar membros para atingir pessoas específicas. Um workspace pode ter um grupo de todos os membros mais outros grupos que atingem pessoas específicas, governadas pelo próprio grupo. Quem pode acessar um determinado workspace continua sendo controlado separadamente pelos convites e pelas permissões do workspace.
O grupo padrão é o único grupo de toda a organização que governa quem não é coberto por um grupo de workspace, incluindo membros externos do workspace. Ele sempre vale para todos os workspaces e ignora membros. Só um por organização; se nenhum estiver definido, quem não está em nenhum grupo não tem restrições.

Configuração em auto-hospedagem

Instalações auto-hospedadas usam variáveis de ambiente em vez da verificação de cobrança/plano.

Variáveis de ambiente

ACCESS_CONTROL_ENABLED=true
NEXT_PUBLIC_ACCESS_CONTROL_ENABLED=true

Você também pode definir uma lista de blocks permitidos no nível do servidor com a variável de ambiente ALLOWED_INTEGRATIONS. Ela funciona como uma restrição adicional sobre qualquer configuração de grupo de permissões — um block precisa ser permitido tanto pela lista do ambiente quanto pelo grupo da pessoa para poder ser usado.

# Only these block types are available across the entire instance
ALLOWED_INTEGRATIONS=slack,gmail,agent,function,condition

Com o recurso ativado, os grupos de permissões são gerenciados em Settings → Enterprise → Access Control do mesmo jeito que no Studio Cloud.