nessie

Vyrobeno v EU a kde jsou vaše data

Kde se Nessie vyvíjí, kde jsou uložena vaše data a co řídíte, když ji hostujete sami.

Kdo Nessie staví a podle jakého práva

Nessie staví společnost UnlikeOtherAI s.r.o., která je registrována v České republice a řídí se českým právem.

Tato stránka popisuje, jak je software postavený a kde běží. Není to prohlášení o souladu s předpisy: Nessie nemá žádný bezpečnostní certifikát a nic z tohoto textu se tak nesmí číst. Jaké osobní údaje se zpracovávají a na jakém základě, popisují zásady ochrany osobních údajů, které jsou samostatnou stránkou.

Kde běží hostovaný produkt

Nessie Cloud běží u evropských hostingových poskytovatelů — Scaleway, Hetzner a dalších. Od každého poskytovatele vybíráme nejlepší službu, kterou nabízí, takže různé části produktu mohou běžet u různých poskytovatelů, všichni v Evropě.

Cokoli přesnějšího — konkrétní lokalitu, město nebo datové centrum — tu záměrně neuvádíme, protože by zastarávalo, aniž by si toho někdo všiml.

Při vlastním hostingu rozhodujete vy

To, kde běží vlastní instance, je nastavení nasazení, ne nastavení produktu. Cesta s jedním strojem je sestava Docker Compose, kterou umístíte na stroj podle svého výběru. Ve stromu Terraformu pro spravovaný cloud je region vstupní hodnota úplně bez výchozí hodnoty: nic tam nelze odhadnout, a proto tam nic výchozí není. Databáze, úložiště objektů i služby se řídí regionem, který zadáte.

Pro stejnou otázku jsou důležité dva strukturální detaily. Fronta i přenos v reálném čase běží na PostgreSQL — v cestě není žádný Redis ani message broker, takže není žádný třetí systém, který byste museli někam umístit. A úložiště objektů je kompatibilní s S3 a není vázané na jednoho dodavatele; referenční nasazení spouští MinIO v kontejneru na privátní síti bez vlastního vstupu zvenčí. Části, které musejí někde být, jsou databáze, úložiště objektů a dvě služby v Node, a všechny jsou tam, kam je umístíte vy. Jak to postavit, najdete na stránce instalace.

Co Nessie drží — a co záměrně ne

Identita se nekopíruje

Při přihlášení přes UnlikeOtherAI identitu lidí spravuje a ukládá poskytovatel identity — autentizační faktory, profily, členství v organizacích a týmech i pozvánky. Nessie je závislá strana, ne druhý systém identit. Je to stejně tak rozhodnutí o datech jako o architektuře: identitu, kterou Nessie nikdy neukládá, nemůže uniknout, ztratit ani zapomenout smazat.

Tabulka users ve skutečnosti uchovává stabilní identifikátor uživatele od poskytovatele — klíč, přes který se řeší vše ostatní —, e-mailovou adresu, neautoritativní kopii zobrazovaného jména a avatara a pole místní pro produkt (předvolby, oslovení, verzi tokenu sloužící k odvolání relací). Kopie existuje jen proto, aby se jméno a obrázek daly vykreslit bez dotazu na každý řádek, a znovu se synchronizuje z ověřených údajů poskytovatele při přihlášení, při přepnutí týmu a při obnovení relace. Žádnou hodnotu si nikdo nevymýšlí: člověk, kterého poskytovatel nepojmenoval, má do té doby místo jména svou e-mailovou adresu. Hash hesla existuje jen u zakládajícího vlastníka instalace, která nemá žádného poskytovatele identity.

Totéž platí pro strukturu. Jedna organizace poskytovatele je jedna organizace v Nessie, svázaná identifikátorem organizace u poskytovatele; tým bez vazby na poskytovatele odpoví 404 TEAM_NOT_LINKED a nespadne na místní odhad, a živé čtení seznamu členů jde k poskytovateli identity a nic neukládá.

Dvě kopie ještě neodpadly a bylo by nepoctivé naznačovat opak. Názvy organizací a týmů se stále ukládají lokálně vedle identifikátorů vazby a lokální řádky členství stále mezi synchronizacemi opravňují běžné požadavky. Odstranění obou je evidovaná, otevřená práce v repozitáři, ne něco, co už je hotové.

Nic obchodního

Platby spravuje centrální fakturační služba. Nessie neukládá zákazníka u platebního poskytovatele, předplatné, fakturu, cenu, zůstatek kreditu, pravidlo dobíjení, platební souhlas, výpis ani stav zrušení a nepočítá tarify. Čte hodnoty připravené k zobrazení a zobrazuje je.

Tajemství

K uložení jakéhokoli tajemství je nutný nakonfigurovaný trezor. Záměrně neexistuje žádná záloha v databázi ani cesta v otevřeném textu: bez trezoru uložení, rotace i odvolání tajemství vrátí chybu, místo aby se změnily na něco méně bezpečného. Vlastní záznamy Nessie o tajemství neobsahují hodnotu, šifrový text, klíč ani token trezoru — jen neprůhledný odkaz a jeho metadata — a cesty v trezoru se skládají pouze ze strukturálních identifikátorů, nikdy ne z názvu organizace, týmu, projektu ani jména osoby.

Přihlašovací údaje, které musí Nessie držet sama, aby mohla jednat jako klient OAuth — údaje konektorů a schránek, tajemství webhooků, materiál pro obnovu relací, data executorů —, jsou zapečetěny v účelově vázaných obálkách AES-256-GCM pod verzovanou sadou klíčů, která je odděleným kořenem od klíče pro podepisování relací, se zdokumentovaným postupem rotace.

Existuje i pravidlo týkající se modelů: o tajemství lze vědět, že existuje, a lze povolit jeho použití, ale jeho obsah se nesmí dostat do kontextu modelu, promptů, argumentů nástrojů, výsledků nástrojů, paměti, embeddingů, vyhledávání, logů ani zpráv. Agentovi lze udělit schopnost tajemství použít. Schopnost je prozradit mu udělit nelze nikdy.

Zda jsou disky pod tím zašifrované, je vlastnost stroje, na kterém nasazení běží. Repozitář nezaručuje šifrování na úrovni svazků pro databázi a úložiště objektů, takže to tato stránka netvrdí.

Izolace tenantů

Nessie je od základu víceklientská: jedna databáze, ve které každý řádek patří přesně jedné organizaci a každá podřízená tabulka nese sloupec organization_id. Izolace se vynucuje na dvou místech — v klauzuli rozsahu, kterou nese každý dotaz, a ve skutečných cizích klíčích na tomto sloupci, které přibyly jako čtyřicet dva omezení poté, co interní audit zjistil, že sloupec je na desítkách tabulek přítomný, ale bez omezení.

Sada testů souladu drží tuto zásadu na hranici HTTP. Nasadí maximálně oprávněného útočníka — plného vlastníka vlastní organizace — a ověřuje, že každé kanonické čtení zdrojů jiné organizace odpoví 403, 404 nebo prázdným výsledkem a každá kanonická změna je odmítnuta, přičemž řádek jiné organizace zůstane nedotčen. Pokrývá kanály, schvalování, auditní záznam, spouštěče, agenty a jejich vazby, běhy, projekty, úkoly, vlákna, připojení, instalace workflow, instance MCP, znalostní bázi a upozornění.

K přesnosti ohledně mechanismu: jde o vynucování na úrovni aplikace plus cizí klíče, ne o zabezpečení na úrovni řádků v PostgreSQL (row-level security). Neexistuje žádná politika RLS ani záchranná síť na straně databáze a sada testů souladu běží proti věrné paměťové databázi, ne proti živé, takže dokazuje klauzule rozsahu, které kód zapisuje, nikoli SQL, které server provede. Repozitář to uvádí v dokumentaci samotné sady a stejně tak to uvádí tato stránka.

Auditní stopa

Zaznamenává se každá významná akce: kdo jednal a v jaké roli — osoba, agent, služba —, co udělal, s jakým zdrojem, v jaké organizaci, projektu, týmu nebo kanálu, zda to uspělo, nebo bylo zamítnuto, proč, a s jakým ID požadavku, adresou a user agentem to přišlo.

Záznam je od základu pouze pro přidávání a zvenčí do něj nelze nic zapsat: POST /api/audit-log neexistuje a je to záměr. Položky jsou zřetězené — každá nese otisk SHA-256 svých kanonických polí plus otisk předchozí položky téže organizace —, takže upravený nebo odstraněný řádek řetězec přeruší a dá se zjistit. Vlastník nebo správce organizace může řetězec kdykoli projít a pokud se přerušil, dozví se, kde poprvé.

Dvě poctivé výhrady. Řetězec činí záznam odhalitelným při pozměnění, ne imunním vůči pozměňování: za ním není odebrání práv k zápisu na úrovni databáze ani úložiště s jednorázovým zápisem, takže záruka je odhalení, ne prevence. A položky se ve výchozím nastavení uchovávají neomezeně dlouho — konfigurovatelné uchovávání s exportem před smazáním je navržené, ale není postavené. Položky také nesmějí obsahovat tajemství ani celá těla požadavků a pevně daná sada názvů citlivých polí metadat se při zápisu maskuje.

Účetní kniha nákladů

Každé vyvolání modelu se zaznamenává k organizaci a k uživateli, týmu, projektu, kanálu, agentovi a běhu, ze kterého pochází, s počtem spotřebovaných tokenů a s cenou hlášenou poskytovatelem i vlastním odhadem Nessie vedle sebe. Metrika, kterou poskytovatel nehlásí, se uloží jako null, nikoli jako odhad. Přehledy může číst vlastník nebo správce organizace.

Tato kniha je provozní telemetrie — co organizace utratila a kým. Není to faktura ani fakturační autorita.

Třetí strany, když používáte hostovaný produkt

Hostované nasazení komunikuje s malou, pevně danou sadou služeb. Provoz modelů a webové vyhledávání nejdou přímo k poskytovatelům: oba odcházejí přes jednu bránu, kterou provozuje UnlikeOtherAI a za kterou stojí poskytovatelé modelů a vyhledávání. Přihlášení a fakturace jdou na autentizační službu UnlikeOtherAI. Trezor tajemství je provozován samostatně vedle aplikace. Odkazy na videohovory vytvářené serverem ve výchozím stavu míří na veřejnou službu Jitsi.

Téměř vše ostatní je vypnuté, dokud to provozovatel nenakonfiguruje, a říká to, místo aby tiše selhalo: připojené účty Google, Microsoft a Slack; e-mail agentů přes Amazon SES, který nasazení provozuje ve vlastním účtu bez prostředníka; mobilní a prohlížečové push oznámení; konektory výzkumu a zdrojů nástěnek; cloudové prohlížeče. Dva detaily stojí za zmínku, protože mění, kam data míří:

  • Připojené schránky zůstávají u vašeho poskytovatele. Pošta se čte živě od vašeho poskytovatele, přes IMAP a SMTP nebo přes jeho vlastní přihlášení; Nessie ukládá zapečetěné přihlašovací údaje a nic jiného o účtu. Výjimkou je schránka, kterou připojíte do schránky Klientů: žádáte, aby se její konverzace uchovávaly u jednotlivých zákazníků, takže se kopírují dovnitř.
  • Hlasové hovory v aplikaci přes Nessie neprocházejí. API zprostředkuje přihlašovací údaje a klient si zvukové spojení otevře sám. Diktování a telefonní hovory jsou jiné: jejich zvuk jde přes Nessie k poskytovatelům řeči a modelů, kteří ho zpracovávají.

Jeden detail inference se řídí stejnou zásadou: podepsané hlavičky s identitou volajícího se posílají jen nakonfigurovanému chatovému hostiteli, takže nasměrování embeddingů na jiný koncový bod nikdy tomuto koncovému bodu nepředá tvrzení o delegaci týkající se osoby, jejíž text se embeduje.

Hostovaný produkt používá několik poskytovatelů inference a vybírá mezi nimi podle ceny a kvality. Organizace bude moci v administraci zvolit, které poskytovatele smějí její agenti používat: jen západní, jen evropské, jen čínské, nebo bez preference — nejefektivnější poskytovatel pro každou úlohu. Vlastní instance si poskytovatele vybírá sama.

Když ji provozujete sami, vše výše se mění

Každá třetí strana uvedená výše je u vlastní instance věcí konfigurace. Inferenci lze nasměrovat na libovolný koncový bod kompatibilní s OpenAI, včetně toho na vašem vlastním hardwaru. Konektory jsou vypnuté, dokud je nezapnete. Přihlášení přes UnlikeOtherAI je podporovaná cesta a nasazení bez jakéhokoli poskytovatele identity běží jako jediná nepropojená organizace se zakládajícím vlastníkem.

V tom je smysl celého uspořádání: software je stejný a rozhodnutí, kde běží a k čemu se smí dostat, patří tomu, kdo ho provozuje. Jak na to, popisuje stránka instalace.