Security

Everything the job needs.
Your keys, on your terms.

Agents need real access to do real work: a shell, your repositories, your services. Aldo gives them that on a machine of their own, and lets you choose how each secret reaches it, down to a stand-in the agent can use but never read.

Your browser
Signed in. Preview links open only for you.
your session
Aldo
Keeps your sign-ins and vault, encrypted.
tokens signed by the thread's key
The thread's machine
Agent, code, app and browser. Stand-ins for injected keys.
the firewall adds the real key
Your services
GitHub, Stripe, your cloud: they see the real key.

01Isolation

A machine per thread.

Agents need a real shell to do real work. Each one gets it on a machine of its own, and nowhere else.

Its own virtual machine: Every thread runs in its own Vercel Sandbox, with its own disk, processes and network. Threads never share a machine.
Saved when it sleeps: A thread that stops keeps its whole disk as a snapshot, restored when it wakes.
Signed both ways: Aldo reaches a machine only with short-lived tokens signed by that thread's own key. A machine reaches Aldo only through its sandbox API, with its own token.
You can take the wheel: The browser an agent drives runs on its machine. While you've taken control, the agent's input is refused.

02Sign-ins

Your accounts, connected once.

Aldo signs in with each provider's own tools and keeps the result encrypted, never in the conversation.

Official logins: GitHub, Claude, Codex and Grok connect through each provider's CLI login, run in a throwaway machine. GitLab, Bitbucket and Azure DevOps use an access token you create.
Stand-ins on the machine: Your GitHub and Claude sign-ins are added to requests by the machine's firewall. The machine itself holds only stand-ins.
One refresh token, one place: Codex refreshes through Aldo, so its single-use refresh token is never copied into more than one machine.

03The vault

Secrets that stay sealed.

API keys, files and website logins, each sealed on its own. You choose how each one reaches a thread.

Sealed, and never shown again: Each item is sealed on its own with envelope encryption. Once saved, a value can't be read back in Aldo's app or API; you save a new one instead.
Three ways in: A variable in the agent's shell and services, or a file at a path: the agent can read these. Or injected into HTTPS requests to the sites you list: the machine holds only a stand-in, so the agent can use the key but never read it.
Kept out of the record: Vault values never go into Aldo's logs, events or responses to the browser. Service logs on the machine hide them.
Refused on the way out: A push, pull request, comment or caption that contains a vault value is refused before it leaves the machine.
Logins filled, not handed over: Aldo types a saved password into the page after checking the page's origin. The agent asks for the fill; it never handles the password.
Asked for, not pasted in: An agent that needs a secret sends you a link to the Vault form. The value goes to the vault, never into the conversation.

04Reachability

Private unless you open it.

Everything a thread runs is yours alone by default. What's public is public on purpose, and says so.

Owner-only previews: A preview link checks that you own the thread, then hands off with a single-use token. Dev server ports are never exposed.
Only the paths named: For webhooks, an agent makes just the path prefixes it names public. Responses can't run as a page or set cookies, and callers' cookies aren't passed on.
Demos for reviewers: Recordings an agent attaches to a pull request are public at unguessable links, so reviewers can watch them.

05Decisions

Agents act within your policy.

What an agent may do on its own is learned from you, one question at a time, and Aldo holds it to that where Aldo is the one acting.