Workstation baseline
Required for every deployment.Code signing
On Windows, the installer and all bundled binaries are signed with an Authenticode certificate. IT teams that enforce execution policy through AppLocker, Windows Defender Application Control, or signature-based EDR rules should permit binaries signed by the Cosmon publisher certificate. On macOS, the app bundle and every binary inside it are signed with an Apple Developer ID certificate and the build is notarized by Apple, so Gatekeeper opens it without an “unidentified developer” prompt. IT teams that restrict launches through MDM or an EDR policy should permit software signed by the Cosmon Developer ID. On Linux there is no Authenticode equivalent, so the AppImage is unsigned. Integrity is verified instead through the SHA-512 digest published alongside each release, which the built-in updater checks before applying any update. IT teams that require a signature check at execution time should allowlist the AppImage by digest.Process spawning
The desktop application is the parent process. While Argus is running, it spawns and supervises two child processes: the agent runtime and the tool server. EDR and behavior-monitoring tools (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Carbon Black, and equivalents) may flag this parent-child pattern. The Cosmon parent process should be allowlisted to spawn its child binaries. The bundled runtime also includes a Python interpreter that ships inside the application package; allowlist it as part of the Cosmon process tree.Local network — loopback port binding
The three processes communicate over127.0.0.1 (loopback) on randomly assigned ports. Windows Defender Firewall, or any host-based firewall, must permit the Cosmon binaries to bind loopback ports.
No ports are exposed on external network interfaces, and the application accepts no inbound connections from the network.
File system
The application reads and writes its data under the user’s app data directory. Standard user permissions are sufficient — administrator privileges are not required to install or run Argus.Outbound network
Required only when one or more backend connections are enabled (see Architecture overview). A fully airgapped deployment — machine-locked license, BYOK to an internal endpoint, telemetry off, traces off — requires no outbound network rules.Egress rules per connection
For shared-tenant deployments, the backend destination is
desktop-api.cosmon.com; analytics and the update download use the fixed hosts above. For single-tenant or customer-hosted backends, the backend destination is replaced by the customer-specific URL. See Data handling for what each connection carries.
In BYOK mode, IT must permit egress to the customer-chosen LLM endpoint. Cosmon does not place any other constraint on that endpoint.
Proxy
Argus reads proxy configuration from the standard environment variables. There is no application-specific proxy configuration to set inside Argus.
If the proxy presents a custom root CA (TLS inspection), see TLS inspection and corporate certificate trust — the CA must be installed in the OS certificate store, not configured inside Argus.
TLS inspection and corporate certificate trust
Argus trusts the operating system’s certificate store. If the corporate environment performs TLS inspection through a proxy with a custom root CA, that CA must be installed in the Windows certificate store. Once installed at the OS level, no Cosmon-specific configuration is needed.Streaming connections (SSE)
For shared-tenant and customer-hosted deployments, Argus opens a Server-Sent Events (SSE) stream to the backend so that model output appears incrementally as the agent runs. Some VPN and forward-proxy products (Netskope, Zscaler, and similar) buffer or aggregate streamed responses by default, which causes Argus to receive the full response only after the model has finished rather than token by token. If a VPN or inspecting proxy is in the egress path, SSE responses must be passed through without buffering — no man-in-the-middle aggregation oftext/event-stream bodies. The built-in network diagnostics (see Diagnostics) verifies this end-to-end.
Identity
Required only when authorization is set to a named license (SSO) or a floating license. Skip this section if all users are activated with machine-locked licenses.OAuth sign-in flow
When a user signs in, the desktop application opens the user’s default browser to the Cosmon sign-in page. After the user authenticates, the browser redirects to a localhost callback URL that the desktop application listens on for the duration of the sign-in.Federated SSO
Enterprise customers can federate sign-in to their own identity provider (Okta, Microsoft Entra ID, Google Workspace, etc.) over OpenID Connect. Your IdP admin registers Cosmon as an OIDC client; Cosmon maps your email domains to that provider. This is configured once per organization and is not a per-workstation concern. For the sign-in flow, the redirect URI, required claims, and the enrollment steps, see Single sign-on. The user’s browser must be able to reach the following during sign-in, in addition to the backend host in the egress table above:
The sign-in page also contacts the following. Sign-in works without them:
Engineering software access
Required for every deployment that uses CAD or CAE integrations. The tool server drives the engineering software installed on the same machine. To do that, IT must permit two patterns. Spawning third-party CAD/CAE processes. The tool server starts the engineering application’s executable (or attaches to an already-running instance). EDR will see the Cosmon tool server spawning a third-party binary likeabaqus.exe, SLDWORKS.exe, or ANSYS.exe. The tool server should be allowlisted to spawn these binaries.
Loading a Cosmon-shipped plugin inside the host application. Each integration ships with a plugin — a DLL, add-in, or script extension depending on the host — that loads into the CAD/CAE process. The plugin binds a loopback port and receives commands from the tool server. Both the plugin loading into the host process and the loopback bind must be permitted.
Runtime-generated automation executables. Some integrations rely on automation executables that the host application generates at runtime (for example, SolidWorks COM automation helpers). These appear in a per-user folder and are not signed by the host vendor, so antivirus and EDR may quarantine them on creation or first execution. The folder used for these helpers should be added to the AV/EDR exclusion list, or the Cosmon tool server permitted to launch unsigned children of that folder.
Diagnostics
Argus ships a network diagnostics panel under Settings → Network. IT can use it to verify, from the user’s machine, that:- DNS resolves and TLS handshakes succeed against every required egress destination (auth, LLM routing, telemetry, traces).
- Streaming responses (SSE) arrive token by token rather than buffered into a single late response — the test that catches VPN/proxy buffering described in Streaming connections (SSE).
- Loopback ports between the desktop application, agent runtime, and tool server bind without firewall interference.