Caedos
GitHub ★ Start →

SECURITY

What we protect, how, and what we don't yet.

Caedos runs on your machine and holds credentials that can post to your channels. Here is exactly how it treats them. Its source isn't public, so this page also says how to check it yourself.

Verify a download Report a vulnerability

At a glance

Where it runs Your machine. One program. Listens on 127.0.0.1 by default.
Authentication None yet. Single operator.
Other websites Refused. A page from another site can't drive the control room's API.
Secrets at rest AES-256-GCM, a fresh 12-byte IV per value.
Secrets in traces Never.
Outbound actions Leashed by default: queued for your approval.
Sources Read only. A source pointed at a write waits for your approval like an action.
Telemetry None. No license check, no update check.
Downloads SHA-256 checksums, signed with an Ed25519 release key.
Dependencies Four direct runtime dependencies (Hono, Zod, React, React DOM) and seven runtime packages in total.
License Elastic License 2.0. Closed source: you get the program, not its code. Source review under contract.

Where it runs

Caedos listens on 127.0.0.1, port 2233. To listen on your network you must set CAEDOS_HOST, and Caedos prints a warning at startup: "The API has no auth yet — anyone who can reach this port controls every process." We mean it. Put it behind your own VPN or authenticating proxy if it has to be reachable.

Other websites

The control room's API takes no token: whatever reaches its port on this machine is trusted. A browser could carry a page from any website there, so Caedos refuses two kinds of request before anything runs: one whose Origin isn't the control room's own, and one addressed to any name but localhost or 127.0.0.1, which stops DNS rebinding. Programs on your machine, such as your AI's MCP client or curl, send no Origin, and get through.

Secrets

  • Stored in an encrypted vault in the SQLite database: per process, plus a workspace vault for shared connections and channels.
  • The key is 32 random bytes created on first run: vault.key, beside the database in the data folder. Anyone with both the database and the key can read your secrets, so treat that folder like a password file.
  • A secret is resolved only inside the step that uses it. Trace summaries are rendered from a copy with secrets masked.
  • The approval queue stores references to secrets, never values. They're resolved when you approve.
  • Anything that becomes public (a shared journal, a published page) is checked at deploy: a $secrets reference there is rejected.
  • Workspace exports never include credentials; they list which ones to re-enter.

The leash

  • Deploying a synth whose actions can touch the outside world sets approval_mode: required under the default policy.
  • Each queued action shows a one-line summary of what it would send. Approve or reject it individually.
  • Allow (removing the leash) is a button in the control room. It isn't one of your AI's tools, and no MCP tool presses it. But an AI that can run commands on your computer can do anything you can, including Allow: the local API has no sign-in, and trusts whatever reaches its port on this machine. That's one reason Caedos listens only on localhost.

Sources can't write

  • A source is there to read. One pointed at a write, with any HTTP method but GET or HEAD, or an MCP tool that isn't marked read-only, counts as an action: shadow never sends it, and a live tick holds it for your approval until you press Allow.
  • No synth can reach Caedos's own API, by any address or method, so none can press Allow for itself.
  • Synths reach only http and https addresses, so none can read files on your disk. Link-local addresses, where cloud machines hand out their credentials, are refused too. The rest of your network stays reachable, because watching your own services is a real use.

Guardrails

  • Per-process daily model budget and hard daily caps on spend and ticks.
  • Workspace ceilings every process inherits; they can only tighten a process's own limits.
  • An allowed-domains list for outbound API calls with literal URLs.
  • A circuit breaker that halts a process failing the same way repeatedly.
  • Shadow mode: real reads, muted actions, nothing persisted to the live process.
  • Webhook triggers can verify an HMAC-SHA256 signature.

What your model provider sees

When a process reasons, the prompt, including the data the process observed, goes to the provider you chose (Anthropic, OpenAI or xAI), under your key and their terms. Processes that never reason never send anything to a model.

Data flow

Data flow Sources (APIs, pages, feeds, MCP tools, webhooks) flow into Caedos on your machine, which holds SQLite (processes, traces, memory) and a vault (encrypted secrets). From Caedos, data goes to the model provider only when the gate fires, and to destinations only for what you allowed. Nothing flows to us. Sources APIs, pages, feeds, MCP tools, webhooks Caedos on your machine SQLite processes, traces, memory vault encrypted secrets Model provider only when the gate fires Destinations only what you allowed Data flow Sources (APIs, pages, feeds, MCP tools, webhooks) flow into Caedos on your machine, which holds SQLite (processes, traces, memory) and a vault (encrypted secrets). From Caedos, data goes to the model provider only when the gate fires, and to destinations only for what you allowed. Nothing flows to us. Sources APIs, pages, feeds, MCP tools, webhooks Caedos on your machine SQLite processes, traces, memory vault encrypted secrets Model provider only when the gate fires Destinations only what you allowed
Nothing flows to us.

Telemetry

None. Caedos contains no analytics or usage reporting, checks no license and never checks for updates. The only outbound connections are to your model provider, the sources and destinations your processes name, the MCP servers you connect, and the public MCP registry when you browse it.

Bun, the runtime built into Caedos, uploads a crash report when it crashes on Windows or macOS. Caedos switches that off. On Windows it does so by running your command in a second copy with reports off, while the first copy only waits for it.

Check it yourself

  • Watch what it connects to. Run Caedos under a firewall or network monitor. You should see only your model provider, what your synths name, your MCP servers, and the MCP registry when you browse it.
  • Check each download. Every release's checksums are signed with the Caedos release key. Verify a download.
  • Leave whenever you like. Your synths are plain JSON or YAML, and caedos export saves your whole workspace to one file, without secrets.
  • Read the source under contract. A company that needs to can review it; ask.
  • If Caedos stops, the source of its last version is released under the Apache License 2.0: after 18 months with no new release, and no notice on caedos.com or in the caedos-run repository that work continues.

Verify a download

Each release ↗ has SHA256SUMS, the SHA-256 of every file, and SHA256SUMS.sig, its Ed25519 signature by the Caedos release key. Save this key as caedos-release.pub.pem: 

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAeBpo421IZkUVLfc27/YSr+nebeFyfTgixtQjpPQCoUQ=
-----END PUBLIC KEY-----

Then, in the folder with your download, check the signature and the file:

openssl pkeyutl -verify -pubin -inkey caedos-release.pub.pem -rawin -in SHA256SUMS -sigfile SHA256SUMS.sig
sha256sum --check --ignore-missing SHA256SUMS

Both need OpenSSL 3. On Windows, Get-FileHash prints a file's SHA-256 to compare with SHA256SUMS. The install scripts check the checksum for you, and install.sh checks the signature too when OpenSSL 3 is installed.

Reporting a vulnerability

Email [email protected]. Please include steps to reproduce. We'll acknowledge within 3 business days.

FAQ

Can my AI approve its own actions?

Allow isn't one of your AI's tools: it's a button in the control room, and no MCP tool presses it. But an AI that can run commands on your computer can do anything you can, including Allow. Caedos has no sign-in yet and trusts whatever reaches its port on this machine, which is why it listens only on localhost.

Where do my API keys live?

In an encrypted vault in the local database (AES-256-GCM), with the key stored beside it. They're resolved only inside the step that uses them, and never written to traces, exports or public pages.

What happens when a source breaks?

The tick records the failure and moves on; a rate limit is weather, not a bug. If the same failure repeats, the circuit breaker halts the process. If a process stalls, Caedos may attempt a bounded repair that's rehearsed before adoption. If it gives up, it writes an autopsy.

Does it check licenses or phone home?

No. There's no telemetry, no license check and no update check. Caedos connects only to what you set up: your model provider, what your synths name, your MCP servers, and the public MCP registry when you browse it.

Can I run it on a server?

Yes: Linux, macOS or Windows, and caedos service install starts it when you sign in. It has no sign-in of its own yet, so keep it on localhost and reach it over SSH, or put it behind your own VPN or authenticating proxy.

Is it open source?

No. Caedos is closed source: you get the program, not its code. It's free for personal use and for work under the Elastic License 2.0. You can still check what it does: watch what it connects to, check each download's signature, and export your work whenever you like. Check it yourself.

What if Caedos stops?

If Caedos is discontinued, we release the source of its last version under the Apache License 2.0. Discontinued means no new release for 18 months, and no notice in that time, on caedos.com or in the caedos-run repository, that work continues.