Prepare authorized Linux agent removal before enabling Wazuh validation

Bottom line: Prepare the authorized removal workflow before enabling validation. Keep a manager-approved package uninstall separate from a broad claim that every form of agent tampering is prevented.

Source fact: documented behavior

The Anti-tampering guide limits the feature to Linux endpoints and requires manager validation before the protected agent package is uninstalled.

It supports either centralized group configuration or local agent configuration for enabling package-uninstallation validation.

For authorized removal, the guide recommends a temporary authentication token instead of storing server API credentials on the monitored endpoint.

What the source does not establish

This article concerns the documented Linux package-removal control. It does not establish protection against every local administrator action, stopping a service, deleting files outside the package workflow or use on another operating system.

Applicability questions

• Which Linux endpoints and configuration authority are in scope?
• Who can authorize removal through the manager?
• How will a temporary token reach the authorized operator?
• What recovery process applies when removal validation fails?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a rehearsed authorized-removal procedure and controlled temporary-token handling before enabling the package validation requirement.

1. Identify the endpoint population and choose whether the setting is managed centrally or locally. Keep that choice with its responsible owner so removal staff know which configuration to review. Prepare an approved disposable Linux agent for the first exercise, and preserve a management path for recovering from a mistaken configuration before extending the setting to other endpoints.
2. Design the authorized removal handoff using the documented temporary-token method and the organization’s current transport-verification policy. Keep tokens and API secrets out of ordinary tickets, screenshots and shared test fixtures. Name the administrator who obtains the token and the operator who uses it. Do not copy the source’s example connection settings as an unexplained production trust policy.
3. Write the expected handling for a missing validation configuration and an authorization failure. Review the source’s applicable removal workflow with the endpoint owner instead of inventing a bypass. If manager validation is unavailable, stop and use the established recovery authority. Do not describe manually erasing agent files as a successful test of the package-uninstallation feature.

Verification and evidence

Proposed verification: on the disposable agent, observe the intended setting and the authorized package-removal path using a temporary token obtained through the reviewed process. Preserve redacted validation and package-operation results. Exercise a rejected authorization case only in the approved test arrangement and keep it separate from the successful removal record.

Confirm that retained evidence contains no reusable token or API password and that the temporary test identity is handled through its normal lifecycle. Record unresolved manager-connectivity or authorization problems with their owner. No agent was removed or tamper attempt performed for this article; acceptance would concern only the tested Linux package workflow, not universal endpoint resistance.

Official references

• Anti-tampering — Wazuh; official product documentation.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.