Sikkerhed hos sSystm

Zero trust er ikke vores politik.
Det er vores arkitektur.

De fleste platforme beskytter én stor database og håber, at murene holder. sSystm byggede aldrig den store database: hver organisations poster ligger i deres egen D1 på deres egen Cloudflare-konto. Blast radius for enhver hændelse er én lejer — by design.

Arkitekturen

Seks vægge,
alle bærende.

Intet af dette er et compliance-afkrydsningsfelt, der er boltet på bagefter. Hver enkelt er, hvordan platformen er bygget — og hvert udsagn nedenfor kan verificeres i produktet.

Dine data har ingen naboer.

Hver organisation får sin egen D1-database på sin egen Cloudflare-konto. Én lejers hændelse forbliver én lejers hændelse — og hvis en forbindelse bryder, fejler API'et lukket.

getByocDb(org) → your D1, on your account

EU betyder EU. Håndhævet.

Vælg EU ved login, og din database oprettes med D1's jurisdiktionsgaranti — infrastruktur, ikke et løfte i en privatlivspolitik. Verificeret efter oprettelse, uforanderlig for evigt.

create { jurisdiction: "eu" } · verified after creation

21 nøgler. Aldrig en masternøgle.

Ingen bred API-nøgle — OAuth-tilladelsen beder om 21 finkornede scopes, hver ærligt risikomærket: safe, risky eller destructive. Læs hele tabellen, før du giver noget.

21 scopes · 8 groups · risk-labelled in the docs

Tokens en database ikke kan lække.

Dine Cloudflare-tokens er AES-256-GCM-krypterede med en frisk IV hver gang, under en nøgle, der kun lever som en server-hemmelighed. Dekrypteret i det øjeblik en handling kører — aldrig før.

AES-256-GCM · random 96-bit IV per token

Ingen kodeord. Intet at phishe.

Én vej ind: Log ind med Cloudflare. Intet kodeordsformular, ingen login-database at dumpe — din MFA og dine passkeys bliver, hvor de allerede bor. Tilbagekald tilladelsen, og sSystm er ude.

one way in: Cloudflare OAuth

AI'en spørger først.

AI-foreslåede infrastrukturhandlinger risikoklassificeres — og alt, der ikke beviseligt er read-only, venter som pending, indtil et menneske godkender. Hvem, hvornår og hvert API-kald: logget.

risky | destructive → pending_approval, always
Strukturel isolation

Ingen delt database.
Ingen blast radius.

Hver organisation kører i sin egen database på sin egen Cloudflare-konto. Der er intet centralt lager at bryde ind i — og ingen vej fra én lejer til en anden.

Isolation i dybden

Fire lag mellem
dig og alle andre.

Lejer-isolation er ikke én væg — det er samme princip gentaget på hvert lag af stacken: database, forespørgsler, vektorsøgning og realtid.

Scoped på hvert lag.

Én lejergrænse kan fejle. sSystm tegner samme grænse fire gange i fire forskellige systemer — direkte fra koden:

  1. 1En database per lejerAPI'et resolver din organisations egen D1-database på din egen Cloudflare-konto for hver request, der rører dine poster — og fejler lukket, hvis det ikke kan.
  2. 2Org-scoped by designHver MCP-token mapper til én bruger i én organisation, og hver forespørgsel scopes server-side. Din AI kan strukturelt ikke nå en anden organisations data med din token.
  3. 3Vektorsøgning i ægte partitionerKomponent-embeddings ligger i et Vectorize-namespace per organisation — en ægte partition, ikke et metadata-filter. En søgning i dit namespace kan fysisk ikke returnere andres vektorer.
  4. 4Realtidsrum, ét per orgDurable Objects — agent-runtime, chatrum — adresseres med din organisations id. Samme org når altid samme isolerede instans; ingen anden kan.

Lejer-isolation er ikke én væg — det er samme princip gentaget på hvert lag af stacken: — org acme

  • Databaseacme's own D1, on acme's account · jurisdiction: eu
  • Vector searchnamespace: acme — a real partition, only acme's vectors
  • Real-time roomidFromName("acme") — the same isolated instance, every time
  • ✗ Reach another org's dataNo path exists. The isolation is structural, not a WHERE clause.

Grunden, det står på

  • Alt kører på Cloudflares edge-netværk — Workers til compute, D1 til data, Vectorize til embeddings, Durable Objects til realtid. Ingen servere hos os at patche, ingen diske hos os at miste.
  • Din infrastrukturleverandør er Cloudflare — samme platform, dine egne sites sandsynligvis allerede stoler på — og dine sSystm-ressourcer ligger i din egen Cloudflare-konto, synlige i dit eget dashboard.
  • BYOC betyder, at udgangen er indbygget: tilbagekald OAuth-tilladelsen i dit Cloudflare-dashboard, og sSystm er udelukket. Din database og dine data bliver hos dig.

Én ærlig note: vi vifter ikke med compliance-badges, vi ikke har fortjent. Det, vi hævder, er arkitektur — og hvert udsagn på denne side kan tjekkes mod produktet. For den kontraktuelle side, se vores databehandleraftale.

FAQ

Common questions.

Where does my data live?
In a database on your own Cloudflare account — your own D1, in the jurisdiction you pin. There is no central sSystm database holding your data. See Enterprise.
Is there a central database to breach?
No. Each customer runs on their own D1, so the isolation is structural, not a WHERE clause you have to trust. There is no shared store to break into.
How is data residency enforced?
It is pinned at the Cloudflare D1 layer — the database itself is created in the region you choose, so residency is where the data physically sits, not a policy setting.
How are tokens and secrets stored?
Encrypted with AES-256-GCM, each token sealed with its own random IV. Plaintext secrets are never written to disk.
Can I revoke access, and is the AI gated?
Yes. Revoke the OAuth grant and access is cut instantly. Every AI write is human-gated — nothing changes your data without approval. See Your AI, over MCP.
Architectural space with translucent orange frame
Sikkerhed · BYOC by design

Eje din stack.
Sov roligt om natten.

Early access åbner i ugentlige hold, tidligste tilmeldinger først. Tilmeld dig nu, og dit workspace klargøres på din egen Cloudflare-konto, i den region, du vælger — med hver væg på denne side allerede på plads.

Cloudflare-login · kerne-workspace gratis