What is Vesper?

Vesper is the Wazuh Labs support service, live at vesper.wazuh.com. It does three related things:

1. Answer it. Anything about installing, configuring, tuning or troubleshooting Wazuh. Vesper retrieves the most relevant material from its corpus and generates a structured answer grounded in it, showing its sources. It reads the corpus and reaches no customer machine at all. Asking happens on the Answers page, which the Overview's Ask a question panel opens.
2. Look into it. A question about one registered deployment, with no intention of changing it. "How is the manager doing?", "what stopped reporting?", "why did alerts drop?". The agent reads that environment live through the connector and answers. It is not given the command tool, so that question cannot change the machine. The choice is made per message, so a later one in the same chat can be sent as a fix.
3. Fix it. The same agent, allowed to act. It inspects agents and indices, diagnoses misconfigurations, and applies fixes when the environment's mode allows it.

Looking and fixing are the same agent on the same environment. What separates them is one property of the conversation, described in The Vesper agent.

Vesper is in closed beta. Access is granted per organization, and nothing is charged during the beta. The console can be seen without an account in the playground, a public read-only demo running on fictitious data.

How answering works

Vesper is a retrieval-augmented generation (RAG) service. Its corpus holds years of resolved community support conversations, from the Wazuh Slack, Discord, Google Groups and GitHub. All of it is stripped of personal identities and embedded into a vector index. When a question arrives:

1. The question is embedded with the same model used for the corpus.
2. The most similar material is retrieved from the index.
3. A generation model writes the answer using only that material as context, in a consistent Summary, Diagnosis, Steps and Verification format.
4. The answer comes back with its sources and their similarity scores, so its grounding can be judged rather than taken on trust.

No customer data is ever ingested into that corpus. See The knowledge corpus for what goes in and what never does, and Reading answers for how to read one.

Answers are generated, so they can be wrong. The sources and scores are there to be checked.

How agentic support works

The agent runs a tool-use loop against registered environments. Each environment is a Wazuh deployment with a connector installed on it. The connector dials out to Vesper over mTLS, so nothing in the customer's network needs to be exposed, and it relays read queries to the local Wazuh indexer and API, plus only the writes that were explicitly allowed.

Every environment has a mode ceiling that an admin controls:

Mode	What the agent may do
Read only	Inspect and answer. No changing action is ever applied, though read and diagnostic shell commands do run on the host.
Manual	Propose changes. Each one waits for an admin's approval in Changes.
Auto	Apply validated changes on its own, still recorded in the ledger.

That ceiling belongs to the environment. It is set by an admin and shared by everyone on the team, so it answers "what may happen to this machine", not "what is this conversation for". Look into it answers the second question: it starts a conversation that is look only whatever the environment is set to, and nobody raising the ceiling while it runs can widen it. Choosing to look is not an admin decision, because asking to do less never needs permission.

The mode is one of five independent gates in front of any change. The others are that the conversation must not be look only, that the operator must be an admin, that the connector must have the capability enabled on the host, and that the connector refuses catastrophic commands outright. The Vesper agent sets them all out.