Desktop protection

Plan requirement: all plans can monitor. Protect and higher can enforce request policy. Business and Enterprise can inspect compatible responses.

Desktop protection runs a loopback proxy on the employee device. Detection runs locally, and only Orthalon event metadata is sent to the organization ingest service.

V1 availability

Orthalon v1 offers the loopback proxy as a managed beta for accepted clients that support a custom model API endpoint. This path works on macOS, Windows, and Linux and does not require a kernel driver or Apple Network Extension. Administrators must configure each accepted client to use the local Orthalon endpoint.

The separate macOS native controls and regional destination-policy edge remain in internal qualification. They are not included in the v1 customer package. Orthalon does not market v1 as a transparent desktop proxy, native ChatGPT or Claude interceptor, mobile agent, or complete SWG/SASE service.

The endpoint artifact is an installable managed background service, not another desktop chat window and not a transparent TLS interceptor. The release package contains its own runtime, starts automatically for the enrolled OS user, keeps the endpoint policy cache and metadata queue in a private local directory, and includes a health command for endpoint management.

Installing it does not capture every prompt on the computer. Each protected native or IDE client must support a custom compatible model API endpoint and must be configured to use Orthalon's loopback service. ChatGPT Desktop and Claude Desktop's normal chat backends are not redirected by this agent; fixed or pinned backends remain discovery-only.

Requirements

• An Orthalon sensor key for the organization.
• A signed Orthalon endpoint artifact with the production service address preconfigured by Orthalon.
• A native application, CLI, or IDE model integration that accepts a custom OpenAI Responses, Chat Completions, or Anthropic Messages endpoint.
• The upstream provider credential required by that client.

Clients with a fixed backend, certificate pinning, or no configurable model endpoint cannot be protected by this proxy. Identity, network, or CASB evidence can discover some of that use, but discovery does not inspect content.

Client compatibility

Third-party VS Code or Cursor extensions are supported only after their exact version passes the custom-endpoint tests. Re-test after every client update.

Configure an endpoint

1. Provision a Desktop agent key under Sensors & keys. Do not reuse a browser, MCP, or gateway key.

2. Download the signed package for the endpoint's operating system and CPU. Verify the publisher signature and separately delivered SHA-256 digest.

3. Install the scoped key as ORTHALON_SENSOR_KEY and the organization shown with that key as ORTHALON_ORGANIZATION_ID through the endpoint secret profile. The organization pin prevents a cached policy from another tenant being accepted. The Orthalon service address is already built into the signed artifact.

4. Put the two enrollment values in the package's desktop-agent.env file. Keep the file readable only by the enrolled OS user. Do not add the service URL: the signed package already contains it.

5. Install without putting the sensor key on the command line:

   macOS or Linux: ./install --config /protected/path/desktop-agent.env
   Windows:        install.cmd --config C:\protected\desktop-agent.env

   The installer validates the package manifest, rejects a broad or malformed enrollment file, installs the bundled runtime, and registers automatic startup for the current user. A newer verified package upgrades the agent without replacing its enrollment.

6. Run ./status or status.cmd, or request the local status endpoint:

   http://127.0.0.1:4110/v1/status

7. Confirm the response reports protected, policySource: network, a current policy version, and no policy sync error.

8. Point the AI client's model API base URL to:

   http://127.0.0.1:4110/v1

   OpenAI-compatible clients normally use that /v1 base. Claude Code appends /v1/messages itself, so configure its ANTHROPIC_BASE_URL as http://127.0.0.1:4110 without the trailing /v1.

9. Send harmless traffic, then synthetic detector test data in Monitor mode.

10. Confirm metadata appears in the correct Orthalon organization. The sensor record should identify the endpoint OS/CPU, agent version, last check-in, and distributed policy version.

When an administrator publishes a policy, the desktop agent receives an organization-scoped version notification and immediately downloads the full policy from Orthalon. The notification contains no policy rules or user data. The agent also makes a conditional ETag request at a bounded interval so a sleeping device, network interruption, or notification outage cannot leave it stale. A failed or malformed update never replaces the last valid cached policy. No Ably credential is installed on the endpoint; the desktop sensor key is exchanged for a short-lived, subscribe-only token.

The local proxy rejects cross-site browser requests, DNS-rebinding host names, non-JSON bodies, non-loopback binds, and image/audio/video/file content it cannot inspect. A REQUIRE_APPROVAL request remains held locally and is sent only after the same user, sensor, organization, domain, detector set, and opaque content binding are approved and atomically consumed.

An HTTP 401 during policy refresh normally means the sensor key is missing, mistyped, revoked, or belongs to a different ingest environment. Create the organization and provision the key in the web app before starting the agent.

Operating-system deployment

• macOS: the per-user package registers a launchd LaunchAgent. Sign the release as a Developer ID installer package, notarize it, and distribute it through MDM in staged rings.
• Windows: the per-user package registers a least-privilege scheduled task and restricts the installation directory ACL. Wrap it in an Authenticode-signed MSI/MSIX or approved IntuneWin release before endpoint distribution.
• Linux: the per-user package registers a hardened systemd --user unit. Convert the verified archive into the supported signed DEB/RPM packages and distribute them through the organization's package-management channel.

For production, put the desktop-scoped ORTHALON_SENSOR_KEY and non-secret ORTHALON_ORGANIZATION_ID in the endpoint-management secret/profile system, not in the package or command line. Orthalon's release process builds the service address into the artifact; a deployment operator may use ORTHALON_INGEST_URL only as a local/staging override. Monitor both /v1/status and sensor check-ins, and rotate the key before expiry.

The in-repository build creates a self-contained archive and checksum on the current operating system with pnpm --filter @repo/desktop-agent package:endpoint. Build each target on its native release runner. Publisher signing, notarization, MDM assignment, update-ring policy, and real-client acceptance remain release-operator responsibilities; the package does not make those external controls automatic.

The package is not a tamper-prevention product on its own. For Active policy, endpoint management must protect the installed files and client routing configuration, enforce automatic startup, and remediate a stopped or modified agent.

Uninstall with install --uninstall. Add --purge only when the endpoint is being retired and the enrollment, cached policy, and queued security metadata must also be removed. Revoke the sensor key during offboarding even when the device reports a successful uninstall.

Future enterprise native endpoint qualification

Orthalon is developing a separate native endpoint and regional edge layer. The current source supports qualification tests and is not a v1 customer feature. It uses an enrolled device identity instead of a browser or Desktop-agent sensor key. An administrator issues a short-lived enrollment, the endpoint creates an Ed25519 private key in the operating-system keystore, and Orthalon stores only the public key and its thumbprint. Signed heartbeats report the adapter, policy, bypass, and health state. Revocation stops new regional sessions and leaves the old device key inactive if the employee later rejoins the organization.

The current macOS qualification package has two distinct controls:

• A Network Extension content-filter provider can allow or deny connections by destination. Encrypted traffic remains metadata-only unless a separately approved TLS inspection path can read it.
• A native text guard can hold the keyboard paste shortcut, Enter key, or an accepted Send-button click in an exact managed application build. It checks the complete accessible editor through the local desktop policy service. It requires Accessibility, Input Monitoring, and event-posting permission.
• A native file-analysis contract scans small readable files on the endpoint. Business and Enterprise can send supported PDF, Office, spreadsheet, and ZIP files to Orthalon's private analysis bucket. Orthalon deletes the object when the job reaches a terminal state.

The keyboard-paste path can stop clipboard text before the app receives it. The submission path checks the editor before an accepted Enter or Send action, so it covers typed text and text inserted through context-menu paste or drag and drop. The target app may sync a draft before submission. Alternate buttons, dictation, images, voice, and inaccessible editors stay outside the accepted path. Re-run acceptance after each target application update.

File analysis and file enforcement are separate controls. The analysis service can classify a file after the native host supplies a verified path. Blocking every picker and drop needs an operating-system file-open adapter plus a recent decision cache. macOS uses Endpoint Security for that release path. Windows uses a signed file-system minifilter for strong open-time enforcement, and Linux uses a privileged fanotify service. Keep native file blocking behind the Enterprise qualification flag until the selected adapter passes the deployment and application tests.

macOS uses a user-space system extension, so the design does not require a kernel extension. Your release operator must still sign and notarize the host and extension, enable the Apple Network Extension capability, and deploy the System Extensions, Network Filter, and privacy-control profiles through MDM.

Windows can use UI Automation and input hooks for accepted application text. Connection controls use Windows Filtering Platform. Stream modification may require a dashboard-signed WFP callout driver, and file-open blocking requires a signed minifilter. Linux needs separate X11 and Wayland input acceptance; Wayland often blocks global input capture. Traffic steering needs a process with scoped CAP_NET_ADMIN, while fanotify file authorization needs its own privileged service. The policy engine and user interface remain unprivileged.

The regional edge currently authenticates short-lived, device-bound sessions and returns destination policy states: inspected, blocked, bypassed, or uninspectable. It does not yet terminate a production device tunnel or perform TLS decryption. Orthalon keeps this capability behind Enterprise qualification until the signed endpoint, MDM, exact-application, regional capacity, failover, privacy, and TLS-governance evidence passes.

Mobile coverage

Orthalon does not currently ship an iOS or Android traffic agent. A genuine mobile protection product needs a signed iOS Network Extension and Android VpnService, managed enrollment, certificate and per-app routing policy, a regional cloud enforcement plane, captive-portal handling, and tested bypass behavior for pinned applications. The desktop loopback package cannot be installed on a phone and the AI gateway is not a general mobile web proxy.

Use supported identity, SaaS, CASB, or network connectors for mobile discovery until that native client and enforcement plane pass the mobile release gate. Do not describe mobile discovery as prompt or file inspection.