Skip to content
    SITEOS

    Sovereignty

    Yours to run, on your own servers. Yours to verify.

    Run SiteOS on your own servers, cut off from the internet if you need to, wherever the facility is, and let your accreditor check how it behaved without trusting us. Made by companies in Cyprus (EU) and the United States.

    Request a briefingSee how verification works

    Deployment

    It runs where you put it

    Each option with its honest state, and the limits of running offline today.

    On your servers

    Available

    The backend and web app as containers with Docker Compose, on your hardware, in your network, with your keys.

    Air-gapped

    In progress

    An offline install bundle: PostgreSQL 16, the backend and web app behind Caddy, and an optional local model server. A no-egress mode refuses connections to public addresses at the socket layer.

    Refuse to start unless isolated

    In progress

    A sovereign mode that will not boot while the machine can reach the internet. Built; automated test coverage is still to come.

    Hosted by us in the EU

    Planned

    A hosted option in the Frankfurt region, for teams that do not want to run servers.

    Running offline, honestly

    • Text features can use a local model server through an OpenAI-compatible interface. Image and embedding features still need a cloud provider and are off when egress is blocked.
    • The C2 globe loads online map tiles today. Offline tiles for air-gapped sites are planned.
    • We have not yet recorded an end-to-end air-gapped install. When we do, we will publish it with the clock visible.

    Verify us · offline attestation

    A signed statement your accreditor checks without us

    Your own accreditor has a sharp question: how do I prove this enclave behaved sovereignly last quarter, without trusting the vendor or touching the live system? The attestation is the machine-checkable answer.

    AvailableBuilt and tested. The verifier and a sample file are shared in a briefing.

    What one file proves

    No egress
    The installation could not reach the outside world during the period.Evidence: Self-test result, the socket guard's state and the count of outbound attempts it refused.
    Audit integrity
    Nobody edited or removed a record of what happened.Evidence: The hash chain verified from its first entry: validity, head hash, entry count and any failed writes.
    Human authority
    No engagement was executed by software alone.Evidence: Auto-execution confirmed as prohibited in code, and every engagement released by a second, distinct person.
    Security posture
    How the installation scored on its own measured checks.Evidence: A snapshot of the posture scorecard: the score and each check's verdict.
    Local access
    The system answered only on the networks it was meant to.Evidence: Loopback binding and host-header validation state.

    How an accreditor checks it

    1. The installation signs a period

      An administrator generates an attestation for, say, the last 90 days. The installation gathers the evidence from its own process and database and signs the whole document.

    2. You pin the key once

      The accreditor records the public key id when the system is accredited, through a channel that does not depend on the vendor.

    3. You verify on your own machine

      A standalone script that imports nothing from SiteOS checks the signature against the pinned key, then recomputes the verdict from the evidence inside the file.

    Accreditor's laptop · offlineExample output
    $ python3 verify_attestation.py attestation.json --key-id c4dd45a8492f57d2
SiteOS Defense — sovereign attestation
  key id      c4dd45a8492f57d2
  period      2026-06-02 → 2026-08-31
  verdict     sovereign=True
RESULT: VERIFIED — signature authentic and document internally consistent.
    Example output of the standalone verifier: key id, period, verdict sovereign true, result verified.

    Signature

    Ed25519, using the pinned Python cryptography package. The air-gapped build gains no new dependency for it.

    A dedicated signing key, separate from every other key in the system. Its private half is generated inside the installation, encrypted at rest under the installation's master key and never leaves it. The public half and its key id are handed to the accreditor once, out of band.

    A forgery always fails

    • Change any evidence and the signature no longer matches.
    • Re-sign with another key and the pinned key id no longer matches.
    • Edit only the verdict and the recomputed verdict disagrees with it.

    What it is not

    It is not an accreditation. It is the evidence an accreditation is built from, produced by the system under assessment and checked without trusting us.

    The verifier and a sample file will be published here when the merge lands. Until then we walk through both in a briefing.

    Human authority

    No engagement without two people

    Policies can be rewritten. This is written into the code, and the attestation proves it held for the whole period.

    TrackDetected, fused and classified. Software can suggest; it cannot execute.
    AuthoriseAn authorised commander, with a fresh second factor.
    ReleaseA second person, a different identity from the first.
    RecordBoth names, the time and the evidence, in the audit chain.
    The release path for an engagement. The check auto_execution: "prohibited" is an invariant in code and is proved in every attestation.

    Two-person release

    Available

    Built and tested: an engagement needs a second person, and a rules-of-engagement gate records each authorisation. It records decisions; SiteOS does not drive effectors.

    Detection only for civil sites

    Available

    The platform detects, tracks and alerts. It has no mitigation function, so for a civil operator the power to act stays with the authorities who hold it.

    Overwatch flights

    In progress

    An incident trigger can launch a drone to watch, but only inside a standing flight authorisation a person approved in advance, through the same audited path as a manual launch. There is no emergency override.

    Who builds it

    Developed in the EU, with a US company for US work

    ELEVEN22SPX LTD, incorporated in Cyprus, develops SiteOS. ELEVEN22SPX Inc., a Delaware corporation trading as ELEVEN22SPX USA, runs United States operations.

    Cyprus (EU)

    ELEVEN22SPX LTD

    Role
    Develops SiteOS
    Legal form
    Private company limited by shares
    Register
    Department of Registrar of Companies and Intellectual Property, Republic of Cyprus
    Registration No.
    HE 478582
    Incorporated
    26 July 2025
    Registered office
    Apelli 11, Central Olive 1, 203, 6056 Larnaca, Cyprus
    Director
    Kevin Hani

    United States

    ELEVEN22SPX Inc.

    Trading as ELEVEN22SPX USA

    Role
    United States operations
    Legal form
    Delaware corporation
    Register
    Delaware Division of Corporations
    State File No.
    10413830
    Certificate of incorporation
    Filed 24 November 2025, effective 1 January 2026
    Registered agent
    Harvard Business Services, Inc., 16192 Coastal Highway, Lewes, Sussex County, Delaware 19958, USAThe registered agent's address, not a place of business.

    The full details, as the registers record them, are in the legal notice.

    Your data leaves with you

    Available

    An administrator can export the organisation's data at any time, the same export that answers access and portability requests. Tracks travel in the open formats the platform already speaks, such as Cursor on Target. In your own installation, the database is yours to keep.

    Ask your accreditor what they need

    Bring the questions your accreditor or security officer will ask. We walk through the attestation, the deployment and the gaps, in that order.

    Request a briefingRead the trust center

    A person reads every request

    Request a briefing