Skip to main content
Glasswarp drives a real machine, so consent and observability are built into the platform — not left to the agent. Glasswarp provides the controls; you remain responsible for your agent’s behavior. API access is off by default. The rig owner must explicitly enable api_access_enabled in Console → Rigs. No session can route to a rig without it.

Visible session indicator

While an API session is active, the host shows an on-screen “API session active” indicator on the real machine. The owner always sees when an agent has eyes and hands.

Kill switch and safety_restore

The owner can end any session from the host or Console. On every exit path — disconnect, launch failure, and API END_SESSION — the host runs safety_restore to return the machine to a safe state.

Audit log

Every API session creates an audit row (who, when, which rig, session duration, action counts). Sessions are observable live via Live View and after the fact via the Console.

Privacy and data flow

Glasswarp is the transport between your agent and a Windows PC you own. Be clear about what travels where.

What is encrypted today

What we store

  • Stored: account identity, API key hashes (not plaintext keys), session metadata and metering (start/end, minutes, action counts), audit rows, billing records.
  • Not designed as a recording product: screenshot JPEG bytes and input event payloads are handled to complete the API call. They are not written to a customer-facing screenshot archive.

UIA text in observe

observe (and /targets) can return structured UI Automation text alongside or instead of a JPEG: focused window title/role, click-target names/roles, and optional field values. That text is far easier to log, cache, and leak than pixels — treat it carefully in your own systems. Never rely on the platform to scrub secrets from screenshots; pixels can still show masked dots or adjacent labels. Do not put passwords in prompts.
Honest model for v1: the REST control plane is an authenticated relay, not application-layer end-to-end encryption. Glasswarp infrastructure can technically access those bytes while serving the request. Do not treat the screenshot/input API as “Glasswarp can never see your screen.”

Who can watch Live View

Live View is for humans you authorize (rig owner / console session), not a back-office feed for Glasswarp staff. Opening Live View is an explicit console action on a session you own.

Longer-term privacy

The product direction is a privacy model where plaintext screenshots and input are not readable by Glasswarp (for example WebRTC / DataChannel control, or application-layer E2E), matching Live View’s media encryption. Until that ships, use the table above — not marketing shorthand.

What’s yours vs ours

Glasswarp provides
  • Consent gate (per-rig API access)
  • Visible indicator
  • Owner kill switch (console session end + host tray End API session…; remote input blocked during tray confirms; Unpair disabled while a session is active)
  • Audit log + Live View
  • TLS / WSS in transit; WebRTC media encryption for Live View
  • Key scoping and rate limits
You are responsible for
  • What your agent decides to do
  • Prompts, guardrails, and human-in-the-loop (HITL) review in your app
  • Not exfiltrating or misusing screen contents
  • Windows licensing and physical/cloud host security
Glasswarp is the safe, observable I/O layer — not an AI-safety layer for your agent’s decisions. Design your own review and approval flows on top.

Next: safe agent sessions

For a practical checklist (dedicated rigs, HITL, allowlists, budgets) — the decision-layer playbook that sits on top of these controls — see Safe agent sessions.