Pular para o conteúdo
Pathrule

documentação

Funções e permissões

As funções de uma organização Pathrule, como um espaço de trabalho é compartilhado com toda a organização ou mantido privado, e como o banco de dados aplica cada leitura e escrita da mesma forma no console web, no CLI, no VS Code e no MCP.

Nesta página

O Pathrule começa como uma ferramenta individual e cresce até virar um produto para equipes. Quando você convida colegas, a pergunta passa a ser quem pode ver e alterar o quê. Esta página explica as funções que você atribui, como o acesso se restringe da organização para o espaço de trabalho e onde a verificação de fato acontece.

Resumindo: as funções são atribuídas no nível da organização, o acesso pode ser restringido por espaço de trabalho, e cada leitura e escrita em um espaço de trabalho do Pathrule Cloud é verificada pelo banco de dados com base no usuário com que você entrou. A mesma verificação vale se a requisição vier do console web em app.pathrule.io, do Pathrule CLI, da extensão do VS Code ou do servidor MCP com que um cliente de IA se comunica.

Um espaço de trabalho local criado com --local não tem conta e fica em uma única máquina, então as funções não se aplicam a ele até que você o mova para a nuvem.

As quatro funções

As funções são atribuídas a cada pessoa no nível da organização. Um proprietário ou administrador convida um colega por e-mail e escolhe a função dele, Editor por padrão; o colega aceita o convite para entrar. Convide pela área Members do console web ou pelo terminal:

pathrule invite colleague@example.com --role viewer
FunçãoO que pode fazer
OwnerAdministração da organização e controles de propriedade. A organização precisa manter um proprietário.
AdminGerenciar os membros e as funções permitidas, e administrar os espaços de trabalho.
EditorLer e escrever conteúdo (memórias, regras, skills) nos espaços de trabalho a que tem acesso. É a função do colaborador do dia a dia.
ViewerLer conteúdo nos espaços de trabalho a que tem acesso. Sem escrita.

Daí decorrem algumas salvaguardas:

  • Mudanças de propriedade exigem autoridade de proprietário, e a organização precisa manter um proprietário.
  • Mudanças de propriedade e de membros são verificadas no servidor, incluindo a exigência de manter um proprietário.

Mudanças de membros exigem uma sessão autorizada e válida. Ações sensíveis de arquivar e excluir espaços de trabalho exigem, além disso, uma autenticação recente.

Assentos e planos

Cada pessoa na organização ocupa um assento, seja qual for a função.

  • Solo e Pro são para uma pessoa. Eles não permitem convites; para trabalhar com outras pessoas, mude para o Team.
  • O Team é cobrado por assento, com no mínimo dois, incluindo o proprietário. Convidar além dos assentos que você paga exige mais um assento; com menos assentos do que membros, todos mantêm o acesso e os novos convites ficam aguardando.
  • Os assentos do Enterprise são combinados com a equipe de vendas.

Os assentos e as faturas ficam em Billing, no console web; pathrule billing abre essa área pelo terminal. Veja Pathrule Web.

Acesso ao espaço de trabalho: toda a organização ou privado

A função define o que uma pessoa pode fazer. O modo de acesso de um espaço de trabalho define quem consegue chegar até ele. Cada espaço de trabalho está em um de dois modos.

  • Toda a organização. Todos os membros da organização têm acesso, com a função que têm na organização.
  • Privado. Só as pessoas adicionadas explicitamente ao espaço de trabalho têm acesso. Ser membro da organização não basta.

Proprietários e administradores alternam o modo nas configurações do console web, em Workspace, Access. Quando um espaço de trabalho se torna privado, só os membros explícitos desse espaço de trabalho têm acesso. Revise e adicione as pessoas que precisam dele; ser membro da organização deixa de garantir acesso. Dentro de um espaço de trabalho privado, a função da pessoa nesse espaço de trabalho define o que ela pode fazer ali, então você pode dar a alguém um nível de acesso diferente do que essa pessoa tem em outros lugares.

Perder acesso não é destrutivo

Mudanças de permissão nunca destroem trabalho e raramente o escondem.

  • Se você perde o acesso de escrita (por exemplo, ao passar de Editor para Viewer), nada desaparece. Você continua lendo tudo o que lia antes; as escritas feitas por você, ou por um assistente agindo em seu nome, são recusadas.
  • Se você perde o acesso a um espaço de trabalho (ao ser removido de um espaço de trabalho privado ou da organização), só então o conteúdo dele sai da sua visão. O conteúdo continua com a equipe.

O mesmo limite vale para o assistente. Quando um cliente de IA tenta escrever onde um membro não pode escrever, a chamada de ferramenta MCP retorna um resultado claro de permissão negada, que o assistente pode repassar a você em linguagem simples, em vez de falhar em silêncio ou parecer que deu certo. O contexto que um assistente recebe, e os arquivos de instruções que o Pathrule escreve para ele, sempre vêm apenas de espaços de trabalho que esse membro pode ler.

Onde a verificação acontece

Nada disso é aplicado pelo aplicativo que você estiver usando. Cada leitura e escrita em um espaço de trabalho do Cloud passa por uma verificação de acesso no banco de dados, resolvida com base no usuário com que você entrou, na sua participação na organização e no modo de acesso do espaço de trabalho. As verificações de acesso fazem parte das operações de banco de dados do servidor, e não de um botão escondido na interface.

  • Uma verificação para todas as superfícies. O console web, o Pathrule CLI, a extensão do VS Code, o servidor MCP local e o Remote MCP passam todos pelo mesmo controle de acesso aplicado pelo banco de dados. Uma alteração feita pelo terminal e uma escrita vinda de um cliente de IA são liberadas ou barradas pelas mesmas regras.
  • Nenhuma chave de administrador compartilhada. Cada superfície usa um token de curta duração e específico do usuário, nunca uma chave de serviço compartilhada que poderia abrir os dados de outra equipe. Um cliente vazado só consegue alcançar o que esse usuário já alcança.
  • Resolução no servidor. As funções na organização e nos espaços de trabalho são resolvidas no servidor, sem confiar no que o cliente informa, então uma requisição adulterada não consegue conceder a si mesma um acesso que não recebeu.

Para ver o quadro completo de como o acesso à nuvem é controlado, consulte a visão geral de segurança.

No auto-hospedado

O Enterprise auto-hospedado usa o mesmo modelo de funções e permissões na sua própria conta da Cloudflare. As funções e os modos de acesso dos espaços de trabalho funcionam da mesma forma; a diferença é que os dados e o banco de dados ficam na sua conta. O login único pelo seu próprio provedor de identidade é configurado dentro do contrato Enterprise e é mapeado para as mesmas funções de organização descritas aqui. Veja Enterprise auto-hospedado para entender como essa implantação funciona.