EDR and SIEM Onboarding

Patch management agents legitimately do things that endpoint security products watch closely: they download executables, install software with elevated privileges, modify policy, create scheduled tasks, and restart machines. If your organization runs an EDR, SIEM, or a security operations center, this page gives your security team what they need to positively identify the TridentStack Control agent on each platform, understand which behaviors are expected, and write precise, minimal trust rules instead of broad exclusions.

If you see agent behavior that is not listed here, treat it as unexpected and investigate it like any other alert.

Network profile (all platforms)

Agents hold a single persistent outbound TLS connection to gateway.tridentstack.com on port 443 and make HTTPS requests to your TridentStack Control server addresses. Update payloads download directly from the platform vendor (for example *.download.windowsupdate.com and *.delivery.mp.microsoft.com on Windows, Apple's software update CDN on macOS, your configured package mirrors on Linux) and from the relevant package sources for third-party applications. The agent never listens on inbound network ports on any platform.

The agent on Windows

Binaries and signing

Every executable TridentStack Control ships for Windows is Authenticode-signed and timestamped. Verify the signature chain rather than trusting file names or paths alone.

Property	Value
Signer subject	CN=TridentStack LLC, O=TridentStack LLC, L=Saratoga Springs, S=Utah, C=US
Issuer	Microsoft ID Verified CS EOC CA 04 (Azure Trusted Signing)

Executable	Location	Role
TridentStack-ControlService.exe	C:\Program Files\TridentStack Control\	Windows service. Supervises the agent and maintains the server connection.
tridentstack-core.exe	C:\Program Files\TridentStack Control\bin\	Agent engine. Runs the persistent daemon and per-operation work (update checks, installs, inventory, telemetry).
tridentstack-updater.exe	C:\Program Files\TridentStack Control\bin\	Agent self-update helper.
TridentStack-Control.exe	C:\Program Files\TridentStack Control\	Desktop status app. Runs only in logged-in user sessions.
result-writer.exe	C:\Program Files\TridentStack Control\	Helper for per-user application installs.

Signer-scoped rules survive agent updates; file-hash rules do not, because every release is a new build. If your EDR supports trusting a signer, prefer that over per-hash allowlisting.

Process tree

• services.exe starts TridentStack-ControlService.exe (the service, running as SYSTEM)
• The service starts tridentstack-core.exe agent run-daemon (the persistent agent)
• The engine starts short-lived children per operation: Microsoft installers (wusa.exe, msiexec.exe, update packages), package manager operations, and OS query tools

Expected behaviors

Behavior	What it looks like	When it happens
Update downloads	tridentstack-core.exe writes installers under C:\ProgramData\TridentStack Control\downloads\	Update installs and pre-staging ahead of maintenance windows
Windows update installation	The engine runs wusa.exe, DISM servicing, or the Microsoft-signed update package as SYSTEM	Approved system update installs
Malicious Software Removal Tool updates	The engine runs the Microsoft-signed KB890830 package with its quiet switch; that Microsoft process writes C:\Windows\System32\mrt.exe, runs a quiet scan, and logs to C:\Windows\Debug\mrt.log	Monthly MSRT releases, when approved
Application installs and updates	Package manager operations and vendor installers run as SYSTEM; installs that must run in a user context use a one-time scheduled task under \TridentStack\PerUserInstall\ plus result-writer.exe, launched in the target user's session	Approved application updates
Third-party installer resume hooks	Some application installers stage a self-contained copy of themselves under C:\ProgramData\Package Cache\{GUID}\ and register a transient RunOnce value (for example HKLM\...\CurrentVersion\RunOnce, calling the cached installer with a resume switch) so the install can continue across a restart, clearing it on completion. This is the vendor installer's own behavior, performed identically under any deployment tool (or a manual double-click); TridentStack Control only launches the installer	Approved application installs that use self-contained bootstrapper installers, such as the .NET SDK/runtime
Policy enforcement	Writes to C:\Windows\System32\GroupPolicy\ (Registry.pol) and policy registry keys under HKLM	Configuration policy deployment
Security posture collection	Read-only runs of OS query tools such as secedit (security policy export), w32tm (time service), reagentc (recovery environment), plus scheduled task, certificate store, and file permission enumeration	Compliance and telemetry collection cycles
Agent self-update	tridentstack-updater.exe runs msiexec /i on a signed MSI from C:\ProgramData\TridentStack Control\downloads\agent-updates\, replacing the agent binaries and restarting the service	Agent version rollouts
System restarts	Restart initiated by the agent as SYSTEM	Only per your update policy and restart windows

Two things the Windows agent deliberately does not do, which your security team can treat as tripwires: it never writes executables into OS system directories from its own process (Microsoft installers perform their own file placement), and it never injects code into other processes.

The agent on macOS

Binaries and signing

All macOS binaries and the installer package are signed with an Apple Developer ID for TridentStack LLC (Team ID 2T8VBB5XQB) and notarized by Apple. The agent refuses to self-update from a package that fails Apple's Developer ID and notarization checks.

Component	Location	Role
tridentstack-agent	/usr/local/sbin/	The agent daemon (universal binary), runs as root
TridentStack Control.app	/Applications/	Desktop status app, runs only in logged-in GUI sessions

Process model

• launchd runs the daemon as the LaunchDaemon com.tridentstack.agent (/usr/local/sbin/tridentstack-agent daemon, root, kept alive)
• launchd runs the status app as the LaunchAgent com.tridentstack.ui in each logged-in user's GUI session
• The daemon and the app communicate over a local Unix socket at /var/run/tridentstack/ui.sock; there is no network channel between them
• Data and logs live under /Library/Application Support/TridentStack/, /var/lib/tridentstack/, and /var/log/tridentstack/

Expected behaviors

Behavior	What it looks like	When it happens
OS update installation	The daemon runs Apple's softwareupdate; major version upgrades are downloaded and staged first, then committed in a second step, with staged content under /var/lib/tridentstack/staged-os-installs/	Approved system update installs
Application installs and updates	installer -pkg for package installers; disk images and archives are handled with hdiutil and ditto; Homebrew operations run as the logged-in console user via sudo -u because Homebrew refuses to run as root	Approved application updates
Pre-install verification	The daemon runs codesign --verify and spctl --assess against every downloaded application before installing it, and rejects software that fails Gatekeeper assessment	Every third-party application install
Credential storage	Keychain reads and writes through the security command	Agent enrollment and startup
Posture and inventory collection	Read-only runs of system_profiler, softwareupdate --history, lsof, ps, scutil, ioreg, sysctl, and code-signature inspection of installed apps; the daemon also reads Apple's /var/log/install.log	Compliance and telemetry collection cycles
Agent self-update	The daemon downloads a signed .pkg over a certificate-pinned TLS connection, verifies its SHA-256 hash, then runs /usr/sbin/installer -pkg ... -target /, which enforces the Developer ID signature and notarization; launchd restarts the new daemon	Agent version rollouts
User notifications and restarts	Restart prompts through the status app or osascript; restarts via /sbin/shutdown as root	Only per your update policy and restart windows

The agent on Linux

Binary and integrity

Linux has no platform-wide binary signing equivalent to Authenticode or Developer ID, so identify the agent by its installation path, service unit, and delivery chain. Agent builds are GPG-signed at build time and TridentStack Control verifies that signature before a build can be distributed to agents; endpoint-side installs and self-updates additionally verify a SHA-256 checksum of the binary delivered over TLS (self-updates over a certificate-pinned connection).

Component	Location	Role
tridentstack-agent	/opt/tridentstack/bin/	The only agent binary. No UI, no helper processes.
tridentstack-agent.service	systemd unit	Runs /opt/tridentstack/bin/tridentstack-agent daemon as root, auto-restarts

Configuration lives in /etc/tridentstack/, working data in /var/lib/tridentstack/, logs in /var/log/tridentstack/ and the systemd journal.

Expected behaviors

Behavior	What it looks like	When it happens
Package installs and updates	apt-get and dpkg-query on Debian and Ubuntu; dnf and rpm on RHEL-family systems, all as root	Approved package updates
Restart-requirement detection	needrestart (Debian/Ubuntu) or needs-restarting (RHEL family), plus kernel version comparison	After installs and during telemetry cycles
Posture and inventory collection	Read-only runs of dpkg-query/rpm, lspci, lsblk, dmidecode, sysctl -a, ss, uname, and systemctl listings; firewall state reads through ufw, firewall-cmd, nft list, or iptables -L (list operations only, the agent does not change firewall rules); an outbound curl for public IP discovery	Compliance and telemetry collection cycles
Agent self-update	Downloads the new binary to /var/lib/tridentstack/downloads/, verifies its SHA-256 checksum and file format, replaces /opt/tridentstack/bin/tridentstack-agent (keeping a .backup copy for rollback), and restarts its own systemd unit	Agent version rollouts
System restarts	/sbin/shutdown -r as root	Only per your update policy and restart windows

Tuning guidance

• Scope rules to the strongest identity each platform offers, plus the install paths. On Windows: the TridentStack LLC Authenticode signer with C:\Program Files\TridentStack Control\ and C:\ProgramData\TridentStack Control\. On macOS: Developer ID Team ID 2T8VBB5XQB with /usr/local/sbin/tridentstack-agent and /Applications/TridentStack Control.app. On Linux: the executable path /opt/tridentstack/bin/tridentstack-agent running under the tridentstack-agent.service systemd unit. Avoid directory-only exclusions, which anything on the machine could plant files into.
• Do not disable detection for system folder writes. The agent does not require it on any platform. Where OS files change (for example mrt.exe during Windows MSRT updates), the write is performed by the platform vendor's own signed installer process, the same write your EDR sees from native OS updates.
• Keep scanning the download directories. C:\ProgramData\TridentStack Control\downloads\ and /var/lib/tridentstack/downloads/ hold real installers; letting your EDR scan them costs little and preserves defense in depth. Hash verification happens independently inside the agent before anything executes.
• Baseline the process trees. Alerting on deviations from the ancestries above (for example, tridentstack-core.exe spawned by anything other than the service, or tridentstack-agent running from a path other than its install location) is a better use of detection engineering than suppressing the agent wholesale.
• Expect one new binary set per release. Agent updates are staged rollouts of newly built, newly signed binaries. Reputation-based analytics may score the first sighting of a new version as rare. The signature chain (Windows, macOS) and install path plus delivery chain (Linux) are the stable identities across releases.

If your security operations team needs additional detail about a specific observed behavior, contact TridentStack support with the process names, command lines, and timestamps from the alert.