Securing Skyline

Skyline lets agents access accounts unattended without giving the agent, its computer, or a copied token standing access to your vault.

We all want our agents to do more.

Access is what makes them useful. Indeed, biggest remaining blocker to letting your agents do literally anything you would do on a computer is simple: giving them an inventory of available services, and letting them access them. But that also comes with new risks: passwords can leak into agent context, websites can steer agents with prompt injection, and malware can watch what happens on the computer.

Legacy password managers are woefully unprepared. They assume a person is there to unlock the vault, inspect the page, and choose what to fill. Leaving one unlocked on an agent's computer can open the door for malware on that computer to reach every password inside it.

Skyline is built so agents can access the account they need without leaving the whole vault unlocked beside them.

Three core principles

Skyline fills supported login and signup forms locally, then gives the agent the result—not the secret.

The agent never sees the password

Skyline's cloud stores encrypted packages, but it can't decrypt them. On compatible Macs, local keys are also protected by Secure Enclave.

The keys stay on your devices

Only apps and processes you approve can ask Skyline to act. Each request stays limited to the chosen account, site, and action; there's no reusable bearer token that opens the vault.

Every use is verified and bounded

The isolation mechanism

The keys that decrypt your passwords live locally, but they aren't enough on their own. Before any password is decrypted or used, Skyline's external decisioning layer must approve one request for one account, site, action, and short time window. Only then does the local helper decrypt and fill it. The agent gets the result, never standing access to the vault.

Cloud
DecisioningChecks the requested use against your policy
Approved for browser fill on yahoo.com
Device
AgentRequests sign-in
Skyline local helperHolds the keys · decrypts locally
ChromeYahoo password field
The keys stay local. Skyline’s external decisioning layer must approve each decryption and use.

Skyline assumes your machine can be attacked

A prompt injection can steer the agent, and malware can watch one login. Skyline doesn't ask your machine to make the whole trust decision alone: your machine holds the decryption keys, while Skyline's cloud holds ciphertext and the authority to approve each release.

Malware watching the exact moment of use may still capture that one password, but it doesn't get standing access to the rest of the vault.

Cloud sync can't see your passwords

Skyline syncs encrypted packages and the metadata needed to route requests. The cloud never receives the keys that decrypt normal saved passwords, so it can move, store, and release ciphertext without being able to read the passwords inside.

Post-quantum encryption by default

Skyline uses ML-KEM-based post-quantum encryption across its current supported secret-custody paths. On compatible Macs running macOS 26 or later, the separate ML-DSA signing key and ML-KEM delivery key are protected by the Secure Enclave.

Post-quantum password delivery is standard. Compatible Macs add hardware protection for the keys.