Security and updates

Cerevisor runs on your machine and keeps your work there. This page says what leaves it, what an agent is allowed to do, how to reach me if you find a problem, and how to check that the installer you downloaded is the one I published.

What leaves your machine

Cerevisor sends no telemetry. There are no usage analytics and no crash reports.

The app contacts three places on its own:

1. Update check. When the app starts, it asks releases.cerevisor.com whether a newer version exists. The request carries your IP address and a random id the updater created on this computer (the .updaterId file in the app's data folder). It carries none of your work. When a newer version exists, the app downloads it in the background. Turn the check off in Settings, Updates, "Check for updates automatically". The "Check for updates" button still works when it is off.
2. Licence validation, only if you activated a paid plan. When you activate, your licence key and a hashed name for this computer go to Lemon Squeezy (api.lemonsqueezy.com). After that, your licence key and an instance id go to Lemon Squeezy about once a day. No content and no usage data go with them. If their server cannot be reached, paid features keep working for 14 days after the last successful check.
3. The skill-matching model. With semantic skill retrieval on (the default), the app downloads a small model, about 23 MB, from Hugging Face (huggingface.co) the first time it starts. It keeps the model in ~/.cerevisor/model-cache and loads it from there after that. Turn it off in Settings, Skills, "Semantic skill retrieval", Off.

Everything else goes to services you set up yourself: the model providers you connected, a web search provider if you added one, MCP servers you enabled (they connect when the app starts), a decision model if you added its key, Outlook if you connected it, and any web address you put in a hook.

Cerevisor calls your model providers with your own keys or sign-ins. It does so when an agent runs, when you use the chat builder, for background work such as a run's retrospective, and to list a provider's models. I never sit in the middle of that traffic.

What Cerevisor stores about you, and the consent flags for any future sharing, are in Data inventory and consent.

How agents are contained

These checks apply to agents in Cerevisor's own loop (Anthropic, OpenAI-compatible and Gemini providers).

• Every tool call such an agent makes during a workflow run passes through ten stages that can only narrow what is allowed. A stage that tries to widen it is refused, and the call is denied.
• An agent's file tools read and write only inside the workflow's folder and the files you declared for that agent. They may also read your installed skills.
• By default, a shell command that names a place outside the folder asks you first. In a run nobody is watching, that command is refused.
• Content an agent reads from the web (including through the browser tool), from email, from an MCP server you have not marked trusted, from a shell command that fetches from the network, or from a file outside the workflow's folder is marked untrusted.
• An agent holding untrusted content must ask you before it sends data to a site that is not on the workflow's approved list. In a run nobody is watching, that send is refused.
• If that agent also holds a secret, the send is blocked for the rest of the run. That is the Rule of Two, and the app enforces it in code, not in the prompt.

Secrets and shared files:

• Secrets you save in the vault are encrypted with your operating system's key store (Keychain on macOS, DPAPI on Windows). On Linux without a keyring service, they are stored unencrypted in your user folder.
• An agent receives a secret as an environment variable, or where a tool call names it as a placeholder, when the tool runs. Cerevisor never writes a secret's value into an agent's instructions.
• A shared workflow package someone sent you is checked and cleaned again before anything is written. It cannot write into Cerevisor's own folders. Nothing in it runs when you open it, and its first run shows the same summary any new workflow does.
• Opening a workflow file never makes the app look up a network share, unless the file itself is on that share.

Harnesses that own their own loop (Claude Code, Codex, Cursor, Antigravity) run outside the checks above. Cerevisor says so in the pre-run summary. It records what it handed each harness in the run's history, and it checks which files changed after the harness finishes. Grok Build is the exception: unless its sign-in is set to approve everything, Cerevisor decides each of its tool calls before it runs.

Reporting a problem

Email security@cerevisor.com. My targets are an acknowledgment within two working days, a first assessment within seven days, and a released fix for a confirmed issue within thirty days. Only the latest release receives fixes.

Updates and installers

• Releases are built by the Release workflow on GitHub Actions from the tagged source code. It publishes them to releases.cerevisor.com, which is where the built-in updater looks.
• The one recorded exception is 3.1.1 for Windows, which I built on my own machine while GitHub Actions could not start jobs. Its release note says so.
• From 3.7.0 on, each release publishes a SHA256SUMS-<platform>.txt file beside its installers on releases.cerevisor.com. Compare it with the checksum of the file you downloaded before you install. On Windows, run certutil -hashfile <installer> SHA256. On macOS, run shasum -a 256 <installer>.
• The checksum file comes from the same server as the installer. It catches a damaged download, not a tampered server.
• Windows installers are not code-signed yet, so SmartScreen warns on first install.
• macOS builds are signed with an ad-hoc identity and are not notarized, so macOS warns the first time you open the app. Install Cerevisor shows how to allow it.
• Until certificates are in place, the checksum is the check you have. The release note will say when that changes.
• The built-in updater downloads over HTTPS. While it downloads an update, it can request a file named after your installed version, which tells releases.cerevisor.com which version you have. Before it offers to install, it checks the file against the SHA-512 listed in the release's update manifest (latest.yml).
• That manifest is not signed and comes from the same server as the installer. The check catches a damaged download, not a tampered server.
• Updates never depend on your licence state.
• On macOS, the app switches its updater off when it cannot verify its own code signature. It then asks you to download the new version from cerevisor.com.
• From 3.7.0 on, every release note will have a Security section naming the Electron version shipped and the dependency advisories closed or still open.