What Fleet stores

Fleet does not read what runs on the machines its connectors sit on. On a Wazuh node the installer looks, once, for the Wazuh login the host keeps, and that login stays on the host. So "what does it keep" has a short answer: the hosts you added, who is in your organization and what they may see, and what each connector reported about itself and its machine. Nothing from inside a deployment is in that list. The precise version follows, for the review a security team will ask for.

In your browser

The console is a static site with no server of its own, so what it keeps is in your browser, under the fleet.wazuh.com origin.

• The Wazuh ID session. Signing in leaves the session tokens in local storage, and the console attaches the ID token as a bearer to calls addressed to api.fleet.wazuh.com, and to nothing else. The console holds no Wazuh credential and cannot reach a deployment directly. See Sign in.
• Preferences, under wazuh-console.preferences: the theme, the background refresh interval in seconds, and whether timestamps render in UTC.
• A sign-out marker in session and local storage, with a 90 second deadline, so the end of the sign-out chain can tell that landing from an ordinary visit.

The host you are looking at is in the URL, not in storage, which is what makes a view shareable by sending a link.

In Fleet's control plane

What Fleet writes down, per organization:

What	The detail
The hosts you added	An id, the name, whether it is a machine of yours or a Wazuh Cloud environment, its status, when it was created, which connector serves it, and for a Wazuh Cloud one the id its account uses
People	Per member: the Wazuh ID subject that identifies them, the email address, the Fleet role, whether they may add or remove hosts, when they joined, and which hosts they are granted. A pending invitation holds the same, plus who invited them, an optional name typed on the invite, and an expiry
The Wazuh Cloud pairing	Which account this workspace is paired to, the address it was paired at, that account's own identifiers, and how and when it was paired. A pairing still in progress holds the address, a hash of the emailed code, its expiry and the number of attempts, and is cleared once it is used. No Wazuh Cloud password and no API key
The token that enrols a connector	Its hash only, with an expiry and whether it was redeemed. The token itself is shown once, when you generate it, and is not kept
What each connector said about itself	Its version, last heartbeat, certificate serial and expiry; and about the machine, the hostname, operating system, architecture, distribution, kernel and process start time, how the connector is supervised and whether it can host services
What Fleet was asked to install	Per host and service: whether it should be installed or removed, when that was asked and by whom. See Other Wazuh products on your hosts
What each plugin said about itself	Its installed and running versions, its own state word, whether it is alive, and its status document as it wrote it
Update settings and outcomes	Whether a host may update itself and which rollout ring it is in, any version pinned for it with who asked and any note they left, and how its last update went

Two more things are written down per organization and are not in that table. The organization id Wazuh ID issued is kept, because it is how another Wazuh product asks Fleet about the right workspace at all; and a binding one of those products asked for has its own section below, because it carries a credential.

The heartbeat carries no CPU figures, no disk usage and no process list, and it reports nothing about what the machine runs beyond the services Fleet installed on it. See What the connector is.

Some of those fields are free text from inside your network

A failed local probe stores the connector's own error, which can name a local address; it is shown only as a tooltip. A plugin's status document is stored as the plugin wrote it, so any error text it puts there is stored too. And a plugin that is not alive has the last 20 lines of its own systemd unit journal attached, only in that case.

Nothing from inside your deployments

Fleet does not read the deployments its connectors sit on, so there is nothing from inside one for it to keep. The console holds no Wazuh credential and the connector carries no path into your Wazuh. What a deployment contains is read by a service you allow on the host, working with its own credentials and reporting to its own product, and that is where the history of it lives, not in Fleet.

In your own network

A service allowed on a host keeps its own credentials on that host, under its own account, and reaches its own upstream from inside your network. Those credentials are never sent to Fleet, and Fleet cannot change them. The connector's own configuration lives in /etc/fleet-connector/connector.yaml, mode 0600, on the host. See Connector configuration.

On a Wazuh node the installer also finds the login Wazuh keeps there and writes it to /var/lib/fleet-connector/discovered-login.json, owned by root at 0600. The connector copies it into the files of each service installed on that host through Fleet, and nowhere else. It is not in the heartbeat, not in any log line and not in Fleet's control plane. Deleting the file with --no-discover stops delivery and revokes nothing: a service that already took the login keeps it until a login is set from that service or the service is removed. See The Wazuh login the installer finds.

A Wazuh Cloud environment's dashboard login is fetched from your Wazuh Cloud account when you ask for it, and Fleet stores no Wazuh Cloud credential of its own. See Wazuh Cloud environments.

What crosses the wire

The connector holds one outbound mTLS session to Fleet, and two things travel on it. Out, a heartbeat every 30 seconds carrying the connector's id and version, the host's name and platform, and the status of each service on it. Back, Fleet's answer, which may ask the host to install or remove a service or move to a newer connector version. No credential of yours crosses either way, because the console holds none and the connector opens no path into your Wazuh.

When Fleet has a control-plane message for a host, such as closing a removed host's session, its API signs the message with HMAC-SHA256 over a canonical string, using a key shared only with the connector gateway. The gateway recomputes it and refuses anything that does not match. Neither the API nor the gateway stores any part of what the machine holds, because none crosses this path.

The one credential Fleet holds and does not own

When another Wazuh product is connected to one of your hosts, it mints an enrolment token for its own plugin and hands it to Fleet to carry there. It waits only because that host may be rebooting.

• It is encrypted before it is stored, and there is no unencrypted path. With no key available the call is refused with 503 and nothing is written. There is no plaintext field for it and no debug switch.
• The encryption is bound to your organization, which travels as authenticated context beside the ciphertext, so a record copied out of your workspace does not decrypt for anybody else, even for something holding the key.
• Fleet holds it for at most an hour. Past that, every reader refuses it, so the stored row is already inert. A sweep then deletes it: once the host has taken it, and once the hour is up whether or not anybody took it.
• It is delivered once. The gateway holds it in memory and attaches it to the host's next reply, and the connector keeps a root-owned note of the hand-over, because the plugin deletes the token after enrolling. On the host it is 0600, owned by that plugin's account.

Fleet never holds the identity the product then issues. The plugin reports what kind of identity it is, its id and when it expires, so a lapse can be seen coming, and the contract forbids a plugin's secret in that report. The identity itself is minted, rotated and revoked in that product's own console.

One organization cannot see another's

A workspace is one organization. Every row Fleet stores is stamped with the workspace it belongs to, and the boundary is enforced by the database underneath the application rather than by the code above it: a query that forgot to name a workspace returns nothing rather than somebody else's rows, and Fleet's API connects with an identity that cannot override that.

Inside a workspace, access is per host and is checked on every request that opens one rather than only when a list is drawn. A host you have not been granted answers exactly the same 404 Not found as one that does not exist, so the reply cannot be used to enumerate what an organization has. See Team and access.

What a removal deletes

Removing a host deletes everything Fleet holds about it, in one transaction: the registry entry, its connector registration, any enrolment token for it, the per-member grants, its update record and any version pin, the plugin records on both sides, and any binding with the credential it was still carrying. Once that has committed, the session the connector is holding right now is closed and its next dial is refused. It deletes nothing inside your network, and for a Wazuh Cloud environment it asks Wazuh Cloud to retire the connector it deployed. See Remove a host.

Removing a person drops their membership and their grants together, and takes effect on their next request. It does not delete their Wazuh ID account, which is not Fleet's to delete.

playground.fleet.wazuh.com sends nothing anywhere: it is the same console built with no backend and no sign-in, every figure generated in your browser from fictitious data. It keeps the same browser-side items as the console does, and nothing else, because there is nowhere else for it to put anything. For what Fleet can and cannot do to a deployment, read What Fleet can do.