Skip to main content
Security

Security architecture and threat model

Security isn't a feature here. It's the architecture.

In development · early access

Built by an identity and security practitioner. Below is our threat model, grounded in cryptographic identity, end-to-end encryption, and honest disclosure of residual risks.

What we protect

  • Commands and approvals are signed on your phone with a key that never leaves it; the hub relays them but can't forge or alter them.
  • Commands, replies, approval details and dashboard data are end-to-end encrypted between your phone and your PC. The hub relays ciphertext it can't read.
  • Pairing needs physical presence: a QR code on your PC plus a 6-digit check typed at its keyboard.
  • Replays are refused (timestamps, one-time ids, single-use connection tickets).
  • Secrets live in Windows Credential Manager or the Linux Secret Service, not in config files.
  • Runs started from your phone execute in a container with no access to your keys or home folder, and network access only to allow-listed hosts.

What we can't protect

  • A fully compromised PC: if malware runs as you or as admin, it can do what you can.
  • The hub sees the metadata it needs for routing (which device, when, which project and agent), never contents.
  • Agents running as the same OS user can't be fully separated from each other; the real boundary is your approval.
  • Built-in tools of clients without hooks (see "Straight talk").