nessie

Byggt i EU, och där dina data finns

Var Nessie byggs, var dina data finns och vad du styr när du driftar det själv.

Vem som bygger den, och enligt vilken lag

Nessie byggs av UnlikeOtherAI s.r.o., ett bolag registrerat i Tjeckien som verkar enligt tjeckisk rätt.

Den här sidan beskriver hur programvaran är byggd och var den körs. Den är inte ett efterlevnadsintyg: Nessie har ingen säkerhetscertifiering, och inget här ska läsas som en sådan. Vilka personuppgifter som behandlas och på vilken grund står i integritetspolicyn, som är en separat sida.

Var den hostade produkten körs

Nessie Cloud körs hos europeiska hostingleverantörer – Scaleway, Hetzner och andra. Vi väljer den bästa tjänsten hos varje leverantör, så olika delar av produkten kan köras hos olika leverantörer, alla i Europa.

Något mer exakt än så – en viss plats, stad eller datacenter – anges medvetet inte här, eftersom uppgiften skulle bli inaktuell utan att någon märker det.

Med egen drift bestämmer du själv

Var en självhostad instans körs är en driftsättningsinställning, inte en produktinställning. Vägen för en enda maskin är en Docker Compose-stack som du placerar på en maskin du väljer. I Terraform-trädet för ett hanterat moln är regionen en indata utan något standardvärde alls: inget där kan gissas, så inget där har ett standardvärde, och databasen, objektlagringens bucket och tjänsterna följer alla den region du anger.

Två strukturella detaljer är viktiga för samma fråga. Kön och realtidstransporten är båda PostgreSQL – det finns ingen Redis och ingen meddelandemäklare i vägen, så det finns inget tredje system att placera. Och objektlagringen är S3-kompatibel i stället för knuten till en enda leverantör; referensdriftsättningen kör MinIO i en container i ett privat nätverk utan egen ingång utifrån. De delar som måste finnas någonstans är databasen, objektlagringen och de två Node-tjänsterna, och de finns alla där du placerar dem. Hur du sätter upp det beskrivs på installationssidan.

Vad Nessie lagrar – och vad den medvetet inte lagrar

Identiteter kopieras inte

Med inloggning via UnlikeOtherAI hanterar och lagrar identitetsleverantören människors identitet – autentiseringsfaktorer, profiler, medlemskap i organisationer och team samt inbjudningar. Nessie är en förlitande part, inte ett andra identitetssystem. Det är lika mycket ett databeslut som ett arkitekturbeslut: en identitet som Nessie aldrig lagrar är en som Nessie inte kan läcka, tappa bort eller missa att radera.

Det som tabellen users faktiskt innehåller är leverantörens stabila användar-id – nyckeln som allt annat slås upp via – e-postadressen, en icke-auktoritativ spegling av visningsnamn och avatar samt produktlokala fält (inställningar, pronomen, en tokenversion som används för att återkalla sessioner). Speglingen finns bara för att ett namn och en bild ska kunna visas utan en förfrågan per rad, och den synkas på nytt från leverantörens verifierade claims vid inloggning, vid teambyte och vid sessionsförnyelse. Inget värde tillverkas: en person som leverantören inte har angett något namn för visas med sin e-postadress tills ett namn finns. En lösenordshash finns bara för startägaren i en installation helt utan identitetsleverantör.

Detsamma gäller strukturen. En organisation hos leverantören är en Nessie-organisation, bunden via leverantörens organisations-id; ett team utan uppströmslänk svarar 404 TEAM_NOT_LINKED i stället för att falla tillbaka på en lokal gissning, och en levande avläsning av medlemslistan går till identitetsleverantören och sparar ingenting.

Två speglingar är inte borta än, och det vore ohederligt att antyda något annat. Organisations- och teamens namn lagras fortfarande lokalt vid sidan av bindnings-id:n, och lokala medlemsrader auktoriserar fortfarande vanliga förfrågningar mellan synkroniseringarna. Att ta bort båda är pågående, öppet arbete i kodförvaret och inte något som redan är klart.

Inget kommersiellt

Betalningar hanteras av den centrala faktureringstjänsten. Nessie lagrar ingen kund, prenumeration, faktura, pris, kreditsaldo, påfyllningspolicy, betalningsmedgivande, kontoutdrag eller uppsägningsstatus hos betalningsleverantören och beräknar inga tariffer. Den läser färdiga visningsvärden och visar dem.

Hemligheter

Ett konfigurerat valv krävs för att över huvud taget kunna lagra en hemlighet. Det finns medvetet ingen reserv i databasen och ingen väg i klartext: utan valv ger sparande, rotation och återkallelse av en hemlighet ett fel i stället för att försämras till något mindre säkert. Nessies egna poster för en hemlighet innehåller inget värde, ingen chiffertext, ingen nyckel och ingen valvtoken – bara en ogenomskinlig referens och dess metadata – och valvsökvägar byggs enbart av strukturella identifierare, aldrig av namnet på en organisation, ett team, ett projekt eller en person.

Autentiseringsuppgifter som Nessie själv måste lagra för att agera som OAuth-klient – anslutnings- och brevlådeuppgifter, webhook-hemligheter, material för sessionsförnyelse, executor-nyttolaster – förseglas i ändamålsbundna AES-256-GCM-kuvert under en versionshanterad nyckelring som är en separat rot från sessionens signeringshemlighet, med ett dokumenterat rotationsförfarande.

Det finns också en regel om modeller: en hemlighet får vara känd som existerande och får vara auktoriserad för användning, men hemligt material får inte hamna i modellens kontext, prompter, verktygsargument, verktygsresultat, minne, embeddings, sökning, loggar eller meddelanden. En agent kan få behörighet att använda en hemlighet. Den kan aldrig få behörighet att avslöja en.

Om de underliggande diskarna är krypterade är en egenskap hos den maskin en driftsättning körs på. Kodförvaret fastställer inte kryptering på volymnivå för databasens och objektlagringens volymer, så den här sidan påstår det inte.

Isolering mellan organisationer

Nessie är multi-tenant till sin konstruktion: en databas där varje rad tillhör exakt en organisation och varje underordnad tabell har en kolumn organization_id. Isoleringen upprätthålls på två ställen – avgränsningsvillkoret som varje fråga bär, och riktiga främmande nycklar på den kolumnen, som lades till i fyrtiotvå villkor efter att en intern granskning visat att kolumnen fanns men saknade begränsning i dussintals tabeller.

En överensstämmelsesvit håller den invarianten på plats vid HTTP-gränsen. Den skapar en maximalt privilegierad angripare – en fullständig ägare av sin egen organisation – och kontrollerar att varje kanonisk läsning av en annan organisations resurser svarar 403, 404 eller tomt, och att varje kanonisk ändring avvisas utan att den andra organisationens rad rörs. Den täcker kanaler, godkännanden, granskningsloggen, triggers, agenter och deras bindningar, körningar, projekt, uppgifter, trådar, anslutningar, arbetsflödesinstallationer, MCP-instanser, kunskapsbasen och aviseringar.

För att vara exakt om mekanismen: detta är tillämpningsnivåns kontroll plus främmande nycklar, inte radnivåsäkerhet (row-level security) i PostgreSQL. Det finns ingen RLS-policy och inget skydd på databassidan, och överensstämmelsesviten körs mot ett troget minneslager i stället för en levande databas, så den bevisar de avgränsningsvillkor som koden skriver, inte den SQL som en server kör. Kodförvaret säger så i svitens egen dokumentation, och det gör den här sidan också.

Granskningsloggen

Varje betydelsefull åtgärd registreras: vem som agerade och som vad – en person, en agent, en tjänst – vad de gjorde, med vilken resurs, i vilken organisation, vilket projekt, team eller kanal, om det lyckades eller nekades, varför, samt det förfrågnings-id, den adress och den user agent som det kom med.

Loggen är append-only till sin konstruktion och det går inte att skriva till den utifrån: POST /api/audit-log finns inte, och det är avsiktligt. Posterna är kedjade – varje post bär en SHA-256-digest av sina egna kanoniska fält plus digesten av den föregående posten för den organisationen – så en ändrad eller borttagen rad bryter kedjan och kan upptäckas. En organisationsägare eller administratör kan gå igenom kedjan när som helst och får veta var den först bröts, om den bröts.

Två ärliga förbehåll. Kedjan gör loggen manipulationsupptäckande, inte immun mot manipulation: ingen återkallad skrivbehörighet på databasnivå och ingen skrivskyddad lagring ligger bakom den, så garantin är upptäckt snarare än förebyggande. Och poster sparas som standard utan tidsgräns – konfigurerbar lagringstid med export före radering är planerad, inte byggd. Poster får dessutom inte innehålla hemligheter eller fullständiga förfrågningskroppar, och en fast uppsättning känsliga metadatafältnamn maskas vid inskrivning.

Kostnadsboken

Varje modellanrop registreras mot organisationen, och mot den användare, det team, det projekt, den kanal, den agent och den körning det kom från, med de tokens det förbrukade och både leverantörens rapporterade kostnad och Nessies egen uppskattning sida vid sida. Ett mått som en leverantör inte rapporterar lagras som null i stället för att gissas. Rapporterna kan läsas av en organisationsägare eller administratör.

Den här boken är driftstelemetri – vad en organisation har spenderat och för vems räkning. Det är ingen faktura och ingen faktureringsauktoritet.

Tredje parter när du använder den hostade produkten

En hostad driftsättning talar med en liten, fast uppsättning tjänster. Modelltrafik och webbsökning går inte direkt till leverantörerna: båda lämnar systemet genom en gateway som drivs av UnlikeOtherAI, och det är där de underliggande modell- och söktjänsterna finns. Inloggning och fakturering går till UnlikeOtherAI:s autentiserare. Hemlighetsvalvet är självhostat vid sidan av applikationen. Videosamtalslänkar som skapas av servern använder som standard den publika Jitsi-tjänsten.

Nästan allt annat är avstängt tills en operatör konfigurerar det, och säger det rakt ut i stället för att tyst misslyckas: anslutna Google-, Microsoft- och Slack-konton; agent-e-post via Amazon SES, som en driftsättning kör i sitt eget konto utan mellanhand; push för mobil och webbläsare; anslutningar till forskningskällor och tavelkällor; molnwebbläsare. Två detaljer är värda att nämna eftersom de ändrar vart data går:

  • Anslutna brevlådor stannar hos din leverantör. E-post läses direkt från din leverantör, över IMAP och SMTP eller leverantörens egen inloggning; Nessie lagrar den förseglade autentiseringsuppgiften och inget annat om kontot. En brevlåda som du ansluter till Clients-inkorgen är undantaget: du ber om att dess konversationer ska sparas hos varje kund, så de kopieras in.
  • Röstsamtal i appen går inte via Nessie. API:et förmedlar en autentiseringsuppgift och klienten öppnar själv ljudanslutningen. Dikteringen och telefonsamtalen är annorlunda: deras ljud går via Nessie till de tal- och modelleverantörer som bearbetar det.

En inferensdetalj följer samma princip: signerade anroparidentitetshuvuden skickas bara till den konfigurerade chattvärden, så att peka embeddings mot en annan slutpunkt lämnar aldrig över ett delegeringspåstående till den slutpunkten om den person vars text bäddas in.

Den hostade produkten använder flera inferensleverantörer och väljer mellan dem utifrån kostnad och kvalitet. En organisation kommer att kunna välja i Admin vilka leverantörer dess agenter får använda: bara västerländska, bara europeiska, bara kinesiska eller ingen preferens – den mest effektiva leverantören för varje jobb. En självhostad instans väljer själv.

Kör du den själv ändras allt detta

Varje tredje part ovan är ett konfigurationsval i en självhostad instans. Inferens kan riktas mot vilken OpenAI-kompatibel slutpunkt som helst, även en på din egen hårdvara. Anslutningarna är avstängda om du inte slår på dem. Inloggning via UnlikeOtherAI är den stödda vägen, och en driftsättning helt utan identitetsleverantör körs som en enda obunden organisation med en startägare.

Det är hela poängen med upplägget: programvaran är densamma, och besluten om var den körs och vad den får nå ligger hos den som kör den. Installationssidan beskriver hur.