Skip to content
Home

Vockal takes commands from your paired phone and nothing else. Six actions can reach your desktop, and every one of them carries a signature only your devices can produce. This paper is the whole architecture, including what it does not protect you from.

No accounts, just devices

There is no password to phish and no account to take over. Authentication is tied to hardware you already hold, through a QR pairing flow:

  1. 1Your desktop shows a QR code carrying a pairing identifier.
  2. 2Your phone scans it and sends the pairing request to the server.
  3. 3The server issues each device its own token, written to storage the operating system encrypts.
Windows
DPAPI (Credential Manager)
iOS
Keychain (Keychain Services)
Android
Keystore (EncryptedSharedPreferences)

Those tokens authenticate every WebSocket and REST connection. No passwords, no OAuth flows, no session cookies. Nothing to phish.

Recovery runs over email and a six-digit code. When it completes, new tokens are issued and the old ones stop working.

Six actions, and no seventh

Vockal runs on an explicit allowlist. The desktop binary carries code for these six things, and nothing else:

  • Click at coordinates
  • Type text
  • Scroll
  • Switch application
  • Navigate to URL
  • Take screenshot

Everything else is not blocked, it is absent. Not on the list, and not in the binary: shell commands, file system access, registry edits, process management, network configuration, system modifications.

This is not a policy that can be overridden, it is an architectural constraint. Even with the server, the model and the network fully compromised, your desktop cannot execute a banned action, because the code path does not exist.

Validation runs twice, independently. The server checks the action type before it dispatches, and the desktop checks again before it executes. Both have to agree.

What leaves your devices

The complete list. If it is not here, it does not leave.

Audio
Streamed to Google Cloud Speech-to-Text for transcription, under Google Cloud's data processing terms. Never stored on our servers; the raw audio is discarded once it is transcribed.
Screenshots
Captured on demand, when the agent needs to see the screen. Held for ten minutes so it can reason across steps, then expired. Sent to OpenRouter for analysis.
Commands
Transcribed and sent to OpenRouter so it can work out what to do. Transcriptions and action history are stored for session continuity.
Context
The active app's name and your monitor layout, so the agent can target the right window at the right coordinates.
Accounts
None. No usernames, no passwords, no profiles. Device tokens are the only credential.
Data sales
Never. Not sold, not rented, not traded. Not to advertisers, not to data brokers.

If something is compromised

The honest version. Every system has a blast radius, and this one is ours.

If our server is taken

Every action dispatched to your desktop is signed with a per-session key that only your desktop holds. Full access to the server does not let an attacker forge one. Past that, the allowlist still stands: they could click, type and scroll, but they could not run a shell command, read your files, or change your system.

If your device is taken

An attacker with root on your phone or desktop can extract the token. At that point they already control the machine, and Vockal has given them no reach they did not already have.

The server can

  • Relay actions between your devices
  • Read transcriptions and action parameters
  • Send context to the model provider
  • Store session history
  • Manage device pairing state

The server cannot

  • Forge an action signature
  • Execute anything outside the six actions
  • Read your file system or registry
  • Run shell commands on your desktop
  • Control your desktop without an authenticated device session