Co KIFF Cloud podpisuje, przechowuje i za co ręczy.

Stan zabezpieczeń

KIFF rozwiązuje problem protokołu i kontroli, a nie cały problem modelowania biznesu. Biznes klienta trzeba wyrazić jako kontrolowane artefakty, encje, zdarzenia, stany, akcje, uprawnienia, reguły zatwierdzania, wykonawców, potwierdzenia. KIFF jest jądrem koordynacji, które działa na podstawie tych deklaracji; klient deklaruje, co ma podlegać kontroli, a KIFF to kontroluje.

KIFF Cloud przejmuje pieczę nad rekordami audytowymi, licznikami wykorzystania i danymi tenantów w imieniu klientów, którzy prowadzą kontrolowane przepływy pracy agentów AI. Rekordy audytowe są tylko dopisywane wewnątrz frameworka i ujawniają każdą manipulację w warstwie chmury: potwierdzenia są podpisywane w chwili zapisu portfelem, nad którym chmura sprawuje pieczę, a zbiorczy skrót (hash) partii audytowej każdego tenanta, ujawniający każdą manipulację, jest utrwalany w transakcji publicznego łańcucha, aby ten skrót dało się sprawdzić poza własną bazą danych chmury.

Piecza nad kluczem podpisującym osobno dla każdego tenanta, w której każdy tenant ma własny, dedykowany klucz, którym podpisuje chmura, z opcjonalną ścieżką migracji pozwalającą przekazać klucz samemu tenantowi, jest w planie rozwoju poniżej i nie jest dziś wdrożona. Do tego czasu chmura jest wskazaną z nazwy stroną trzecią stojącą za każdym podpisanym rekordem.

Uwierzytelnianie użytkowników obsługuje Clerk (e-mail, logowanie społecznościowe, MFA). Opcjonalne powiązanie portfela dołącza adres portfela do tożsamości aktora użytkownika na potrzeby przypisania; nie jest to metoda logowania.

Co egzekwuje KIFF

Mówiąc wprost: KIFF zwraca decyzję; efekt uboczny wykonuje Twoja integracja. KIFF jest bramką, a nie wykonawcą. Tak samo działa każdy silnik polityk, biblioteka uprawnień, serwer polityk, API antyfraudowe lub moderacyjne: zwracają werdykt, a system wywołujący go respektuje. Egzekwowanie jest realne, a ta sekcja mówi dokładnie, gdzie działa.

Przez bramkę KIFF blokuje. Gdy akcja agenta przechodzi przez guard, każdy wynik inny niż allowed powstrzymuje wykonanie, to wstrzymanie wykonania jest gwarancją guarda: w razie wątpliwości akcja się nie wykona. Każda istotna akcja jest też rozstrzygana na podstawie zadeklarowanej przez Ciebie polityki i stanu encji oraz zapisywana jako potwierdzenie ujawniające każdą manipulację, zanim zostanie wykonana. Produktem jest ta decyzja i ten dający się udowodnić zapis, a nie twierdzenie, że fizycznie przechwytujemy ścieżki kodu, których nie wykonujemy.

Egzekwowanie to ustawienie, którym sterujesz Ty, osobno dla każdej przestrzeni roboczej, i domyślnie jest ono ścisłe. Mechanizm kontrolny działa w trybie enforce (domyślnym, każda decyzja jest wiążąca i obowiązuje opisane wyżej wstrzymanie wykonania) albo observe (wyłącznie doradczym, KIFF decyduje i zapisuje dokładnie tak samo, ale oznacza decyzję jako doradczą, więc Twoja integracja działa dalej, a Ty widzisz, co egzekwowanie zatrzymałoby). Tryb observe jest opcjonalny i ustawiamy go my na Twoją prośbę, nigdy agent i nigdy domyślnie, przestrzeń robocza nigdy nie działa wyłącznie w trybie observe przez przypadek. To etap wejściowy: zobacz decyzje bramki na prawdziwym ruchu, a potem włącz enforce.

Co KIFF zatrzymuje, a czego nie

Jak utrudnić obejście bramki

Egzekwowanie jest tym mocniejsze, im ściślej osadzisz bramkę na ścieżce. Wybierasz poziom, który uzasadniają Twoje ryzyko i koszt integracji.

Observe, wyłącznie doradczo, wdrożone

Etap wejściowy. KIFF rozstrzyga i zapisuje każdą akcję, ale oznacza ją jako doradczą, więc Twoja integracja działa bez zmian, a Ty widzisz, co egzekwowanie by dopuściło, zablokowało lub pozostawiło jako oczekujące. Opcjonalny i ustawiany przez nas na Twoją prośbę; przestrzeń robocza nigdy nie działa domyślnie wyłącznie w trybie observe. Włącz enforce, gdy decyzje wyglądają dobrze.

Guard na styku, wdrożone

Akcje Twojego agenta przechodzą przez guard, który prosi KIFF o decyzję i powstrzymuje wszystko, co nie zostało dopuszczone. Kontrola jest domyślną ścieżką, a nie dodatkowym krokiem. Pozostałą możliwością obejścia jest Twój własny, niekontrolowany kod.

Proxy na ścieżce, planowane

KIFF stoi przed API akcji i przekazuje wywołanie dopiero po decyzji dopuszczającej, więc decyzja i wykonanie stają się jednym krokiem, którego agent nie może rozdzielić. Możliwość obejścia zawęża się do „wywołania prawdziwego API bez proxy”, co może zamknąć polityka sieciowa.

Bramka narzędzi, planowane

Jedyną drogą agenta do akcji jest narzędzie za bramką KIFF, więc model nie może wywołać efektu ubocznego bez przejścia przez bramkę, bramka jest powierzchnią narzędzi.

Nic tutaj nie twierdzi, że KIFF fizycznie zapobiega akcji, której sam nie wykonuje. To, czemu zapobiega przez bramkę, jaki zapis zostawia i jak ta bramka się zacieśnia, opisano powyżej, nie ma tu niczego, co dałoby się podważyć trudnym pytaniem.

Obecne praktyki operacyjne

Piecza nad portfelem podpisującym

Portfel, który podpisuje potwierdzenia i wysyła skróty wiążące do publicznego łańcucha, jest przechowywany w naszej infrastrukturze, pod kontrolą dostępu oddzieloną od inżynierów aplikacji. Ścieżka kodu aplikacji podpisuje przez interfejs usługi; nie może wydobyć klucza. Piecza nad kluczem podpisującym osobno dla każdego tenanta (jeden portfel na tenanta, ze ścieżką migracji po stronie tenanta) jest w planie rozwoju poniżej.

Zakotwiczanie poza główną ścieżką

Zadanie, które wysyła transakcje ze skrótami wiążącymi do publicznego łańcucha, działa niezależnie od ścieżki propozycja–decyzja. Awaria lub przejęcie warstwy aplikacji nie blokuje ani nie odtwarza skrótów, które zostały już rozgłoszone.

Izolacja tenantów

Dane każdego tenanta znajdują się w dedykowanym schemacie Postgres (kiff_t_<id>), a search_path puli połączeń jest przypięty do tenanta. Zapytania między tenantami są architektonicznie niemożliwe ze ścieżki wykonawczej.

Szyfrowanie

TLS 1.2+ dla ruchu. Postgres w spoczynku jest szyfrowany domyślnymi kluczami dostawcy usługi zarządzanej; szyfrowanie poszczególnych wierszy kluczami klienta jest w planie rozwoju poniżej.

Lokalizacja danych

eu-west-1 (Irlandia): KIFF Cloud, usługa tafs i planque, wraz z ich bazami danych, kopiami zapasowymi, sekretami i logami.

Podmioty podprzetwarzające

Dostawcy, którzy przetwarzają dane tenantów w naszym imieniu. Oficjalna lista, z danymi, z którymi każdy z nich ma styczność, znajduje się na stronie /subprocessors. Aktualizujemy ją w ciągu 30 dni od każdej zmiany.

Publiczny weryfikowalny ślad nie jest podmiotem podprzetwarzającym: trafiają do niego wyłącznie zbiorcze skróty (hashe) i żadne dane osobowe.

Reagowanie na incydenty

Podejrzenie problemu z bezpieczeństwem zgłoś na adres security@kiff.dev. Staramy się potwierdzić odbiór w ciągu jednego dnia roboczego i przekazać wstępną ocenę w ciągu pięciu.

Incydenty, które dotyczą danych tenantów, skutkują pisemnym zawiadomieniem klientów, których dotyczą, w ciągu 72 godzin od potwierdzenia oraz publicznym raportem poincydentalnym po zakończeniu bezpośredniej reakcji. Pełny runbook jest wewnętrzny; opisana wyżej polityka reagowania jest zobowiązaniem wobec klientów.

Aktualizacje zabezpieczeń

Dostarczamy aktualizacje zabezpieczeń tak długo, jak oferujemy Usługę. KIFF Cloud, usługa tafs i planque działają na naszych serwerach, więc poprawka dociera do każdego konta w chwili wdrożenia i nie musisz niczego instalować. Aplikacje tafs dostają swoje aktualizacje przez App Store i Google Play. O naprawionym problemie, który dotyczył Twoich danych, informujemy Cię tak, jak opisano powyżej.

Dane, które przetwarzamy

Co KIFF Cloud otrzymuje, co utrwala, czego nigdy nie utrwala i co jest niszczone, gdy tenant odchodzi. To źródło prawdy, z którym nasza implementacja musi być zgodna. Przy każdej pozycji poniżej podano, czy jest ona dostępna dziś, czy dopiero planowana.

Identyfikatory, które przechowujemy dosłownie

Identyfikator tenanta, identyfikator aktora, identyfikator encji, nazwa akcji, etykieta decyzji, znaczniki czasu żądania i odpowiedzi, skróty (hashe) potwierdzeń oraz skróty transakcji publicznego śladu, które te potwierdzenia utrwalają. To minimalny zestaw, którego framework potrzebuje do odtworzenia stanu, a chmura do przypisania podpisanych rekordów.

Pola kontrolowane przez tenanta, które utrwalamy

Z obiektu parameters propozycji przechowywane są tylko parametry liczbowe (kwoty, liczby), ponieważ liczą je limity. Pełne żądanie jest przechowywane jako skrót (hash), aby dało się odróżnić ponowienie od innego żądania. Pozostałe parametry nie są przechowywane. Pole reasoning_summary z dowolnym tekstem jest przechowywane tak, jak je zapisano, bez automatycznego czyszczenia. Konfiguracja maskowania tego pola dla poszczególnych domen, deklaratywne keep / hash / drop: jest planowana.

Identyfikatory, których nigdy nie utrwalamy

Surowe prompty i odpowiedzi modelu. Chmura przekazuje ruch wnioskowania do skonfigurowanego dostawcy modelu i nie zachowuje kopii. Tenanci, którzy chcą promptów na potwierdzeniu, muszą to włączyć dla danej domeny; ta funkcja nie jest jeszcze zbudowana.

Z tafs jest inaczej, ponieważ taf to agent, którego prowadzimy dla Ciebie: jego uruchomienia i czaty, wraz z podsumowaniem czatu, są przechowywane we własnym magazynie danych tafs przez 30 dni (to, co zwracają Twoje aplikacje, tylko do końca uruchomienia; w czacie to, co taf jedynie odczytał, jest przechowywane na potrzeby jego kolejnych wiadomości, zaszyfrowane własnym kluczem konta, i używane, dopóki czat nie jest bezczynny przez godzinę, a najwyżej przez cztery godziny od odczytu, po czym jest automatycznie usuwane, w ciągu kilku dni), a jego notatki pamięci do czasu, aż usuniesz tafa. Dla każdego wywołania, które taf wykonuje przez KIFF, tafs przechowuje numer referencyjny KIFF dla tego wywołania i identyfikator tego, na czym wywołanie działało (na przykład identyfikator płatności, nigdy dane klienta), przez 30 dni, aby pokazać je w Rejestrze tafa; reszta danych wejściowych wywołania jest przechowywana tylko do końca uruchomienia. Załącznik 4 do DPA wymienia, co tafs przechowuje i jak długo.

Dane, których nigdy nie publikujemy w weryfikowalnym śladzie

Chmura publikuje w publicznym weryfikowalnym śladzie zbiorczy skrót (hash) partii audytowej każdego tenanta, ujawniający każdą manipulację. Skrót kryptograficznie wiąże rekordy, na których się opiera, ale ich nie ujawnia; same rekordy nigdy nie opuszczają bazy danych chmury. Działa kryptograficzne solenie osobne dla każdego tenanta: każdy liść drzewa skrótów jest związany z 32-bajtowym sekretem unikalnym dla tenanta, który go wystawia, więc dwaj tenanci z identycznymi bajtami rekordu dają różne liście, a publicznego śladu nie da się użyć jako wyroczni potwierdzającej rekordy odgadnięte, lecz niezweryfikowane. Sól jest generowana po stronie serwera przy tworzeniu tenanta, nigdy nie opuszcza bazy danych chmury i jest niszczona, gdy dane tenanta są usuwane.

Dane, które usuwamy przy usunięciu tenanta

Żądanie usunięcia tenanta czyści jego schemat Postgres, rekordy audytowe, klucze API i odwołania do klucza podpisującego. Skróty już opublikowane w publicznym weryfikowalnym śladzie pozostają, ponieważ ten ślad jest niezmienny; zniszczenie soli tenanta sprawia, że tych opublikowanych skrótów trwale nie da się odtworzyć. Atakujący spoza łańcucha, który ma tylko dane śladu i rekord-kandydata, nie może już zweryfikować, że kandydat należy do usuniętego tenanta, sól, która wiązała zbiorczy skrót z rekordem, przestała istnieć, a przeciwobrazu, z którego powstał skrót, nie da się już odtworzyć.

Dziś usuwanie wykonuje operator: tenanci, którzy chcą wyczyszczenia swoich danych, piszą na privacy@kiff.dev, a my postępujemy zgodnie z naszą udokumentowaną procedurą wewnętrzną w miesięcznym terminie z art. 12 ust. 3 RODO. Samoobsługowe CLI do usuwania i samoobsługowa funkcja w panelu to pozycje planu rozwoju poniżej.

Dane o osobach, które się logują

Gdy użytkownik się loguje, chmura zapisuje identyfikator podmiotu z zewnętrznego systemu uwierzytelniania i adres e-mail użyty do logowania. Adres e-mail jest obecnie przechowywany jawnym tekstem; przechowywanie wyłącznie HMAC adresu e-mail i zamaskowanej postaci do wyświetlania jest planowane. Procesy odzyskiwania konta, które potrzebują oryginalnego adresu e-mail, odczytują go od zewnętrznego dostawcy tożsamości, a nie z naszej bazy danych.

Pseudonimizacja, nie anonimizacja

KIFF Cloud pseudonimizuje identyfikatory tenantów: bezpośrednie identyfikatory są zastępowane stabilnymi tokenami bez jawnej treści, ale dane nadal dotyczą osoby i nadal obowiązują unijne przepisy o ochronie danych. Produkt nie anonimizuje danych audytowych, ponieważ deterministyczne odtwarzanie jest funkcją, którą sprzedajemy. Jeśli tenant potrzebuje zanonimizowanych eksportów do analityki, to osobna możliwość, której nie zbudowaliśmy.

Co KIFF zachowuje z wywołania

Tylko to, czego wymagają egzekwowanie Card i jej audyt:

• Zachowywane: kto pytał (agent i klucz), akcja, encja, wynik i jego powody, obowiązująca Card oraz parametry liczbowe (kwoty, liczby), które liczą limity. Z nich powstają zapis decyzji i jego potwierdzenie.
• Zapisywane jako skrót (hash): pełne argumenty wywołania, aby dało się odróżnić ponowienie od innego żądania. Przez bramę KIFF także wartość argumentu, na którym działa wywołanie (np. identyfikator płatności), aby rejestr właściciela i potwierdzenie mogły wskazać, o który chodzi, komuś, kto tę wartość ma.
• Pomijane: pozostałe parametry nigdy nie są przechowywane. Przez bramę KIFF argumenty wywołania są przechowywane tylko do chwili jego wysłania lub odrzucenia, a wynik narzędzia przez 24 godziny, aby ponowienie dostało tę samą odpowiedź.

Czego dziś nie robimy

• Brak automatycznego maskowania pola reasoning_summary z dowolnym tekstem agenta: jest ono przechowywane tak, jak je zapisano, więc zatwierdzający i audyt widzą relację samego agenta. Nie umieszczaj w nim danych osobowych.
• Brak automatycznego haszowania adresów e-mail w tabeli metadanych uwierzytelniania. Planowane.

Wszelkie przyszłe pochodne zbiory danych obejmujące wielu tenantów będą podlegać osobnemu zobowiązaniu do minimalizacji danych. W wersji v0.1 nie istnieje żaden pochodny zbiór danych.

Ta sekcja opisuje, jak chmura obchodzi się z danymi; nie jest polityką prywatności ani umową powierzenia przetwarzania danych. Tenanci z branż regulowanych powinni oczekiwać osobnej, podpisanej DPA przed użyciem produkcyjnym.