Team and access
Team sits in the console's account navigation, below Hosts. It lists the people in your Fleet workspace, the invitations that have been sent, and what each person can reach. A workspace is one organization, so the people listed are the ones your Wazuh ID organization has in Fleet.
Any member can read the page. Only an administrator can change it: a member gets
the roster and no invite, edit or remove control, and the API refuses the same
calls with 403 and "Only an administrator of this workspace can do that."
Hiding the buttons is a convenience, not the boundary. A failed roster read says
the list is incomplete rather than showing an empty team, because "there is
nobody in this workspace" is one thing that is certainly untrue.
Inviting somebody
Invite member asks for an email address, a role, and, for a member, which hosts they get and whether they may add new ones. The form says what happens next: "They get an email from Wazuh with a link to set up their account. Nothing is shared with them until they accept it, and you can cancel it any time before they do."
Fleet does not send that email, and it cannot. Signing in to Fleet is signing in with Wazuh ID (see Sign in), and Fleet cannot create a Wazuh ID account. The invitation therefore goes to Wazuh Hub first: the Hub creates the Wazuh ID account with the inviter's organization already stamped on it, and Wazuh ID sends the branded set-up link. Only when that succeeds does Fleet record the pending invitation, with the role and grants the invitee should land with. The other order would leave an invitation for somebody who can never accept it, one that reads as sent and is not.
An invitation is valid for 14 days. The invitee follows the link, sets their Wazuh ID account up, and opens fleet.wazuh.com. On that first sign-in the pending invitation is claimed and they join your workspace with the role, the permission and the grants you chose, in one transaction. There is no separate accept button: following the invitation is the consent.
When an invitation cannot be created, nothing is recorded and the form says why. Besides the plain form checks on the address and the role, these are the outcomes worth naming:
| What came back | What it means |
|---|---|
already_in_another_org | That address belongs to a different Wazuh organization. A person can be in one organization at a time |
already_a_member | That person is already in this workspace |
too_many_pending_invites | Too many invitations are waiting to be accepted. Cancel some of them first |
unknown_environment | A host id that is not one of this workspace's is refused rather than quietly dropped |
hub_unreachable | Wazuh Hub could not be reached, so nothing was sent. No mail, and no invitation |
The two roles
Fleet's roles are its own, and are not derived from your role in the Wazuh organization.
| Role | What it can do |
|---|---|
| Admin | Every host in the workspace, implicitly. Invite people, change roles and grants, remove people, add or remove hosts |
| Member | Only the hosts granted to them. Cannot change the team. Can add or remove hosts only if Can add new hosts is ticked |
Can add new hosts is a permission rather than a role, and it is always on
for an admin. Without it, adding or removing a host answers 403, and the
console says you do not have permission to add hosts in this workspace. See
Add your first host and
Remove a host.
Per-host access
A member is granted specific hosts, one checkbox each. What they are granted is what their Hosts page shows, and the only thing they can read. The Host access column says it in words: "All hosts" for an admin, "No hosts" for a member with none, the host names for one or two, and "3 hosts" and up once the names would not fit.
An administrator with no grants has all hosts. A member with no grants has none. The two states are identical in the data and opposite in meaning, so the role decides how to read the list, never its length.
An admin holds no grants because grants for them would be a second source of truth that could disagree with the role. For the same reason, promoting a member to admin deletes their grants.
The grant is checked on every read, not only hidden from a list
Fleet enforces a grant on every request that opens a host, not only when the list is drawn. Its detail, what its connector reported, and installing a service on it each re-check two things on the server: that the host belongs to the caller's workspace, and that this member may open it. Nothing in the browser holds a Wazuh credential, as Data handling sets out.
That is what makes the checkboxes real: a grant the server did not read would be a claim the interface makes and does not keep, and typing a host id into the address bar would walk around it. Filtering the host list is a convenience on top.
A host you have not been granted answers exactly the same 404 Not found as
one that does not exist. That is deliberate: any other answer would let
somebody compare the two replies and enumerate the organization's hosts one id
at a time. The access gate uses the same body, so a stranger cannot tell "this
workspace has no such host" from "this feature is not for you" either.
A grant is permission to read, not to install
Another Wazuh product can put its own agent on the hosts your connector already runs on, as Other Wazuh products on your hosts sets out. That act writes a binary and a credential to a machine, so it needs the service to be allowed on the host first, in Fleet, on the host's Services panel, whatever grants a member holds. A granted member who connects from the other product's console before that gets one sentence from Fleet saying where to allow it. Taking such a plugin back needs membership alone, because it removes an identity rather than handing one out. The per-host grants above are honoured on that path too, so a service asking about a host on somebody's behalf gets the same answer Fleet's own console would give them.
Changing a role or a grant
The pencil on a row reopens the same form with the address fixed, and saving writes the role, the connect permission and the grants together.
The pencil stays clickable on every row, including your own and the only administrator's. What it will not accept sits on it as a tooltip, and the API is what refuses a demotion that would leave the workspace without an administrator.
The change takes effect on that person's next request. Nothing is pushed to a console they already have open, and nothing is read off the session they hold: membership and grants are re-read on every request, so a token proves somebody was admitted once, not that they still are.
Removing somebody
The confirmation says what it does: the person "loses access to this workspace on their next request. Their Wazuh account is not deleted, and you can invite them again later."
Removal drops the membership and every grant that hung off it, in one transaction, and it is Fleet-side only. Their Wazuh ID account is organization-level and may be in use by another Wazuh product, so it is not deleted, and the Wazuh organization is not told that they left.
Two rows cannot be removed, and the reason sits on the disabled button rather than in a failed request:
| Row | Reason shown |
|---|---|
| Your own | "You cannot change your own role or remove yourself." |
| The only administrator | "This is the only administrator. Promote somebody else first." |
The last administrator cannot be removed or demoted. A workspace with no
administrator can never invite, grant or remove again, and nothing outside Fleet
can repair it: Fleet's roles are not known to the Wazuh organization. The API
refuses both acts with 409 whatever the screen offered.
Invitations, and the one that stays pending on purpose
The Invitations section appears once there is at least one. An expired invitation is kept and shown rather than swept away, so a lapsed one stays visible.
| State | What the row says |
|---|---|
| pending | "Waiting for them to accept" |
| accepted | "Accepted, and now in the members list" |
| expired | "This invitation lapsed. Invite them again to send a new one." |
Cancel withdraws an invitation that has not been accepted. It drops Fleet's record, so the invitation can never be claimed, and it does not delete the Wazuh ID account created for the invitee.
Inviting a person who already has a Fleet workspace of their own leaves the invitation pending until it expires, and the page says so, which is the truth.
An existing workspace is never moved. Fleet's data is partitioned by workspace, so somebody who already has hosts would not take them along: they would stop being visible, with no error anywhere. The invitation is left unclaimed instead. Merging two workspaces is not something Fleet can do on its own, so raise it through Getting help.
Two limits worth knowing
There are no display names. Fleet stores only a member's email address, so each row shows the local part of it. Wazuh ID holds the real name, and a second copy here would go stale.
The playground has no backend. Its Team page works on an in-memory list scoped to the browser tab: inviting somebody there adds them straight to the list, no mail is sent, there is no Invitations section, and a reload restores the sample workspace. The role rules are mirrored so the playground cannot show a state the real API would refuse: an admin's grants are cleared, and the last administrator cannot be removed.