Documentation › User Guides › Device Owners › Stage 5 › Privacy and security

Device Owner mode launches Q3 2026. The agent sandbox model and data-flow described below reflect the architecture in desktop/src/main/ and the backend's container security configuration. Specific control names will be re-verified against the GA build.

Privacy and security on your machine

You are letting code that other people authored run on your hardware. That requires honest answers to three questions:

  1. What can a B2B customer's job actually do on my machine?
  2. What data does the Zyra agent send back to the platform?
  3. How do I verify any of this is true?

This chapter answers each. The canonical compliance disclosure is the Security at Zyra trust page.

The sandbox: what a job can and cannot do

Every B2B customer job runs inside a Docker container with a tightened security profile:

  • Read-only root filesystem. The container cannot persist anything to disk on your host. Working space is a writable tmpfs that vanishes when the job ends.
  • No host network access. The container's network namespace is isolated — it cannot probe your LAN, your other devices, or your local services.
  • Capability drop = ALL. Linux kernel capabilities dropped to minimum. No CAP_SYS_ADMIN, no CAP_NET_ADMIN, no CAP_SYS_PTRACE.
  • no-new-privileges. A process inside the container cannot escalate via setuid binaries.
  • Resource caps. CPU, RAM, and PID counts bounded so a job can't starve your host.
  • Non-root user. Container processes run as an unprivileged user, never as your host user.

[VERIFY: the canonical configuration lives in the backend's container security configuration referenced in .claude/rules/security.md (DOCKER_SECURITY_CONFIG) and is applied by the agent's container runner at desktop/src/main/taskExecutor/dockerRunner.ts. Specific knob values at GA will be reflected in the security.html trust page.]

This combination is broadly equivalent to what cloud providers use for multi-tenant compute. The configuration is enforced by the agent and auditable in the public repo.

What a job still consumes

  • CPU cycles you've allocated (per availability schedule and capability caps).
  • RAM up to the per-container cap.
  • Network bandwidth via a NAT bridge for inputs/outputs — cannot reach LAN hosts.
  • GPU resources (if exposed) via device passthrough, sandboxed to allocated VRAM.

Power and electricity, of course — see Stage 4 chapter 4.

Bring-your-own keys

[VERIFY: BYOK for job inputs/outputs — encrypted-at-rest for task payloads is implemented in the storage layer; full BYOK with customer-supplied KMS keys is on the roadmap.] By default, job inputs and outputs are encrypted at rest in MinIO/S3 and in transit via TLS to the agent. You as a device owner do not manage keys; encryption is handled platform-side via ephemeral per-job data-encryption keys.

What data the agent sends to Zyra

Heartbeat (every ~10-30 seconds while online)

  • Device ID and authentication token.
  • Current CPU load, memory usage, network throughput, GPU utilization.
  • Docker capabilities detected on host.
  • Container status: running count, idle slots available.

Built in desktop/src/main/backendSync.ts::sendSingleHeartbeat from the systeminformation library. Does not read your filesystem, browser history, other applications, or anything outside the metrics enumerated above.

Capability registration (one-time and on hardware change)

  • Hardware fingerprint (CPU model, RAM total, GPU model — normalized via backend/app/services/gpu/detection.py::normalize_gpu_model).
  • OS and platform identifier.
  • Network class (residential / business / unknown).

Task results (per job)

  • Container exit code, runtime duration, resource consumption.
  • Output artifacts (uploaded to platform storage on behalf of the B2B customer — their data, not yours).

What it does NOT send

  • Your host filesystem contents.
  • Your other applications, processes, or browser activity.
  • Your network traffic content (only the container's aggregate network usage).
  • Your microphone, camera, or peripheral input.
  • Your geolocation, beyond the country region you set at signup and the public IP geolocation already visible to any server you connect to.

Encryption in transit and at rest

  • In transit: every connection from the agent to the backend uses TLS 1.2+.
  • At rest in the backend: job payloads in MinIO/S3, database rows in PostgreSQL — encrypted with platform-managed keys.
  • On the device: task working data lives in a tmpfs that is destroyed when the container exits. Agent auth token stored in the OS keychain (macOS Keychain, Windows DPAPI); non-secret settings in electron-store JSON.

How to verify the agent isn't doing anything sneaky

Inspect the container at runtime

While a job is running, on your host:

docker ps --format "{{.ID}} {{.Image}} {{.Command}}"
docker inspect <container_id> | grep -E "Privileged|CapAdd|CapDrop|NetworkMode|ReadonlyRootfs"

You should see ReadonlyRootfs: true, Privileged: false, all caps dropped, network none or an isolated bridge with no LAN routes.

Audit the agent's outbound network

Run a network monitor (Little Snitch on macOS, GlassWire on Windows, tcpdump everywhere). You should see:

  • Connections to *.getzyra.io (control plane and storage).
  • Connections from inside the container to the customer's data sources via the NAT bridge.
  • Nothing to your LAN. Nothing to consumer telemetry services. Nothing to ad networks.

Audit the source

[VERIFY: source visibility — Zyra's backend is in a public GitHub repo (referenced from /security.html). The desktop agent source is in the same repo at desktop/src/. You can read every file, including backendSync.ts and taskExecutor/dockerRunner.ts.] If the agent were doing something secret, you could find it.

Build it yourself

If you have a strong reason not to trust the published binary, build the agent from source with the standard Electron build chain. Instructions in the repo's desktop/README.md. [VERIFY: reproducible-builds work item — binaries are signed; bit-for-bit reproducibility is a post-launch goal.]

What we cannot promise

  • We cannot promise your machine will never be touched. A job consumes CPU, RAM, GPU — that's the point. We promise the sandbox confines the job to those resources only.
  • We cannot promise zero bugs. Sandbox escapes have happened in the broader container industry. We follow CVE feeds, patch the agent runtime, and disclose any incident affecting device owners (see security.html).
  • We cannot promise your ISP doesn't notice the bandwidth. Job traffic is real bandwidth (Stage 4 chapter 4).

If something looks wrong

  1. Stop the agent (Tray icon → Stop earning).
  2. Capture evidence (docker inspect output, network capture, screenshots).
  3. Open a confidential disclosure to security@getzyra.io — see security.html for the disclosure policy and PGP key.

We treat agent-misbehavior reports as P0. The trust model only works if the device owner is the first line of audit.

Cross-links

End of Stage 5 — you've finished the device-owner guide

From here, the best documentation is the dashboard you're operating, the marketplace report we publish annually, and the community forum. Welcome to the operator side of the platform.

← Previous: 3. Reading the marketplace · Back to the device-owner guide overview

Last reviewed: 2026-05-21