Usuários e acesso

Quem entra no Zero é uma pessoa do provedor de identidade da sua organização — o mesmo login da sua empresa. O Zero não guarda senha nem mantém uma lista própria de usuários: ele lê quem existe no provedor e decide o que cada pessoa pode fazer aqui.

	Onde vive	O que decide
Identidade	No provedor de identidade	Quem a pessoa é, o e-mail, se a conta está habilitada, a senha
Acesso ao Zero	No Zero	Se ela entra nesta organização, com qual papel e em quais Spaces

Cada organização usa o realm de identidade ao qual está vinculada. Não existe um realm do Zero com as pessoas de todas as organizações: a lista, a busca, a criação e o e-mail de definição de senha acontecem no realm DA organização, e o Zero só administra aquele realm quando recebeu dele a delegação adequada.

Existir no provedor não dá acesso ao Zero. Uma conta sem acesso que tenta entrar vê "Sua conta existe, mas ainda não possui acesso ao Zero." — e o caminho é alguém que administra a organização conceder o acesso.

A tela de Usuários

Em Usuários, quem tem papel Administrador vê as pessoas do provedor de identidade da organização, com busca por nome, e-mail ou nome de usuário. Cada linha mostra:

Coluna	Significa
Realm	habilitado, desabilitado (o provedor recusa a entrada dessa conta) ou senha pendente (a conta ainda não definiu a senha)
Acesso ao Zero	Com acesso, com o papel, ou Sem acesso — o estado da maioria das pessoas de um provedor compartilhado

Quem não administra a organização vê só a lista de membros — com quem divide o trabalho —, e não o diretório do provedor.

Conceder acesso a quem já existe

Conceder acesso escolhe o papel — Administrador, Operador ou Usuário (este com os Spaces que a pessoa vai operar) — e vale na hora: não há convite nem aceite, e a próxima entrada da pessoa já cai na organização.

Depois disso o Zero envia um e-mail informativo, "Seu acesso ao Zero foi concedido", com a organização, o papel e o botão Entrar no Zero, que leva à tela de login normal. Ele não traz senha, código nem link especial, e não pede para trocar a senha: a pessoa entra com a conta que já usa.

O e-mail é aviso, e não o que dá acesso. Se ele falhar, o acesso continua valendo; a tela mostra o estado do envio — na fila, aceito pelo servidor de e-mail ou falhou, com o motivo — e oferece Reenviar aviso. "Aceito pelo servidor de e-mail" não quer dizer que a mensagem chegou nem que foi lida.

Uma conta desabilitada no provedor não recebe acesso: o provedor continuaria recusando a entrada, e o acesso pareceria funcionar.

Criar uma pessoa nova

Criar usuário pede e-mail, nome, sobrenome, o papel e — para Usuário — os Spaces. Não há campo de senha, e isso é deliberado:

1. a conta nasce no provedor de identidade sem senha, com a obrigação de defini-la;
2. o acesso ao Zero é concedido na mesma hora;
3. o Zero envia "Sua conta do Zero foi criada", que só avisa do acesso e diz que outro e-mail vai chegar;
4. o provedor de identidade envia o e-mail oficial com o link para a pessoa definir a própria senha — pelo servidor de e-mail do realm da organização, e não pelo do Zero. O link vale por 24 horas e volta para o login do console.

São dois e-mails diferentes, de remetentes diferentes, e nenhum carrega senha. O link de definição de senha é do provedor: o Zero não o vê nem o guarda.

Cada passo tem estado próprio na tela. Se o e-mail oficial falhar — por exemplo, porque o realm da organização não tem servidor de e-mail configurado —, a conta e o acesso continuam criados, e Reenviar e-mail de definição de senha tenta de novo depois que quem administra o realm configurar o e-mail. O Zero não reconfigura o realm de ninguém para isso. Esse reenvio só existe para quem o Zero criou nesta organização e ainda não definiu a senha: conceder acesso nunca redefine a senha de ninguém.

Se já existe alguém com aquele e-mail no provedor, nada é criado: a tela diz "Este usuário já existe no realm.", mostra a pessoa e oferece Conceder acesso.

Alterar e revogar

Alterar acesso troca o papel ou os Spaces. Nada é recriado e nenhum e-mail é enviado; a auditoria registra quem mudou, de qual papel para qual.

Revogar acesso tira a pessoa da organização na hora — a autorização é conferida a cada requisição, sem esperar o login expirar. A conta dela no provedor de identidade continua existindo, com a senha e o acesso a outros produtos. A organização nunca fica sem administrador: o último não pode ser rebaixado nem revogado.

Quando o diretório não aparece

Se o realm da organização só permite ao Zero validar a entrada, a tela diz "Este realm ainda não delegou ao Zero a administração de usuários.", mostra quem já tem acesso e lista o que falta — e é só isto, sem pedir administração do realm inteiro:

• ler usuários do realm;
• criar usuários e pedir ações por e-mail;
• atribuir a marca de acesso ao Zero, e nenhuma outra role.

A ação é delegar este realm ao Zero: quem administra o realm instala nele a conta de máquina do Zero (uma autorização temporária, que se apaga sozinha no fim), e a plataforma registra a delegação. Essa conta vale só para aquele realm. Enquanto isso, alterar e revogar o acesso de quem já tem continuam funcionando.

Pela linha de comando e por agentes

As mesmas operações existem na CLI e no servidor MCP, com a mesma autorização do console:

zero users search carolina
zero access grant <id> --role operator
zero users create --email ana@empresa.com.br --first-name Ana --last-name Souza --role member --project <space>
zero access revoke <id>

Um agente que recebe "conceda acesso à Carolina" procura a pessoa no provedor e concede ao identificador encontrado — nunca por aproximação: com mais de uma pessoa possível, ele pergunta.