Agent Architecture

Every Moftgate agent checks in with the server on a regular schedule called a heartbeat. On each heartbeat the server decides what the agent should do: which settings to apply, which DLP policies to enforce, which modules to run, and which custom fields or update exclusions to honor. This guide explains those decisions from an administrator’s perspective so you can configure agents confidently.

Configuration is delivered through three layers that run in order on every heartbeat: first the server picks the active profile for that endpoint, then it filters DLP policies by target scope, and finally it merges the chosen profile with the tenant defaults. License checks run alongside this flow so unlicensed features are never sent to the agent.

An agent profile is a reusable bundle of settings - DLP toggles, USB rules, web content gateway options, file integrity monitoring paths, and more. Instead of configuring each endpoint individually, you create a handful of profiles that match your device roles (for example "Finance laptops", "Kiosk terminals", "Developer workstations") and assign one profile to each endpoint.

When an agent registers for the first time, it is automatically assigned the default profile. If you have marked a profile as the default, that one is used; otherwise the oldest profile is used as a fallback. You can reassign the profile at any time from the endpoint detail page.

1. 1
   Open the endpoint detail page

   Navigate to Fleet Intelligence, open the endpoint you want to configure, and locate the Agent Profile selector.

2. 2
   Choose a profile

   Select the agent profile that matches the device role (e.g. "Finance laptops", "Kiosk terminals"). The change takes effect on the next heartbeat.

3. 3
   Verify in the agent cache

   On the endpoint, run "agent --profile" to confirm the cached settings, DLP policies, and active modules match what you configured.

Close image

Target scope decides which endpoints a profile or policy applies to. When the server selects the active profile for an endpoint, it walks a priority ladder from most specific to least specific. The first scope that matches wins, and lower-priority scopes are ignored for that decision.

The priority order, from highest to lowest, is: endpoints, then users, then groups, then profiles, then all. In plain terms: a rule aimed at a single device beats one aimed at a person; a person beats a group; a group beats a profile; and a profile beats a blanket "everyone" rule.

Groups let you target policies and profiles at collections of devices or people. Moftgate keeps two independent kinds of group membership: endpoint groups (which devices belong together, e.g. "IT servers", "Accounting workstations") and user groups (which people belong together, e.g. "Contractors", "Executives").

When a policy uses the "groups" scope, the server checks both kinds of membership: if either the endpoint or its currently logged-in user belongs to at least one of the selected groups, the policy applies. This OR logic means you can target a policy at "anyone in the Finance group or any device in the Finance group" with a single rule.

• Endpoint groups are great for device-role policies (e.g. enforce strict USB blocking on kiosk terminals).
• User groups are great for person-based policies (e.g. allow clipboard transfer for executives regardless of which laptop they use).
• A single endpoint can belong to many groups, and a single user can belong to many groups.

DLP policies are filtered by target scope on every heartbeat, so each agent receives only the policies relevant to it. The same five scopes are used, with one important detail for the "groups" scope: it matches if the endpoint belongs to a selected group OR the logged-in user belongs to a selected group.

What an agent actually does is gated by two things: whether your license includes the module, and whether the module is enabled in the endpoint’s active profile. Both must be true for the feature to run. This two-layer check prevents unlicensed features from being sent to the agent and lets you turn off a module per profile even when it is licensed.

On every heartbeat the server sends the agent a short list of active modules. The agent only starts the background tasks for modules in that list - it will not track clipboard or USB for DLP if DLP is inactive, will not watch files for integrity monitoring if visibility is inactive, and so on. This keeps idle agents lightweight.

• Heartbeat always works, even with no license, so the agent stays visible in the panel.
• If no license file exists, all modules are closed and the agent does nothing beyond heartbeat.
• A module disabled in the profile is not sent to the agent, saving CPU, memory, and network.
• When the license changes, the active module list updates on the next heartbeat.

Custom fields and KB (knowledge base) exclusions are delivered to agents with the same target-matching logic as policies. Each custom field or exclusion can be scoped to all endpoints, a group, a profile, a tag, or a single endpoint, so agents only receive what applies to them.

Custom fields let you collect extra metadata from each endpoint (for example "Cost Center", "Department", "Asset Tag"). The agent gathers known values like hostname, OS, and username automatically and uses the default value for anything else, then reports the values back to the server on every heartbeat.

KB exclusions tell the agent which OS updates to skip. When the agent is about to install an update, it checks the exclusion list first; any excluded update is skipped and logged. Exclusions can also be filtered by operating system type, so a Windows-only exclusion never affects a macOS agent.

For advanced users and support engineers, the agent ships with a small set of command-line flags. These are useful for diagnosing what an endpoint is actually doing and for testing DLP rules against a file before rolling out a policy.