Pre-Provisioned Origin Data

Status. The file name (zs-origin.json), per-OS locations, and the ownership/permission enforcement described below are implemented in the agent. Confirm availability for your specific agent version with We360 before planning a hard offline (origin-blocked) rollout.

Summary

The desktop agent normally performs service discovery at startup by calling the origin server (origin.in.we360.ai) to fetch its tenant manifest — the addresses of the tenant API gateway and authentication server, shared headers, and SSO configuration. See Stealth App — Server Communication for the full exchange.

Pre-provisioned origin data lets an administrator supply that manifest as a local, protected file instead. When the file is present and valid, the agent loads discovery data from it and does not call the origin server at all. This allows the origin host to be completely blocked at the firewall while the agent continues to operate normally against the tenant gateway and auth server.

In effect, the root of trust for discovery moves from a network endpoint (vendor-hosted, reachable over the internet) to a local artifact the customer controls and protects.

The file

Property	Value
Filename	zs-origin.json
Location (per OS)	Windows: C:\Windows\System32\zs-origin.json · macOS: /Library/Preferences/zs-origin.json · Linux: /etc/zs-origin.json
Format	JSON containing the tenant manifest the origin server would otherwise return.
Protection (enforced)	The agent honours the file only if it is owned by an administrator and not writable by standard users. On macOS/Linux it must be owned by root and not group- or world-writable (deploy with chown root — root:wheel on macOS — and chmod 644); on Windows the System32 location is admin-only via NTFS ACLs. A file that fails this check is logged and ignored, and the agent falls back to online discovery. See Security model below.

Schema

The file mirrors the tenant manifest contract. All string fields are required unless noted:

{
  "status": "active",
  "tenantId": "<tenant-id>",
  "tenantName": "<display name>",
  "baseDomain": "<acme>",
  "apiGatewayUrl": "https://api.in.we360.ai",
  "apiKeycloakUrl": "https://auth.in.we360.ai",
  "apiKeycloakRealm": "<realm>",
  "headers": { "X-Example-Shared-Header": "value" },
  "ssoConfig": { }
}

• headers may be an empty object {} if no shared headers are required.
• ssoConfig is optional and may be omitted or empty.
• Any missing or non-string required field makes the file invalid; the agent treats an invalid file as absent (see fallback below).

Behavior

• File present and valid → the agent loads the manifest from the file, persists the gateway/auth values to its config store exactly as if origin had returned them, and skips all origin.in.we360.ai/discover/tenant_by_* calls, including the periodic (~30 min) manifest-refresh timer. No discovery traffic leaves the device.
• File absent or invalid → the agent falls back to normal online discovery against the origin server. (Customers who want a hard offline posture should pair provisioning with the firewall block, and validate the file before deployment.)
• Data path is unchanged. Authentication, activity sync, screen-recording upload, and live streaming continue to use the tenant gateway and auth server named in the file — over TLS with certificate validation, exactly as today.

Blocking origin

Once devices are provisioned with a valid zs-origin.json, the following hosts may be removed from the egress allow-list / actively blocked for those devices:

• https://origin.in.we360.ai
• https://origin.global.we360.ai

The tenant gateway (api.in.we360.ai), auth server (auth.in.we360.ai), the admin portal, and asset/config hosts must remain reachable. See the allow-list guide for the full set.

Updater note: the origin server also serves agent version metadata (/discover/app_versions/) used by the auto-updater. With origin blocked, automatic update checks via that path will not run. Plan agent updates through your existing software-distribution channel (MDM/portal) for fully offline fleets. This is the one function that does not have a local-file equivalent today.

Security model

This capability is a security improvement for hardened environments, but it relocates rather than removes the trust assumption:

• What it removes: the need to reach a vendor-hosted discovery endpoint over the internet, and with it the network man-in-the-middle / origin-impersonation vectors against the discovery step. There is no discovery request to intercept or redirect.
• What it relies on instead: the integrity of the local file. Whoever can write zs-origin.json can point the agent at an arbitrary gateway — the same power the origin server has today, but now exercised locally. This is why the file must live in a protected, admin-only location and be deployed through managed tooling. The agent enforces this: on macOS/Linux it refuses a zs-origin.json that is not root-owned or that is group/world-writable (so a non-admin user cannot plant or tamper with one); on Windows it relies on the System32 ACL. Treat write access to this file as equivalent to administrative control of the agent's destination.
• Net effect: the root of trust changes from "a TLS connection to a vendor endpoint, validated against the OS CA store" to "a local file under the customer's own ACLs and MDM control." For organizations that already firewall outbound traffic and manage their endpoints centrally, this is a stronger and more auditable posture, and it lets them eliminate origin egress entirely.

Deployment checklist

1. Build the zs-origin.json for the tenant (values match what origin returns for that tenant — confirm with We360 or read them from a reference install).
2. Validate the JSON against the schema above.
3. Deploy via MDM/GPO to the per-OS location in the table above, with admin ownership and standard-user-read-only permissions (macOS/Linux: chown root + chmod 644; Windows: the System32 ACL already enforces this). A file that isn't admin-owned / is user-writable will be ignored by the agent.
4. Confirm the agent onboards and syncs with origin still reachable (validation step). Check the agent log for a line confirming the local override loaded (and no "ignored — ownership/permission" warning).
5. Block origin.in.we360.ai / origin.global.we360.ai egress for those devices.
6. Move agent updates to your managed software-distribution channel.