Threat model

A security model is only meaningful alongside an honest threat model. Here is what Apex is designed to stop, and what it is not.

What Apex defends against

Server-side vault breaches

Cloud password managers keep an encrypted copy of your vault on a server so it can sync. A breach of that server hands attackers the encrypted blob to grind on offline, indefinitely. Apex never uploads your vault, so there is no server-side copy to steal. The relay only ever sees ciphertext in transit and stores no vaults.

Supply-chain attacks and info-stealer malware

This is the case Apex is built for. A malicious npm or PyPI package, a trojaned installer, or an info-stealer runs with your privileges on your computer and copies everything it can reach: browser-saved passwords, ~/.ssh keys, ~/.gnupg keys, .env files, and password-manager vault files.

On an Apex machine that haul comes up nearly empty:

No vault file — it’s on your phone. There is nothing to copy and no master password to keylog.
No SSH or GPG keys — with Apex Agent they never leave the phone, so ~/.ssh and ~/.gnupg hold nothing.
No browser password store — the extension holds at most one credential, in memory, for one submission, then wipes it.

The blast radius shrinks from “everything” to, at worst, the single login you happened to be using at the moment of compromise.

Signing-key leakage

A stolen SSH key lets an attacker reach your servers; a stolen commit/release-signing key lets them publish malicious code under your name — that’s how one compromised laptop becomes the next supply-chain attack. With Apex Agent (coming soon), the keys never touch the laptop. Every git push, ssh, or gpg --sign forwards to the phone for a biometric tap; only the signature comes back. Malware cannot sign or push silently, and you revoke a lost laptop by un-pairing it.

Secrets in `.env` files

Project .env files are a routine info-stealer target. With Apex Agent, a .env can hold apex://<project>/<KEY> references instead of real values; apex run -- <command> resolves them from the phone over the encrypted relay — after an explicit on-phone approval — and injects them into that one command’s environment. The real values are never written to the laptop’s disk, and because every resolution needs a tap, malware cannot silently harvest them.

The limit is honest: unlike an SSH or GPG key (which never reaches the laptop at all), an environment variable has to exist in the process that consumes it. Once you approve a run, the injected values live in that process for its lifetime, where malware active on the machine at that moment could read them. The agent wipes its own copies after handing them off, but it cannot wipe the child process’s environment. This narrows the exposure to the secrets a command you launched is actively using — it does not hide them from a fully compromised, live machine.

Tampered or replayed messages

Every payload is signed with ECDSA and verified before decryption, so the relay cannot spoof a request and intercepted messages cannot be replayed.

What Apex does not protect against

Honesty matters more than marketing:

A compromised phone. The phone is the trust anchor. If it is fully compromised while unlocked, the vault is at risk. Use device biometrics, keep the OS updated, and don’t jailbreak/root.
Other local secrets you keep on the laptop. Apex removes your crown-jewel secrets — the vault and your SSH/GPG keys — and apex run keeps real .env values on the phone (see above). Source code, cloud tokens, and any env value in active use during an approved run are still yours to defend.
The single credential in active use. If your computer is compromised at the instant you autofill a login, that one credential can be observed. Your vault and every other credential remain out of reach.
Shoulder-surfing your master phrase, coercion, or a malicious OS keyboard. No software design defends against every physical or platform-level attack.
Metadata. The relay sees connection timing and ciphertext sizes. See the security model.