Bezpieczeństwo i prywatność¶

Model zagrożeń¶

System zakłada, że modele, providerzy, treść internetu, załączniki, kanały, pluginy i obserwacje UI mogą być błędne lub złośliwe. Zaufanie koncentruje się w małym Control Plane, Repository Guard, Approval Center i zweryfikowanych adapterach. Nawet komponent zaufany działa z najmniejszym zakresem.

Główne zagrożenia:

prompt injection z dokumentu, strony, e-maila, głosu lub obrazu;
model halucynujący approval, ścieżkę, rezultat albo tożsamość;
złośliwy/skompromitowany plugin i supply chain;
kradzież sesji UI, CSRF, replay lub fałszywy Approval Center;
path traversal, junction/reparse, zapis do main lub credential roots;
SSRF, DNS rebinding, redirect do sieci prywatnej, wyciek danych;
podwójne wykonanie przez race, crash i retry;
poisoning pamięci i cross-project retrieval;
przejęty worker lub urządzenie zdalne;
fizyczna awaria zasilania, dysku, sieci lub chłodzenia;
błąd operatora albo nadmierne uprawnienia stałe.

Karta modułu Security & Policy¶

Pole	Kontrakt
Odpowiedzialności	hard denies, policy evaluation, capability, classification, trust boundaries, incident controls.
Wejścia	actor, tool/version, payload, project, data, paths, account, destination, effect, policy snapshot.
Wyjścia	allow/deny/require approval, resolved scope, risk, disclosure, audit event.
Zależności	Registries, identity, Approval Broker, Repository Guard, network/path resolvers, Audit.
Uprawnienia	policy jest broker-owned; tylko governance principal może proponować/aktywować wersję.
Autonomia	może automatycznie odmówić, zawiesić lub obniżyć autonomię; nie może automatycznie poszerzyć praw.
Walidacja	positive/negative/adversarial, concurrency, restart, independent review i invariant coverage.
Awaria	fail closed; read-only/recovery; brak trybu „bez policy”.

Granice zaufania¶

flowchart LR
    U["Człowiek"] -->|"uwierzytelniona decyzja"| AC["Approval Center"]
    M["Modele / providerzy<br/>niezaufani"] -->|"propozycje"| B["Control Plane"]
    W["Web / kanały<br/>wrogie dane"] --> B
    AC --> B
    B -->|"grant"| R["Tool Runner"]
    R -->|"typed call"| T["Scoped adapter"]
    T --> X["System / aplikacja / urządzenie"]
    B --> A["Audit"]
    R --> A

UI może uruchomić/focusować Approval Center, ale JavaScript nie przechowuje sekretu decyzji. Worker otrzymuje lease i grant jednego invocation, nie dane operatora. Provider nie łączy się z bazą ani Runnerem. Loopback jest siecią, nie dowodem tożsamości człowieka.

Ochrona danych¶

Dane mają klasy: public, internal, confidential, restricted, z rozszerzeniami branżowymi. Polityka określa przechowywanie, dozwolonych consumerów, redakcję, providerów, retencję i eksport. Minimalizacja zachodzi przed wywołaniem modelu, nie po. Telemetria nie zapisuje promptów i pełnych payloadów domyślnie; używa hashy, metadanych i klasyfikowanych artefaktów.

Project isolation obowiązuje w pamięci, artefaktach, indeksach, cache i UI. Wyszukiwanie semantyczne filtruje scope przed rankingiem. Backup zachowuje klasyfikację i szyfrowanie. Usunięcie ma retention/legal hold i tombstone; nie jest swobodną komendą modelu.

Sieć¶

Adapter deklaruje scheme, host/domain allowlist, port, redirect policy i klasy danych. Resolver blokuje loopback, link-local, prywatne zakresy oraz niejawne przejście przez DNS, chyba że narzędzie jest jawnie przeznaczone do konkretnego lokalnego endpointu. Każdy redirect jest ponownie sprawdzany. file://, arbitralny proxy i dynamiczny URL z treści są odrzucane.

Segmentacja oddziela Control Plane, workers, storage, kamery/IoT, użytkowników i management. Worker IPC nie jest publicznie eksponowany. Zdalny dostęp używa uwierzytelnionej overlay VPN i zasad urządzeń, ale sam VPN nie nadaje roli aplikacyjnej.

Ścieżki i kod¶

Ścieżka jest realnie rozwiązywana po uwzględnieniu symlinków, junctions, case i platformy. Write tools działają wyłącznie w attested candidate roots. Main, Git metadata, runtime storage, credentials i zabronione lokalizacje są hard deny. Narzędzie nie przyjmuje arbitrary executable argv. Build korzysta z zatwierdzonego wheelhouse/package mirror i podpisanych manifestów.

Approval i separation of duties¶

Provider proponuje; Planner organizuje; Policy liczy; człowiek decyduje; Broker wydaje grant; Worker wykonuje; validator ocenia; promotion principal zmienia stan aktywny. Nie jedna tożsamość. Approval i execution są oddzielne; execution i promotion także. Draft ≠ send, approved ≠ published, candidate ≠ promotion, trigger ≠ capability.

Przykładowe polecenia¶

„Pokaż dokładnie, jakie dane miałyby opuścić urządzenie przy tej konsultacji.”
„Zawieś plugin po naruszeniu deklarowanych efektów i unieważnij oczekujące grants.”
„Przetestuj politykę przeciw path traversal i replay bez dotykania chronionych lokalizacji.”
„Przełącz instalację w read-only do czasu wyjaśnienia niespójności audytu.”

Walidacja¶

Każdy invariant ma test pozytywny i negatywny. Approval/grant/lease wymagają testów wieloprocesowych oraz restart. Path policy testuje reprezentacje ucieczki w bezpiecznym sandboxie. Provider tests zawierają hostile output i fake approval fields. Testy nie dotykają realnych sekretów ani chronionych urządzeń. Niezależny review potwierdza brak agentowego raw shell i nieautoryzowanych main write paths.

Incydent i scenariusz awaryjny¶

Po wykryciu incydentu system: zatrzymuje dotknięte leases, revoke grants/sessions, izoluje wersję agenta/tool/workera, utrwala volatile evidence, przechodzi read-only, klasyfikuje zakres danych i skutków, inicjuje recovery oraz wymaga decyzji o wznowieniu. Automatyczne działania mogą tylko zawężać prawa. Nie usuwa logów ani nie rotuje dowodów bez retention hold. Jeżeli Approval Center lub policy state są niepewne, wszystkie nowe skutki są blokowane.