BEZPIECZEŃSTWO

Profil bezpieczeństwa, prosto z mostu.

BuildOnAI dokumentuje granice bezpieczeństwa komponentów local-first: podpisane żądania między usługami, kontrolę polityk w Cortexie oraz modele zagrożeń per repozytorium. Operator odpowiada za decyzje wdrożeniowe i zgodność własnego środowiska.

Granice bezpieczeństwa local-first

Wykonywanie lokalne daje operatorowi kontrolę nad tym, gdzie działają usługi i znajdują się dane. Samo w sobie nie potwierdza zgodności prawnej ani regulacyjnej; trzeba ją ocenić dla konkretnego wdrożenia.

Udokumentowane granice techniczne:

  • Komponenty self-hosted. Usługi działają na sprzęcie operatora. Fallback Cortexa do hostowanego modelu wymaga jawnej konfiguracji.
  • Document Processor zostaje lokalnie. Aplikacja desktopowa Tauri w Rust + Svelte. Parsowanie PDF / DOCX / TXT dzieje się na systemie plików hosta. Wyszukiwanie to SQLite FTS5 połączone z embeddingami z lokalnej Ollamy, a indeks jest plikiem SQLite na lokalnym dysku. Gdy Ollama jest niedostępna, wyszukiwanie schodzi do samej warstwy leksykalnej, zamiast przestać działać. 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 na granicy podpisu. Key-server zapisuje strukturalną linię JSONL dla każdej weryfikacji, którą wykonuje. 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 Serverzamienia chronione wywołanie HTTP między agentami w podpisaną transakcję. Replaye blokuje krótko żyjący cache nonce'ów; dryf zegara powyżej ~60 s jest odrzucany. Klucze publiczne to zwykłe pliki; rewokacja torm.

3. Izolacja Document Processora

Document Processordział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 pozostaje w aplikacji, dopóki operator nie wyeksportuje go przez kontrolowany przez siebie workflow.

4. Niezmienniki wymuszane w CI

Każde repozytorium produktowe 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. Niezmienniki są częścią builda, więc zmiana, która któryś z nich łamie, nie trafia na main na zielono.

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 (żądanie jest 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. Weryfikacja podpisu chroni endpointy, a nie samą ekspozycję portów.
  • Złośliwy kod w pluginie Cortexa wrzuconym do plugins/. Pluginy są zaufanym kodem; traktuj ten katalog jak każdy inny 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 buildonai.tm@gmail.comz 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):