Users and access

People sign in to Zero through your organization's identity provider — the same login your company already uses. Zero does not store passwords or keep a user list of its own: it reads who exists in the provider and decides what each person can do here.

	Where it lives	What it decides
Identity	In the identity provider	Who the person is, the email, whether the account is enabled, the password
Access to Zero	In Zero	Whether they enter this organization, with which role and in which Spaces

Each organization uses the identity realm it is bound to. There is no Zero realm holding the people of every organization: listing, search, creation and the password-setup email all happen in the organization's OWN realm, and Zero only administers that realm once it has received the proper delegation from it.

Existing in the provider does not grant access to Zero. An account without access that tries to sign in sees "Your account exists, but it does not have access to Zero yet." — and the way forward is for someone who administers the organization to grant access.

The Users screen

Under Users, people with the Administrator role see the organization's identity-provider users, with search by name, email or username. Each row shows:

Column	Meaning
Realm	enabled, disabled (the provider refuses to sign this account in) or password pending (the account has not set a password yet)
Access to Zero	Has access, with the role, or No access — the state of most people in a shared provider

People who do not administer the organization see only the member list — who they work with — and not the provider's directory.

Grant access to someone who already exists

Grant access picks the role — Administrator, Operator or User (the latter with the Spaces the person will operate) — and takes effect immediately: there is no invitation and nothing to accept; the person's next sign-in already lands in the organization.

Zero then sends an informational email, "Your access to Zero has been granted", with the organization, the role and a Sign in to Zero button that opens the normal login screen. It carries no password, code or special link, and it does not ask for a password change: the person signs in with the account they already use.

The email is a notice, not what grants access. If it fails, access still holds; the screen shows the delivery state — queued, accepted by the mail server or failed, with the reason — and offers Resend notice. "Accepted by the mail server" does not mean the message arrived or was read.

An account that is disabled in the provider does not receive access: the provider would keep refusing the sign-in, and the access would only look like it works.

Create a new person

Create user asks for email, first name, last name, the role and — for User — the Spaces. There is no password field, on purpose:

1. the account is created in the identity provider without a password, with the obligation to set one;
2. access to Zero is granted at the same moment;
3. Zero sends "Your Zero account has been created", which only announces the access and says another email is coming;
4. the identity provider sends the official email with the link for the person to set their own password — through the mail server of the organization's realm, not Zero's. The link is valid for 24 hours and leads back to the console login.

These are two different emails from different senders, and neither carries a password. The password-setup link belongs to the provider: Zero neither sees nor stores it.

Each step has its own state on screen. If the official email fails — for instance because the organization's realm has no mail server configured — the account and the access stay created, and Resend password-setup email tries again once whoever administers the realm configures email. Zero does not reconfigure anyone's realm to make this work. That resend only exists for people Zero created in this organization who have not set a password yet: granting access never resets anyone's password.

If someone with that email already exists in the provider, nothing is created: the screen says "This user already exists in the realm.", shows the person and offers Grant access.

Change and revoke

Change access switches the role or the Spaces. Nothing is recreated and no email is sent; the audit trail records who changed it, from which role to which.

Revoke access removes the person from the organization immediately — authorization is checked on every request, without waiting for the login to expire. Their account in the identity provider keeps existing, with its password and access to other products. The organization is never left without an administrator: the last one cannot be demoted or revoked.

When the directory does not show

If the organization's realm only lets Zero validate the sign-in, the screen says "This realm has not yet delegated user administration to Zero.", shows who already has access and lists what is missing — only this, never administration of the whole realm:

• reading the realm's users;
• creating users and requesting email actions;
• assigning the Zero access marker, and no other role.

The action is to delegate this realm to Zero: whoever administers the realm installs Zero's machine account in it (a temporary authorization that deletes itself at the end), and the platform records the delegation. That account is valid for that realm only. Meanwhile, changing and revoking the access of people who already have it keeps working.

From the command line and from agents

The same operations exist in the CLI and in the MCP server, with the same authorization as the console:

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

An agent asked to "grant Carolina access" searches for the person in the provider and grants access to the identifier it found — never by approximation: with more than one possible person, it asks.