You don't have to take our word for it.

Verify it yourself

These are the claims our pages make about sovereignty, one by one. The tests ship with the hub's software, and most commands below run on the hub itself, in the folder Elysium is installed in: /opt/elysium on an appliance. They need a shell on the hub. An appliance ships with remote login switched off and no known console password, so shell access has to be set up when the hub is provisioned.

Your hub also has a trust page of its own, at hub.local/trust on your home network unless you gave the hub another name. It shows how to trust the hub's certificate and what remote access reveals, and while the hub's reasoning runs in the cloud, it lists what leaves.

1. Out of the box, it runs in Sovereign mode.

   How it works

   A hub ships set up to sign residents in on the hub, with no Anthropic or OpenAI key, and with every model running on the hub, the one that picks out memories included. As shipped, it refuses a switch to Hybrid from the dashboard: opening Hybrid takes a change to its configuration.

   The test

   Sections 1 and 2 of the self-test read the settings the running services use. They fail if sign-in does not run on the hub, if cloud sign-in settings are present that the owner has not linked on purpose, or if a cloud key is set or memory extraction is not local while reasoning stays on the hub. With --expect-posture sovereign, any other posture fails the run.

   What it cannot see

   It reads the settings the services run with and does not inspect their code. Without the flag, a hub whose owner deliberately linked a cloud account passes, and its report names that posture.

   Run it yourself

   On the hub, in the install folder:

   ./scripts/sovereign/sovereign-selftest.sh --expect-posture sovereign

2. In Sovereign mode, nothing it learns leaves the house.

   How it works

   Reasoning, memory and sign-in run on the hub, and when the local model fails, the request ends in an error message instead of going to a cloud service. Six kinds of outside contact stay off until someone in the household turns them on: public-data lookups such as the weather, web search, a connected email account, a tool server, remote access, and downloading another local model. One kind is on as the hub ships: its Matter controller downloads the Matter standard's public lists of device certificates and makers when it starts and once a day. When you pair a device, it also checks the device's certificates with the standard's public register and, if the device's maker lists one there, with the maker's server; both can then tell that a device of that maker is being added from your home's internet address.

   The test

   Section 3 of the self-test reads the connection table of every service the hub runs and fails if any of them holds a connection to a public address. Section 5 fails if a service listens on a public address. Section 6 reports whether public-data lookups are on, names the search engine web search would use, and lists the connections the hub's operating system holds.

   What it cannot see

   It sees the connections open at the moment it runs, so one that opens and closes between two runs goes unseen. It sees TCP connections and connected UDP sockets: a UDP packet sent without connecting leaves no entry. It does not list connected email accounts, tool servers, model downloads or the Matter controller's contacts, and cannot see side channels such as the timing of traffic. For evidence that does not depend on our software, watch the hub's traffic on your router.

   Run it yourself

   On the hub, in the install folder:

   ./scripts/sovereign/sovereign-selftest.sh

3. Pull the internet cable, and your home still answers.

   How it works

   The model, memory, sign-in and the hub's own Matter controller all run on the hub, which reaches your devices over your home network and Thread.

   The test

   With the cable unplugged, run the self-test with --strict: its section 4 then dials a public address from every service and fails if any of them gets through. The rest you check by hand: ask The Butler something, sign in from a phone on your home network and switch a light.

   What it cannot see

   It shows that no service can reach the internet; using the house is your part of the check. It fails while cloud reasoning is on, or while remote access is on and you have given it the tunnel's address, because a hub cannot be cut off and reach the cloud at the same time. Today it fails on a hub as shipped even with the cable unplugged: it fails on any service it cannot probe, and the database service has none of the tools its probe uses.

   Run it yourself

   Unplug the cable, then on the hub, in the install folder:

   ./scripts/sovereign/sovereign-selftest.sh --strict

4. Sign-in works offline.

   How it works

   Accounts live on the hub, which checks passwords and issues sign-in tokens itself. A cloud account comes into it only if the owner links one, and the local password stays the main way in even then.

   The test

   Section 1 of the self-test fails unless sign-in runs on the hub, in every posture, and fails on cloud sign-in settings the owner has not linked on purpose.

   What it cannot see

   It checks the setting the sign-in service runs with. The direct check is signing in with the cable unplugged, which only you can do on your hub.

   Run it yourself

   With the cable unplugged, sign in at the hub's address. To check the setting behind it, run this on the hub, in the install folder:

   ./scripts/sovereign/sovereign-selftest.sh

5. In Sovereign mode, there is no cloud fallback.

   How it works

   In Sovereign, the hub's reasoning service may use only the hub's own models. When the local model fails, you get an error message and the request goes nowhere else.

   The test

   An end-to-end test starts a test hub whose local model fails every request, with a cloud key planted on it, and sends a chat message. It fails if the logs show a fallback, or if the reasoning service holds a public connection in any of its samples, taken every 0.2 seconds. Section 6 of our report describes a run during development: 15 samples taken across a failing conversation showed no public connection.

   What it cannot see

   It runs on a test copy of the hub, sends one chat message and samples only the reasoning service. A connection shorter than the gap between two samples could be missed.

   Run it yourself

   On the hub, or on any computer with Docker and a copy of its install folder. It builds its own images, so it needs the internet, and it uses its own containers and data and leaves your hub's alone:

   ./scripts/sovereign/sovereign-failclosed-e2e.sh

6. Updates are signed, and install only when you start them.

   How it works

   The hub installs a release only after checking its signature against the public key in its system image, refuses a release that is not newer than the one it runs, and asks you to confirm before it changes anything. Nothing on the hub fetches releases by itself: you bring one in on removable media, or download it over your own connection, which opens one connection to the release server for the download. The signature check fails if a new outside connection appears while it runs, and the appliance image turns off the operating system's own update timers.

   The test

   An end-to-end test signs real releases and checks that a tampered release, a wrong signature and an older release are refused before anything changes, that a newer release is accepted, and that checking a release opens no outside connection. Section 6 of the self-test reports whether the operating system polls for package updates on a timer.

   What it cannot see

   Every update rests on our signing key, which you trust without being able to check it. The key that will sign releases for owners has not been made yet; today the image is built with a development key. Updates to the operating system and the graphics driver are outside this signed path, and you install them by hand. If an installed release fails its health check, the hub goes back to the previous one; that path has so far been tested only against a simulated container runtime.

   Run it yourself

   On the hub, in the install folder. The update tool runs as root, so both commands start with sudo. The first checks a release and changes nothing; the second shows the release that is installed:

   sudo ./scripts/sovereign/sovereign-update.sh --bundle /media/usb/elysium-release-<version>.tar --dry-run
   sudo ./scripts/sovereign/sovereign-update.sh --status

7. Video and device control stay on the hub, in Sovereign and in Hybrid.

   How it works

   Only a hub carries out device commands: its own API queues each one, and its Matter controller sends it over your home network and Thread. In Hybrid a cloud model can choose a command, from the device states the Hybrid list names, and the hub still carries it out. Camera support is in development, so no part of the product handles video yet.

   The test

   In Hybrid, section 3 of the self-test accepts outside connections from the reasoning service alone. It still fails if a service that carries out device commands, or any other service, holds one.

   What it cannot see

   There is no camera code to test yet. The test sees connections and cannot see what travels over them, so in Hybrid it cannot tell what the reasoning service sends.

   Run it yourself

   On the hub, in the install folder:

   ./scripts/sovereign/sovereign-selftest.sh

8. In Sovereign mode, nothing it hears leaves the house.

   How it works

   The wake-word check, speech recognition and the spoken voice run on the hub. Cloud speech and cloud follow-up detection are Hybrid options, and each checks the hub's mode before it contacts a cloud service, so neither reaches one while the hub is in Sovereign, even when it is configured.

   The test

   Section 6 of the self-test reads the speech settings: a cloud option that is configured shows as withheld unless the hub's reasoning runs in the cloud, and as on when it does.

   What it cannot see

   It reports settings and fails on none of them; whether anything leaves is then for the connection check of section 3, with its limits. The always-on voice front end is still being integrated.

   Run it yourself

   On the hub, in the install folder:

   ./scripts/sovereign/sovereign-selftest.sh

9. In Hybrid, the app lists what leaves before you switch.

   How it works

   Before an admin switches to Hybrid in the dashboard, it shows the hub's list of what Hybrid sends, asks for the local password and records when they accepted the list. Switching back to Sovereign takes effect from the next request. The list itself is on How it works.

   The test

   The list is kept in four places: the dashboard, the hub's own trust page, the self-test and this website. Our tests fail when any copy differs from the others. On a hub whose reasoning runs in the cloud, section 2b of the self-test prints the list.

   What it cannot see

   These tests keep the copies identical and do not watch traffic. In Hybrid, section 3 accepts the reasoning service's outside connections, so it cannot show which items on the list travel.

   Run it yourself

   Open the hub's own trust page, and on a Hybrid hub run this in the install folder:

   ./scripts/sovereign/sovereign-selftest.sh

What this website keeps

What elysium-labs.ai records when you visit, in short. Our privacy policy is the full text, and the numbers here come from the same source as its numbers.

Cookies and browser storage

The pages set no cookies when you read them, and no cookie is used for analytics, advertising or tracking. You can check in your browser's developer tools: the responses of the pages carry no Set-Cookie header. Cookies come only with things you do. Signing in, or connecting Google to your account, uses our own cookies (elysium_session, elysium_access, elysium_refresh, elysium_oauth_state and elysium_oauth_link), and while you are signed in the site renews your session. When your browser uses our API, for example to sign in or in Ask Elysium, the load balancer in front of it sets AWSALB and AWSALBCORS, which last 7 days. In your browser's storage the site keeps a few items for your chosen language and for Ask Elysium (els-lang, els-orb-sound, els-ask-thread-v1:… and els-ask-chat-id). The privacy policy says what each one is for.

Other companies' servers

The pages load no scripts, fonts or images from other companies' servers. Each page apart from sign-in and your account sends a Content Security Policy that lets your browser load scripts, styles, fonts, images and media only from this site, and connect only to this site and our API. Visiting this website in our privacy policy says what our servers log.

Content delivery network

Your requests to elysium-labs.ai and www.elysium-labs.ai can first reach Amazon CloudFront, the content delivery network of Amazon Web Services, at an edge location near you, which may be outside Switzerland. It sends a page from its own copy when it has one, and otherwise passes the request on to our servers in Zürich. It keeps copies only of pages and files that are the same for every visitor. We have not turned on its access logs, so it keeps no log of your requests for us. For a request that came through it, the IP address in our load balancer's log is CloudFront's. Visiting this website in our privacy policy has the details.

Counting visits

Each page you open, apart from your account pages, sends our API one count holding four things: the page, its language, the host name of the site whose link brought you to it, and whether your window is the size of a phone, a tablet or a computer. The API adds it to a daily total that holds no IP address, no cookie and nothing that identifies you or your browser. If your browser sends Do Not Track or Global Privacy Control, your visits are not counted. We keep the totals for 13 months, and our team's report withholds every total from 1 to 4. The count still passes our load balancer, whose log keeps your IP address and your browser's user agent for 30 days, and on a day with few visits that log and the totals can be read together. How we count visits has the details.

Ask Elysium

If you are not signed in, we keep no copy of your conversation, and your browser keeps it until you close the tab or start a new chat. If you are signed in, we keep your questions and the answers with your account for 180 days. A rating of an answer is kept for 180 days. To prevent abuse, counters hold your IP address for up to 24 hours, and the record of a paused chat, with your IP address, is kept for up to 7 days after its last pause. Anthropic writes the answers and OpenAI turns each question into a search vector; neither uses your text to train its models, and both may keep it for a limited time to detect misuse. Ask Elysium in our privacy policy has the details.

Early-access requests

A request holds your email address, the page and form you used, the page's language, when you asked, which version of our notice you saw and how your visit began: the host name of the site that linked to this one and the campaign tags of the first page you opened, neither of them if your browser sends Do Not Track or Global Privacy Control. If you are signed in, it is linked to your account. We also keep a scrambled form of your address, to limit the emails it receives, and a record of each email we send you about the request. If you do not confirm it, we delete it within 7 days of your last request; a confirmed request stays until you remove it, delete your account or we close the list. Each email we send automatically about it has a link that removes it. The early-access list in our privacy policy has the details.

Logs and backups

Our load balancer logs each request it passes on: the IP address it came from, the address requested, the time, the user agent and the result. Our API logs the requests it receives, apart from the visit counts. We keep these logs for 30 days. Records of network connections, with IP addresses and ports but no content, are kept for 14 days, and database backups for 7 days. How long we keep data lists every period.

Who receives data, and where

The companies that receive personal data from this website, Ask Elysium and the hosted Elysium app, where they are and what they do for us. This is the list in our privacy policy, read from the same source, so the two always match. The policy also gives the safeguard that applies to each.

Report a security problem

Write to security@elysium-labs.ai. Our security policy says what you may test, how to test in good faith and the safe harbor we give researchers. The same contact is published in machine-readable form at /.well-known/security.txt.