> 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/origin-communication-response-template.md).

# Origin Communication — Response Template

*Reusable response for customers and security reviewers asking about the agent's communication with `origin.in.we360.ai`.*

***

## 1. What the origin server does

The agent contacts the origin server for one purpose: **service discovery (bootstrap)**. On startup it asks *"for this tenant, what is the address of the API gateway and authentication server, and what shared configuration applies?"* and receives a **tenant manifest** in reply. From that point on, all real traffic — authentication, activity sync, screen-recording uploads, live streaming — goes to the **tenant gateway and authentication server**, not to origin.

We want to be precise about earlier wording: this is **discovery, not "license validation."** Our documentation has been corrected to reflect that. The origin exchange carries tenant and device identifiers plus install-health telemetry only — **no captured user data** (no screenshots, recordings, keystrokes, or activity events) is ever sent to the origin server.

## 2. Security controls on the exchange

* **TLS with full certificate validation.** All communication, including discovery, is HTTPS validated against the endpoint's OS trust store. The agent contains **no TLS-weakening behavior** — no disabled peer verification, no "ignore SSL errors," no cleartext fallback. A network attacker cannot rewrite the manifest in transit without a certificate the device already trusts.
* **Hard-coded origin.** The origin host is a compile-time constant; it cannot be changed over the network.
* **Authenticated data path.** All data traffic requires an OAuth `Bearer` token issued by the tenant's authentication server.
* **Egress allow-listing (customer-side).** Organizations that restrict outbound traffic can permit only the known We360 hosts, so any unexpected destination is blocked at the firewall.
* **Signed, integrity-checked updates** with downgrade and bad-metadata protection.

## 3. Eliminating origin entirely — pre-provisioned discovery

For environments that want the strongest posture, we are introducing **pre-provisioned origin data**. An administrator deploys a local, protected file (`zs-origin.json`) containing the tenant manifest. When present, the agent loads discovery data from that file and **makes no calls to the origin server at all** — so `origin.in.we360.ai` (and `origin.global.we360.ai`) can be **blocked entirely** at the firewall while the agent continues to operate normally.

This directly answers the concern that a vendor-hosted discovery endpoint could, in principle, re-point the agent: with origin blocked and discovery served from a local file, **there is no discovery request to intercept, impersonate, or redirect.** The root of trust moves from a network endpoint validated against the OS CA store to **a local artifact under the customer's own ACLs and device-management tooling** — more auditable and entirely within the customer's control.

The trade-off, stated plainly: this relocates the trust assumption rather than removing it. Whoever can write the local file controls the agent's destination, so the file must be deployed read-only to a protected, admin-only location through managed tooling. For centrally managed fleets this is a net improvement. (Note: automatic version checks also use origin; fully offline fleets should distribute agent updates through their own software-distribution channel.)

*Status: planned capability — see the* Pre-Provisioned Origin Data *guide for schema, behavior, and rollout. Contact us for availability timing.*

## 4. On the broader risks raised

* **Man-in-the-middle.** Requires defeating TLS, which requires a rogue/compromised root CA on the device. On a managed fleet with a protected CA store this precondition does not hold — and a compromised root CA would compromise *all* TLS on the device (banking, email, SSO), not this agent specifically. Pre-provisioning removes the discovery request from the threat model altogether.
* **Supply chain / vendor trust.** A legitimate concern, but inherent to deploying any endpoint agent and not specific to the discovery design — a compromised vendor controls the binary and backend directly. We address this through code signing, update integrity, and support for independent assessment under NDA.
* **Certificate pinning.** The agent currently relies on the OS trust store and does not pin above it; we are evaluating pinning as an additional hardening layer.

## 5. We will support a deeper review

On request and under NDA, we can provide an architecture briefing, the full network-exchange inventory (already documented), and support for an independent security assessment with the access — architecture detail and network traces — a reviewer reasonably needs.

***

### Summary

| Concern                       | Our position                                                                                                                                                |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "Discovery, not licensing"    | Agreed; documentation corrected.                                                                                                                            |
| Origin can re-point the agent | True by design — and **eliminable** via pre-provisioned `zs-origin.json`, which lets you block origin entirely.                                             |
| Network MITM redirect         | Mitigated by enforced TLS validation (no skip-verify in the agent), hard-coded origin, and egress allow-listing; **removed entirely** when pre-provisioned. |
| Compromised CA                | Device-wide problem, not agent-specific; addressed by the protected CA store and by pre-provisioning.                                                       |
| Supply-chain / vendor trust   | Inherent to any agent; addressed via signing, update integrity, due-diligence support.                                                                      |
| No certificate pinning today  | Confirmed; under evaluation.                                                                                                                                |


---

# 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/origin-communication-response-template.md?ask=<question>&goal=<endgoal>
```

`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.