Skip to content

Security overview

The 30-second version. Each section links to the deeper page; this one exists so a security reviewer can scan the whole story before deciding which detail to read.

No behaviour-changing control plane. Rules, configuration, opt-out, and per-fleet behaviour are install-time only, baked into the binary and the enrollment manifest the admin deploys via MDM. The one thing PointFive controls remotely is release availability — which version is offered, when, to what fraction of the fleet. Auto-update is opt-in on the client. → Installation & distribution §1

Hybrid-encrypted on the device against a public key pinned in the binary at build time. The private key never leaves PointFive’s key-management system. A compromised laptop or manifest yields ciphertext, not plaintext. → Installation & distribution §5

Binaries are code-signed for each OS (Apple Developer ID, EV code signing, GPG repositories). Auto-update artifacts carry an additional signature that the client verifies before swapping; a mismatch aborts the update. → Installation & distribution §3

Every field allowed on the wire is enumerated. Anything not on the list is stripped; unknown signals are dropped; a redactor warning on any shape field drops the whole record. → Data contract → Fail-closed posture

Bash output, tool inputs, transcripts, environment variables, raw file paths, hostnames, IPs, branch names, commit messages — none are on the allowlist, no code path attaches them, an automated test asserts only allowlisted keys ship. The developer’s raw email also never leaves the device — it’s read once locally to compute a one-way hash and discarded. → Data contract → What the contract explicitly does not send

A short-lived local cache of compressed-away output, so the agent can tokenshift recover <id> the original back. Local-only, never shipped, off when disabled in the manifest. The recovery_retrieved signal records that a recovery happened — never the content.