Security & data handling
Cryogram is built so that your data has no route to us. Automations are built and run on your own machine, on your own AI keys, and the app works without an account. This page says in plain language what stays local, what the app downloads from us and sends to us, and how sharing and cloud runs handle data for those who use them.
On your machine
Your data stays in your systems
Automations are stateless: each run reads inputs, writes outputs, and keeps none of your business data in between. The documents, records and messages an automation touches live in your own files and systems, and Cryogram keeps no copy. What Cryogram stores on your machine is its own operating state: the automation definitions, run history and settings.
Build material never leaves your machine
The material made while building - your chat with the builder, sample files, and the recorded test results each automation is checked against - is stored locally and is never uploaded. What you send to the AI during a build session goes straight to your AI provider on your own key, under your own agreement with them.
What the app downloads, and what it sends
Everything the app needs ships with it, so a fresh install works offline. When it starts it can check for newer versions of the app and of the skills the AI builds with - each check reads a published file, sends nothing about you, and has its own switch; both downloads are signed and the app checks the signature before using them, and an app update never installs without your approval. In the other direction the app sends exactly one thing, and only when you ask it to: when a run fails you can send us a report about it, shown to you in full before it goes, carrying no account, token or identity of any kind. There is nothing that reports usage, and no account is needed for any of this.
Secrets: the AI sees names, never values
API keys, passwords and tokens are stored encrypted on your machine, are never shown back in the interface after entry, and are never included in anything an AI model reads. Steps receive secrets by name; the values are filled in at the moment a step runs and are removed from outputs and logs. There is no code path that hands a secret value to a model.
Steps run supervised
Automation code runs in its own supervised process, and each automation carries a list of the internet domains it may reach, written during the build and shown to you, with connections to any other domain refused. The code being supervised is code the agent wrote for you and you approved - the supervision is there to catch mistakes, and we don't claim it as a defence against code written to break out of it.
Approval before anything external
Steps that act on an outside system - sending email, writing to a CRM, posting to an API - ask for your approval first. For each automation you decide whether such steps need your confirmation on every run or are approved to run unattended. Irreversible actions are flagged as such.
Every step checks its work
During the build, Cryogram writes checks for each step based on the run it watched. At run time, a result that fails its step's check is never passed on to the next step: the run stops, tells you what failed, and can carry on from where it stopped once the problem is solved. An automation that cannot run correctly stops and tells you; it does not improvise.
Fixes are tested before they are applied
When something changes and a step breaks, the AI investigates what happened and proposes a fix. The fix is applied only after it passes the automation's checks against the recorded results of past good runs. A fix that fails those checks is never applied.
Sharing and cloud runs
Automations can be shared with colleagues, and can run in our cloud on a schedule or an external trigger. Both follow the same rules as everything else. A shared automation runs on your colleague's own machine, reading from and writing to your systems directly; the business data it touches never passes through us, and what our platform records is run metadata: which automation ran, when, and which steps succeeded or failed. Credentials for shared automations are stored encrypted on our platform, handed to a colleague's machine only for the length of a run, and can be changed or withdrawn by you at any time. Cloud runs are a per-automation choice, isolated per customer, encrypted in transit and at rest, with outbound network access refused except to the domains the automation declares. Anything a step sends to an AI model still goes through your keys, never ours.
Your AI provider
Cryogram is not a model provider. During building and repair, content you choose to work with is processed by your AI provider on your key, under your agreement with them. Once an automation is built, only the steps that need judgement call a model at all; the routine majority of a run calls no model.
This website
The waitlist form is operated by Tally, our form processor; what we collect and why is described in the privacy policy. This site sets no advertising trackers.
Reporting a vulnerability
If you believe you have found a security issue in Cryogram or this site, email security@cryogram.app. We read every report and will respond promptly. Please give us reasonable time to fix the issue before public disclosure.