> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cosmon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data handling

> What data Argus keeps on the workstation, what leaves it and where it goes, what Cosmon stores per plan, and who at Cosmon can access it.

This page is written for security reviewers. It describes every path by which data can leave an engineer's workstation, what Cosmon does with it, and the controls on Cosmon's side. For the connection model and deployment topologies see [Architecture overview](/architecture/overview); for network allowlisting see [IT prerequisites](/architecture/it-prerequisites).

## What stays on the workstation

Argus is a desktop application. It stores its working data in the user's application data directory, readable only by that operating system user and covered by whatever disk encryption and endpoint policy the workstation already has.

The following are never transmitted by Argus, in any deployment mode:

* CAD models, assemblies and drawings
* Simulation input and output files
* The local databases holding chat history and agent state

Conversation content itself does leave the workstation on two connections, the model request and history sync, described in the next section.

The application accepts no inbound network connections and listens only on the loopback interface.

## What leaves the workstation

Every outbound connection is listed below with what it carries. "Content" means the text of the conversation and the results of tool calls, which can include model parameters, script output, error messages and screenshots from the engineering application.

| Connection | Carries content? | Destination | Default | User control |
| - | - | - | - | - |
| Model request | Yes. This is how the agent works. | Cosmon backend, then the model provider; or the provider directly in BYOK mode | Always on | Deployment mode |
| Conversation history sync | Yes, on plans that retain it. See below. | Cosmon backend | On | Settings toggle |
| Operational telemetry | No. Spans that would carry prompts or tool results are removed on the workstation before upload. | Cosmon backend | On | Settings toggle |
| Error reports | No conversation content. Stack traces, application version, OS. | Cosmon backend, which relays to Cosmon's error-reporting service | On | Not user-configurable |
| Product analytics | No conversation content. Feature usage events with clicked-element text limited to controls, and session replay with every input and all rendered text masked. | `analytics.cosmon.com` | On | Analytics off with the telemetry toggle; replay has its own toggle |
| Updates and version check | Nothing. Asks for the current version and downloads the next release. | Cosmon backend, then Cosmon's release bucket | On | Not user-configurable |

In the bring-your-own-key deployment, model requests go to the endpoint the customer configures and never touch Cosmon. The packaged application still makes the update, error-report and analytics connections above unless they are switched off or blocked at the network. A deployment with no Cosmon contact at all needs those connections disabled as well; see [Deployment options](/architecture/deployment-options) and talk to Cosmon about an offline configuration.

## What Cosmon stores, by plan

The Cosmon backend is plan-aware. Whether conversation content is ever written to Cosmon's systems is decided server-side on every request, from the account's plan, and cannot be changed by the end user.

| Data | Enterprise | Other plans |
| - | - | - |
| Model requests and responses | Relayed to the provider, not stored | Relayed to the provider, not stored |
| Usage records (model, token counts, cost, timestamps) | Stored | Stored |
| Conversation history from sync | **Discarded on arrival.** Only counts, token totals, tool names and model names are kept. | Stored, to support diagnostics and product analytics |
| Telemetry spans | Operational spans only; anything else is dropped on arrival even if a client sent it | Operational spans; sensitive spans are filtered on the workstation |
| Account, organization, seat and billing records | Stored | Stored |

On the Enterprise plan the result is that Cosmon holds no copy of any conversation. There is nothing server-side to export, share or subpoena, and nothing for Cosmon staff to read.

If an organization is on the Enterprise plan, its members are treated as Enterprise for this purpose regardless of any personal plan they hold.

## Model providers

Cosmon does not train or fine-tune models. All models are third-party foundation models accessed by API under Cosmon's provider agreements, and Cosmon does not use customer content to train anything. Provider-side retention is governed by those agreements; ask your Cosmon contact for the current terms that apply to your deployment. In BYOK mode the provider relationship, and its retention terms, are yours.

## Sharing and export

Argus has no share-link, publish or collaboration feature. Conversation content cannot be sent to another user or a third party through the product.

The only export is user-initiated: a user can export a chat, including agent history, as a JSON file written to their own workstation through the operating system's save dialog. That file is then subject to the workstation's own data-loss-prevention policy like any other document.

## Encryption in transit

All connections from the desktop application and the browser to Cosmon use HTTPS. Cosmon's public endpoints accept TLS 1.3 only, enforced at Cosmon's edge in front of the load balancer; TLS 1.0, 1.1 and 1.2 handshakes are refused. Plain HTTP is redirected to HTTPS and HSTS is set for one year including subdomains. Connections from the backend to the database and to model providers are encrypted. Customers that inspect TLS on their network configure the workstation's OS certificate store; see [TLS inspection](/architecture/it-prerequisites#tls-inspection-and-corporate-certificate-trust).

## Access on Cosmon's side

* The production database has no public IP address and accepts encrypted connections only, from Cosmon's private network.
* Backend services run under dedicated service accounts with per-service least-privilege grants. No service account holds a project-wide owner or editor role.
* Cosmon's internal operations dashboard is reachable only over Cosmon's private network, with device approval and named identities, and requires a verified `@cosmon.com` staff identity. It fails closed.
* Administrative changes to infrastructure are recorded in cloud audit logs. Infrastructure is defined in Terraform and changed through reviewed pull requests.
* Application logs record user identifiers and routes, never passwords (Cosmon's servers never receive one) and, on the Enterprise plan, never conversation content.

## Retention and deletion

| Data | Retention |
| - | - |
| Conversation history (Enterprise) | Not stored |
| Conversation history (other plans) | Retained until the account is deleted or the customer requests deletion |
| Usage and billing records | Retained for the life of the account and as required for billing |
| Local data on the workstation | Under the customer's control; removed by uninstalling or deleting the application data directory |

Deletion requests go to [support@cosmon.com](mailto:support@cosmon.com). Content deletion is performed per named account, never by domain sweep, so that the scope of a deletion is exactly what the customer approved.

## Revoking access

Organization owners and admins can remove a member or unassign a seat in the team console. The backend checks entitlement against the database on every request, so the licence is withdrawn on the user's next request. On request, Cosmon disables an account in the identity provider, which blocks new sign-ins and token renewal; an already-issued session token remains valid until it expires, at most 60 minutes. Cosmon can also set a minimum desktop version; when a client's version check succeeds against the backend, a release below the minimum is blocked until the user updates.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.