BEZPIECZEŃSTWO

Profil bezpieczeństwa, prosto z mostu.

BuildOnAI jest zbudowany dla organizacji, w których suwerenność danych jest wymogiem regulacyjnym, nie preferencją — kancelarii prawnych, badań medycznych, laboratoriów klinicznych, sektora publicznego, finansów. Profil bezpieczeństwa jest uformowany pod ten warunek: nic nie wychodzi z hosta domyślnie, obrona strukturalna jest wymuszana w CI, każde repozytorium ma własny model zagrożeń.

Dlaczego to ma znaczenie dla branż regulowanych

Ramy regulacyjne mają znaczenie, bo odwracają pytanie o bezpieczeństwo. Domyślne założenie większości nowoczesnego tooling AI brzmi: "dane wychodzą z hosta, chmura trzyma je bezpiecznie, log audytowy wystarczy". Dla organizacji objętych GDPR art. 32, HIPAA §164.312, tajemnicą adwokacką, ISO 27001 z klauzulami data-residency albo krajowymi ramami cyberbezpieczeństwa, to założenie jest odwrócone: dane nie mogą wyjść z hosta, a ciężar dowodu spoczywa na operatorze.

BuildOnAI startuje z odwróconego założenia:

  • Self-hosted z założenia. Każda usługa działa na sprzęcie kontrolowanym przez operatora. Zero połączeń do chmury, zero telemetrii, zero vendor lock-in. Opcjonalny fallback do hostowanego LLM jest opt-in przez klucz API — bez niego ekosystem zostaje całkowicie offline.
  • Document Processor zostaje lokalnie. Aplikacja desktopowa Tauri w Rust + Svelte. Parsowanie PDF / DOCX / TXT dzieje się na systemie plików hosta. Embeddingi generuje Ollama na hoście. ChromaDB trzyma je na lokalnym dysku. Oryginał dokumentu nigdy nie przekracza granicy sieci.
  • Auth ed25519 między agentami. Gdy organizacja potrzebuje więcej niż jednego agenta lub jednego hosta, każde żądanie jest podpisywane. Klucze publiczne to zwykłe pliki w key-server; rewokacja to rm. Bez zewnętrznego dostawcy tożsamości.
  • Trail audytowy z konstrukcji. Każdy uprzywilejowany endpoint zapisuje strukturalną linię JSONL. Tail-and-alert wystarczy na start; osobne SIEM nie jest wymagane.

Cztery warstwy strukturalne

"Bezpieczeństwo strukturalne" oznacza, że ochrona jest częścią architektury, a nie procesu, który operator musi przestrzegać. Cztery warstwy, każda w innym repozytorium, każda z własnym SECURITY.md:

1. Cortex Policy Engine

Policy Engine w Cortex odmawia niebezpiecznych wywołań niezależnie od tego, kto i jak zlecił. Skompromitowany prompt może poprosić model o usunięcie plików; policy odmawia. Trzy reguły domyślnie (deny dla destruktywnego shella, ask dla zapisów do FS poza projektem, allow dla komend read-only). Reguły własne idą do policy.json w roocie projektu. Engine to strukturalna obrona przed prompt injection — żadna sprytna inputka nie obejdzie kroku human-confirmation, gdy policy mówi ask.

2. Podpisane żądania ed25519

Key Server + trzymodowe pokrętło AUTH_MODE (off → observe → enforce) zamienia każde wywołanie HTTP między agentami w podpisaną transakcję. Replayy blokuje krótko żyjący cache nonce'ów; dryf zegara powyżej ~60 s jest odrzucany. Klucze publiczne to zwykłe pliki; rewokacja to rm. Ścieżka migracji jest stopniowa — patrz Bezpieczne wdrożenie.

3. Izolacja Document Processora

Document Processor działa jako aplikacja Tauri — rdzeń Rust, UI Svelte, brak osadzonego sandboxa przeglądarki, z którego można uciec. Dostęp do plików jest ograniczony do katalogów wybranych przez usera przez allow-list Tauri; nie istnieje zdalny endpoint, do którego atakujący mógłby się dostać. Sparsowany dokument opuszcza Document Processor tylko, gdy operator skonfiguruje jawny pipeline, jak ten w Pipeline dokumentów.

4. Niezmienniki wymuszane w CI

Każde repozytorium ma pipeline w .github/workflows/ z niezmiennikami bezpieczeństwa — Python AST checks na wzorce shell-injection, capability-based fallback sentinele, whitelistę known-public endpointów, podpisane fixture'y do testów migracji. Wyłączenie niezmienników CI unieważnia gwarancje licencji komercyjnej; jest to zapisane w licencji jako klauzula kontraktowa, nie umowa dżentelmeńska.

Co chronimy, czego nie chronimy

Każde repozytorium ma SECURITY.md z dokładnym modelem zagrożeń tego komponentu. Wspólna struktura:

W zakresie

  • Niezaufany prompt próbujący skłonić model do destruktywnego działania (Policy Engine odmawia niezależnie od źródła).
  • Nieautoryzowany peer w sieci wywołujący chronione endpointy pod AUTH_MODE=enforce (żądanie odrzucone; weryfikacja ed25519 nie przechodzi).
  • Atak replay na podpisane endpointy (cache nonce'ów + okno timestampu).
  • Skompromitowany host agenta wycofywany w trakcie incydentu (rm klucza publicznego na key-server; rewokacja natychmiastowa).

Poza zakresem

  • Zdeterminowany atakujący z dowolnym dostępem sieciowym do portów hosta pod AUTH_MODE=off (domyślne dla wdrożeń solo / zaufany LAN). Jeśli Twoje środowisko nie pasuje do tych założeń, przełącz na enforce.
  • Złośliwy kod w pluginie Cortexa wrzuconym do plugins/. Pluginy są dziś trusted-by-design; izolacja przez subinterpretery PEP 684 jest na roadmapie (Cortex v1.2). Do tego momentu traktuj plugins/ jak dowolny katalog z wykonywalnym kodem na hoście.
  • Ataki na sam system operacyjny hosta. BuildOnAI to usługa userland; w warstwach, których nie kontroluje, polega na izolacji procesów, kontenerów i uprawnień FS hosta.

Zgłaszanie podatności

Jeśli znalazłaś / znalazłeś problem bezpieczeństwa, napisz na [email protected] z tematem [SECURITY]. Wstępne potwierdzenie w ciągu trzech dni roboczych. Wolimy naprawić coś po cichu i podziękować w release notes niż dowiedzieć się o problemie najpierw z social mediów.

Proszę nie zakładaj publicznych issues GitHub na zgłoszenia bezpieczeństwa. Plik SECURITY.md w każdym repozytorium opisuje per-component ścieżkę zgłaszania i nasze zobowiązania reakcji.

Modele zagrożeń per repozytorium

Każde repozytorium ma własny SECURITY.md z autorytatywnym modelem zagrożeń tego komponentu (po angielsku):