Proxaradocs
Guides/Endpoint Protection

Network endpoints

Every destination the device agent talks to: one tenant API origin plus a pinned update host, what each connection carries, and what IT needs to allow.

Updated July 2026

The Endpoint Protection device agent initiates connections to exactly one API origin, plus one pinned release host for update downloads. Everything else it opens is loopback, on the device itself. Separately from the agent's own connections, the local proxy relays employee AI traffic onward to the AI services employees use. This page lists every destination the device agent talks to, what each connection carries, and what IT needs to allow. (Proxara Connect involves no device software and no device endpoints; its traffic runs between the firm's dedicated environment, Microsoft, and the firm's AI assistant.)

Destinations

DestinationWhat it isWhat it carries
The tenant API originOne HTTPS origin per install. Customer and pilot installs use the firm's own endpoint, delivered as managed configuration. Trial installs use trial.proxara.ai. The built-in default is api.proxara.ai.Device registration and heartbeats, configuration and policy, the AI-host registry, classification calls, signed compliance events, MCP audit events, and update checks.
The release download hostOne pinned HTTPS URL per release, set server side. Serves the signed installer for silent updates on production installs.The installer package. Its SHA-256 is checked against the server-declared hash before the file is written to disk, then the platform code signature is verified before install. Trial installs never auto-update; they update by reinstall.
Loopback (127.0.0.1)The local proxy, the PAC endpoint, the companion, and the local MCP gateway.Never leaves the device.
AI destinationsThe AI hosts employees actually use, matched against the registry. This is relayed employee traffic, not agent-initiated.The redacted request onward to the provider, and the provider's reply back.

Which environment sits behind the tenant origin is covered in The private environment.

Paths under the API origin

Every control-plane call is a path under the single tenant origin. The load-bearing ones:

PathCarries
/api/v1/devices/*Registration, heartbeats, and device configuration. Content-free: no prompts, no file content.
/api/v1/analyzeThe prompt text and file content of AI-evidenced traffic, sent for classification. This is where content leaves the device, and it goes only to the environment the firm is enrolled in.
/api/v1/ingestSigned compliance events. When sensitive values were found, the event carries the original text as evidence alongside the redacted version; clean exchanges are content-free. File attachments carry redacted extracted text only, never raw bytes.
/api/v1/registryThe AI-host registry pull, refreshed every thirty minutes. Devices fetch it from the firm's API, never from Microsoft directly.
/api/v1/mcp/*MCP gateway audit events and server classifications.
/api/v1/local-llm/*The content-free inventory of local AI runtimes and models, and the policy for them.
/api/v1/agent/updateThe update check. Trial installs always receive no-update.
/mcpThe relay bridging local AI clients to Rox, the tenant's MCP endpoint.

What IT allows

  • The tenant's API origin: the firm's own endpoint on a customer or pilot install, trial.proxara.ai on a trial install, api.proxara.ai as the built-in default.
  • The pinned release download host, once the firm's installs are on managed updates.

No other agent-initiated destination exists. The proxy's relayed traffic goes to the AI hosts the firm's employees use, which the firm's existing egress controls continue to see and govern. On a fleet that forces egress through a corporate proxy, the agent chains every outbound leg through the upstream configured at deployment; Coexistence covers that configuration.