What runs where, and who can touch it.

On your Mac

• The local service listens only on 127.0.0.1. Every request needs a token, and any request carrying a browser Origin is refused.
• VM disks and build files stay on the machine. GitHub still receives the logs, artifacts and caches your workflows upload, exactly as with any runner.
• Vectis stops only the processes it started and tracks. It never kills by name, and it cleans up only after it has evidence that a process exited.

In the Vectis cloud

• The cloud coordinates identity, GitHub access and remote commands. It stores your account ID, linked GitHub logins and installations, machine names, environment summaries, repository connections, job states and operation results. Workflow files read for a migration preview are kept for 24 hours. Answers to remote queries, such as status or recent service log lines you ask a Mac for, pass through the cloud and are kept for about a minute. A daily sweep deletes finished jobs and operations after 90 days, and runner and webhook records after 30.
• Machine and controller credentials stay in Keychain on each device. The cloud keeps only their fingerprints, and GitHub user tokens are used during verification and never saved. Removing a Mac, unlinking a GitHub account or deleting your account deletes the records behind them.
• The GitHub App private key, client secret and webhook secret, and the key that signs short-lived machine tokens, live only in the cloud. The single-use runner configuration it creates is deleted once the runner is released, and after 15 minutes at the latest.

Inside a guest

• Guests receive no host folders, no Docker socket and no host credentials. The GitHub App key never reaches a guest.
• Vectis talks to guests over SSH with pinned host keys and without agent forwarding. The only GitHub credential a guest sees is the single-use runner configuration for its one job.
• Each VM is deleted after its job. The next job starts from the clean image again.

Public repositories and forks

• A public repository must require approval for all outside contributors before Vectis will run its jobs or publish a migration. A weaker or unreadable policy blocks both.
• Vectis never changes that policy and never approves a workflow run. Forks do not inherit your runners.
• This is an approval-based trust model. It is not a guarantee against arbitrary hostile workloads, so approve outside changes the way you would for any self-hosted runner.

Remote control

• Remote commands are queued in the cloud and collected by each Mac over an outbound connection. No machine needs an open port.
• A command for an unavailable Mac waits or fails. It never falls back to running on the Mac you are using.
• Controllers are approved in the browser with a verification code, expire after 90 days, and can be revoked at any time. The service itself cannot be installed or stopped remotely.

Reporting a vulnerability