> For the complete documentation index, see [llms.txt](https://docs.we360.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.we360.ai/deployment-and-it-ops/security-and-hardening/network-and-security-hardening/pre-provisioned-origin-data.md). # 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: ```json { "status": "active", "tenantId": "", "tenantName": "", "baseDomain": "", "apiGatewayUrl": "https://api.in.we360.ai", "apiKeycloakUrl": "https://auth.in.we360.ai", "apiKeycloakRealm": "", "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). ### Generating the file (recommended) The file content is exactly what the origin server returns from its **by-base-domain discovery** endpoint. Rather than hand-authoring it, fetch the live response for the tenant and save it as `zs-origin.json` — this guarantees the values match what the agent would otherwise receive online: ``` https://origin.in.we360.ai/discover/tenant_by_base_domain/?baseDomain= ``` Open that URL in a browser (or `curl` it), replacing `` with the tenant's base domain — e.g. `?baseDomain=tech-demo`. The JSON body it returns **is** the `zs-origin.json` contents; save it verbatim to the per-OS location in the table above. No fields need to be edited. > The response includes a few extra fields the agent ignores (`meta`, `autoUpdate`, `coreServiceUrl`); leaving them in is harmless. Only the required fields listed under **Schema** must be present and valid. ## 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.we360.ai/deployment-and-it-ops/security-and-hardening/network-and-security-hardening/pre-provisioned-origin-data.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.