MacOrb / Trust & transparency

Security

Last updated: September 18, 2026

How credentials are stored

Each credential gets its own random 256-bit data key and is encrypted with AES-GCM. That data key is itself encrypted under a separate key-encryption key held in Cloudflare's secret infrastructure. The database row holds ciphertext, nonces, the encrypted data key, and a key version. It does not hold the credential.

The encryption binds each value to one MacOrb account and one credential type. A row copied to another account, or moved between the Amp key and the GitHub token, fails to decrypt rather than opening.

MacOrb decrypts a stored credential in two places. It decrypts the Amp key, and the GitHub token when you name a repository, while starting a Mac. It also decrypts inside the service to answer the question “is a credential saved?” when the console or the API reports status. Status is all that leaves: saving a credential returns no value, no prefix, and no length.

On a running Mac

Starting a session sends the decrypted credentials to Namespace as part of the instance configuration. The Amp key is what the runner authenticates with. When you ask for a repository, the boot script signs GitHub CLI in with your token so the clone can happen.

GitHub CLI keeps that token on the Mac: in the macOS keychain when the keychain is available, otherwise in its own configuration file in plain text. MacOrb registers GitHub CLI as git's credential helper instead of writing the token into the checkout, so it does not land in the repository's git configuration. Even so, programs and agents on that Mac can read and use both credentials.

Give the GitHub token only the repositories and permissions the work needs, with a short expiry. Check what the Amp key can do before you paste it. Keep credentials out of prompts, repository files, and bug reports.

Your sign-in session

Signing in sets a signed HttpOnly cookie that is valid for seven days. The same token can be used as a bearer token by the MacOrb CLI and plugin. Treat it as a password.

The token is stateless. There is no server-side revocation list today, so signing out clears the cookie in that browser and nothing more. A copy of the token that already exists elsewhere keeps working until it expires. Anyone holding a valid token can act as your account, including starting and stopping Macs.

Who can see what

• MacOrb's operator runs the service and can reach its database, logs, configuration, and the list of running Macs. Logging is written to redact secrets, and the operator is still inside the trust boundary.
• Cloudflare runs the application and the database, and holds the key-encryption key.
• Namespace runs the Mac and receives the configuration needed to boot it, including the credentials that Mac will use.
• Amp and GitHub receive their own credentials when the runner and GitHub CLI authenticate. Their terms apply to what happens there.

Removal is not revocation

The console can replace or remove either stored credential. Replacing overwrites MacOrb's row. Removing deletes it. Both change what future sessions receive.

Neither one revokes anything at Amp or GitHub, and neither reaches a Mac that already has the credential. If a credential may have been exposed: stop any running session, then revoke or rotate it with Amp or GitHub. Issuer-side revocation and short expiry are the controls that actually work.

Reporting a vulnerability

Security reports: support@macorb.dev.

Please give us a chance to fix an issue before you publish it. There is no bounty programme; there is a person who will read your mail and fix the thing.