Securing Skyline
In using agents, risk correlates strongly with reward. Aggressively using them to operate browsers, dashboards, APIs, and workflows can bring a huge jump in productivity. But with it comes higher risk: malware on your device, sensitive keys leaking into context, or credentials getting copied into places they were never meant to live.
And yet, we still see people storing passwords in plaintext files so their agents can access them. We see service accounts, intended for scoped-down API keys, being used as bearer tokens for complete access to every password you own. Those are for the risk-takers.
But honestly, in most cases, we just don't take this risk. And as a result, our agents get stuck on login pages. All the time.
Skyline is for that gap: better outcomes from agents, without putting your passwords and keys in all the places they don't belong.
For normal protected values, the keys that open your secrets stay local. Skyline's blind cloud vault holds release authority: it can decide when an exact encrypted package should be released, but it cannot decrypt that package or silently change what your local devices will trust.
The agent can use protected values through authorized apps and processes, but it does not get a local vault, a reusable bearer token, or passwords in the model context.
The four pillars
- 01
Normal secrets are locally secured.
The keys that open protected values stay on your devices. The cloud can coordinate an exact release without being able to decrypt it or quietly change what your devices will trust.
- 02
There is no local vault to steal.
Requester machines do not get a synced vault, vault-dump token, or portable unlock package that malware can copy and drain later.
- 03
Agents do not see passwords in context.
Browserfill and local secret actions handle the protected moment, so passwords do not land in the agent's context window, transcript, tool output, or model-provider logs.
- 04
Agents do not get bearer tokens.
Access is tied to authorized apps and processes through Skyline's local path, not to a reusable token string that can be copied elsewhere.
What Skyline protects
Skyline protects the things agents keep reaching for and should not be trusted to hold: passwords, API keys, environment variables, TOTP codes and seeds, account-recovery artifacts, the personal fields you type into forms, and private files.
The model comes down to four separations: the online vault cannot decrypt normal secrets, the local machine does not receive a vault to steal, the agent does not see passwords in context, and authorization binds to apps and processes rather than bearer tokens.
How it is put together
The first thing worth knowing is that the part of Skyline that can actually open a secret lives on your devices, not in our cloud. Everything else builds out from there.
An agent or automation does the work through an authorized local app or process. When it needs a secret, it does not reach into a vault and it does not hold a bearer token. Skyline's local path handles the protected use.
The authority to actually change the vault - add secrets, approve a trust change, admit a new device - lives on a trusted device. Today that is the Skyline iPhone app. It is not just another requester; it is the root of trust.
On the device where the work is happening, Skyline uses its own protected local software to perform the protected moment. It might fill a password, run a workflow that needs a secret, use a temporary code, or save a new protected value. It opens only what Skyline released for the action that was approved.
Then there is the cloud vault. It stores encrypted packages, routes requests, applies policy, keeps the audit trail, and releases the package an approved action needs. What it cannot do is open any of it. For normal secrets it is a release authority, not a decrypt authority.
Normal secrets are locally secured
For a normal secret, the ability to decrypt lives locally - on a trusted device or approved local software. The cloud holds the encrypted package it would release for an approved action, but it does not hold the key that opens it.
That does not make the cloud passive. It is an online release authority, and it does real work. When an agent asks to use something, the cloud weighs the request, the item, where the secret is headed, what has already been approved, recent activity, and policy. It can allow, queue, slow down, deny, or - when a request is unusual enough to want a human - ask your phone.
That is the whole reason Skyline can run a genuinely useful hosted vault without becoming something that can read your secrets. Storing, routing, searching, auditing, and releasing exact packages are not the same as holding plaintext or minting a key that opens it. In plain terms: we cannot see your passwords. And just as importantly, we cannot edit what is in your vault into something your devices will trust.
Visibility is not authority.
The cloud can see some metadata, like an item's name, URL, label, or pending approval, so it can make useful decisions and show clear prompts. But seeing a name is not the same as being able to rewrite it.
Cloud records do not open secrets.
Skyline can store encrypted packages and the non-secret information needed to route them, but those records do not contain the local authority needed to open the package.
The algorithms are public.
Normal protected fields use ChaCha20-Poly1305 with a fresh random data key and nonce per package. That data key is wrapped separately for each trusted local key holder: P-256 for the iPhone/admin recipient and X25519 for approved requester/helper recipients, using HKDF-SHA256 and ChaCha20-Poly1305 envelopes.
Changes are verifiable.
Creates, imports, updates, and trust changes carry proof that your devices check locally. The backend stores vault data, but it cannot silently change what an item means into something your devices will then reveal, fill, or hand over.
There is no local vault to steal
Skyline does not turn an agent machine into a vault owner. The normal path does not leave a synced vault, vault-dump token, broad unlock package, or service-account-style master key sitting on the machine.
This matters because the biggest local failure mode is not only an agent making a bad decision. It is malware, a compromised process, or a copied local artifact. With Skyline, the useful local authority is tied to approved apps, processes, and local helper paths, not to a portable string that can be moved somewhere else.
Like any password manager or secret-delivery tool, Skyline cannot make a fully compromised device safe. Malware on the endpoint may still grab a value at the moment of legitimate use. The difference is what is lying around to take afterward: not a synced vault and not a standing vault token.
Agents do not see passwords in context
The default is not "show the agent the password and hope it is careful." The agent does everything around the secret - navigate, pick the service, choose scopes, fill the ordinary fields, get the page ready - and Skyline steps in for the protected moment.
Depending on the flow, trusted local software may fill, use, create, capture, or save a protected value without turning it into ordinary agent output.
Before the agent sees its next observation, Skyline has already done the careful part - verified, cleaned up, stored, navigated away, returned a sanitized status - so passwords do not enter the agent's context. In normal flows, protected values do not show up in the transcript, do not get sent to OpenAI or Anthropic or any other model provider as context, and do not sit in ordinary page reads or tool output waiting to be scraped later.
You can still explicitly reveal a secret when you mean to. That is a real path, just not the one agents authenticate through by default.
Agents do not get bearer tokens
Skyline's normal authority path is not a bearer token. An authorized app or process can use relevant secrets through Skyline's local path, but copying one token string should not be enough to become that app or process somewhere else.
That is different from handing out a broad service-account token, share link, time-limited envelope, or preloaded batch at the start of a run. Those can be useful tools, but they make possession of the token the main boundary.
Skyline instead ties use to the authorized local app/process path and watches for suspicious behavior. Routine authorized use can keep moving; unusual or trust-changing cases can escalate to the phone.
How a request gets decided
Authorization and escalation are deliberately different jobs. An approved app/process can use secrets through Skyline's local path. The cloud checks activity against policy, history, identity, and risk; unusual, risky, or trust-changing cases can go to your phone, which approves only the thing it is actually approving.
Skyline is designed so your devices do not have to take the cloud's word for what is trusted. Decisions are anchored in trust state your devices can check for themselves.
The backend can be useful for routing and storage, but it is not enough by itself to make a new key, item change, or approval trusted. A request is bound to the approved action, and the local side checks trusted state before protected material is used.
That is how the cloud can help decide without being able to overrule the result. It routes, weighs, queues, and releases - but it cannot rewrite the request, fake your phone, or turn one approval into a broad unlock.
Adding devices, losing devices
The iPhone is Skyline's first control surface. It reviews approvals, adds and edits vault contents, and authorizes trust changes like admitting a new local access path.
A new local component or requester cannot read existing secrets merely because it generated its own key. It has to be admitted into trusted vault state.
Skyline treats cloud-stored ciphertext and local device authority as separate pieces. When trust changes, rekeying can move the vault forward so old grants and old access paths do not quietly remain root authority forever.
If a trusted device loses its own key, it does not get to fake its way back in. Skyline fails loudly and asks you to re-pair, rather than quietly trusting whatever the backend says.
The same shape beyond passwords
Passwords are where Skyline starts, but the shape was never really about passwords. It is about giving an agent a bounded protected action instead of custody of the secret behind it.
It runs in reverse for things that are created rather than used: a value made, captured, or imported is encrypted before durable cloud storage, so the cloud holds an encrypted package and safe metadata, never the plaintext.
The same custody split can be hardened or pointed at different kinds of secrets. Some values can require more than one independent boundary before use, and some credentials can be used inside a protected authority that performs the action and returns only a result.
Software integrity
All of this rests on the trusted local software and trusted device being authentic. That is true of any security product, and it is why code signing, controlled releases, and being transparent about updates matter: an update changes the very code that enforces the local boundary.
The split underneath stays the same either way. Your devices hold the keys that open your secrets, and the cloud coordinates the release without ever becoming able to open them itself.