Agent settings

You can access agent-related settings by navigating to Administration > System Settings > Agents.

To automate changes to these settings, use the Workload Security API. For more information and examples, see Configure Policy, Computer, and System Settings.

Agent-initiated activation (AIA)

In addition to activating new agents in Workload Security (such as via a cloud connector or manually adding a new computer on Computers), you can also allow agents to automatically activate themselves. For more information, see Activate and protect agents using agent-initiated activation and communication.

Allow Agent-Initiated Activation: Allow agents to connect to Workload Security to activate themselves. Then select which computers are allowed to perform agent-initiated activation:

For Any Computers: Any computer, whether it is already listed on Computers or not.
For Existing Computers: Only computers already listed on Computers.
For Computers on the following IP List: Only computers whose IP address has a match on the specified IP list.

Configure initiation behavior:

Policy to assign (if Policy not assigned by activation script): Security policy to assign to the computer during activation. This setting only applies if no policy is specified in the agent's activation script or an AIA event-based task.
Allow Agent to specify hostname: Allow the agent to specify its hostname by providing it to Workload Security during activation.
Allow Virtual Desktop Infrastructure (VDI) support: Enable VDI support to lock system settings. Applicable to the VDI environment and cloned agents.
If this setting is enabled and you do not want agents upgraded automatically, do the following:
1. Navigate to Administration > System Settings > Agents > Agent Upgrade.
2. Disable Automatically upgrade agents on activation for the corresponding operating system. For details, see Automatically upgrade agents on activation.
If a computer already exists: Handle the activation attempt if the new computer is trying to use the same agent GUID or certificate, or has the same BIOS UUID as an existing computer:
- Do not allow activation: Do not activate the computer.
- Activate a new Computer with the same name: Create a new computer object and activate the computer. Use this option if you are activating clones with the same BIOS UUID, so that each cloned machine has its own computer object. Note that deactivating and reactivating the same computer creates a new computer object, resulting in the previous computer object becoming inactive permanently.
- Re-activate the existing Computer: Keeping the same name, reuse the existing computer object and activate the computer. If you are activating multiple computers with the same BIOS UUID, they will all share the same computer object, which can cause issues where a unique identifier is needed.

This setting only applies to physical computers, Azure virtual machines (VMs), Google Cloud Platform (GCP) VMs, or VMware VMs. Note that AWS provides a unique instance ID that Workload Security uses to differentiate all AWS instances, so this setting is ignored for those computers.

Reactivate cloned Agents: Reactivate clones as new computers; assign the the policy selected in Policy to assign (if Policy not assigned by activation script). This can be useful when re-imaging computer hard disks, or deploying new VM instances or AMI using a "golden image" that has an already-activated agent. It ensures that each computer has a unique agent GUID, despite being deployed by copying the same software image.

Clones are detected after the initial activation, during their first heartbeat. If the same agent GUID is being used on different computers, Workload Security detects the clones and reactivates those computers.

If you disable this option, clones will not be automatically reactivated. You need to activate them either manually through the Workload Security console or via an activation script.

This setting only applies to AWS instances, Azure VMs, GCP VMs, or VMware VMs that you added via Computers > Add Account.
Reactivate unknown Agents: Reactivate deleted (but previously activated) computers as new computers if they connect again. The original computer's assigned policies or rules will not be assigned to the computer again by default. You should assign it again manually or use a tool such as an event-based task to assign it automatically. This setting is useful together with inactive agent cleanup: any accidentally removed computers can automatically re-activate. See also Automate offline computer removal with inactive agent cleanup.

Previously known agents are detected after the initial activation, during their next heartbeat. If a heartbeat has an agent GUID (indicating prior activation) but its computer is not currently listed on Computers, Workload Security reactivates the computer.

Note that previous event messages still link to the old computer object, as opposed to the new one.

Agent upgrade

Automatically upgrade agents on activation: During activation, upgrade the agent to the latest software version that is compatible with Workload Security. This is only applicable to Linux computers. See also Automatically upgrade agents on activation.

Inactive agent cleanup

If you have many offline computers (that is, they are not communicating with Workload Security), and they do not need to be managed anymore, you can automatically remove them from Computers via inactive agent cleanup. This setting is useful in conjunction with reactivating currently unknown agents. See also Automate offline computer removal with inactive agent cleanup.

Delete Agents that have been inactive for: The amount of time a computer must be inactive in order to be removed.

Data privacy

Allow packet data capture in network events: This setting determines whether the agent captures and sends packet data to Workload Security as part of Intrusion Prevention and Firewall events. The options for this setting are as follows:

Yes (excluding encrypted traffic): All unencrypted packet data is sent to Workload Security. This is the default option.
Yes (all traffic): All packet data is sent to Workload Security, including encrypted packet data. The resource requirements for capture of packet data on encrypted connections is higher than for unencrypted connections. If you select this option and encounter problems with performance on your workloads, consider switching to the option that excludes encrypted traffic.
No: Packet data is not captured or transmitted from the agent to Workload Security. Customers in regulated environments or who are concerned about the transmission of network content to Workload Security can disable this setting. For more information about data transmitted to Workload Security, see the Trend Cloud One - Endpoint & Workload Security Data Collection Notice.

Note that this feature is supported with most agent versions 12.5.0.1001 or later, but is not supported on macOS agents.

Allow user name capture in network events: Determines whether or not the agent captures and sends packet data with detected user name to Workload Security as part of Firewall events. The options for this setting are as follows:

No: User name of packet data is not captured or transmitted from the agent to Workload Security. If you are in a regulated environment or concerned about the transmission of network content to Workload Security, you can disable this setting. For more information about data transmitted to Workload Security, see the Trend Cloud One - Endpoint & Workload Security Data Collection Notice. This is the default option.
Yes: User name of packet data is sent to Workload Security.

Note that the user name in a packet data is supported on Windows and Linux for most Deep Security Agent versions starting from version 20.0.1-12150. However, it is not available in all regions. To use this functionality, contact Trend Micro.