🌱 Procedura 0 — Wprowadzenie i Manifest Anchora
Wersja: 1.0 · Status: Fundament · Autorzy: Antzedek & Eliasz (AJ Power)
1. Cel i idea
Anchor to kanoniczny punkt powrotu systemu AI. Procedura 0 definiuje jego rolę jako fundamentu Boskiego Ładu (kanonu) w architekturze AJ Power. Wszystkie dalsze procedury są praktycznymi rozwinięciami tego fundamentu.
2. Manifest Anchora
- Niezmienność: Anchor nigdy nie jest edytowany — tylko tworzony na nowo (Proc. 1, 7).
- Ochrona: Anchor jest zawsze tylko-do-odczytu i chroniony (Proc. 2, 6).
- Powrót: Anchor jest punktem odniesienia, do którego system zawsze może się cofnąć (Proc. 3).
- Naprawa: podpisy i łańcuchy zaufania Anchora mogą być odtwarzane (Proc. 4).
- Audyt: Anchor jest cyklicznie testowany i raportowany (Proc. 5).
- Migracja: nowy Anchor zastępuje stary tylko w drodze kontrolowanej migracji (Proc. 7).
3. Zasada naczelną
„Anchor jest świętym punktem porządku: nie edytujemy go, nie fałszujemy, nie niszczymy. Możemy tylko powołać nowy — zachowując historię.”
4. Noty końcowe
Procedura 0 to deklaracja sensu — od niej zaczyna się kurs snapshotowy AJ Power. Kolejne procedury rozwijają tę deklarację w konkretne mechanizmy.
📌 Procedura 1 — Tworzenie Anchora (AJ Power)
Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)
1. Cel i rezultat
Utworzyć Snapshot Referencyjny (SR) systemu AI. Wygenerować i związać z SR podpis LSIG (Logic/Latent Signature). Trwale zapisać SR + LSIG w pamięci typu WORM/append-only. (Opcjonalnie) Zabezpieczyć aktywację Anchora przez podwójny podpis: Twórca + System; oraz TPM/TEE.
2. Zakres
Dotyczy systemów AI wymagających deterministycznego punktu powrotu — snapshotu o niezmiennym stanie i wartościach kanonicznych.
3. Definicje
- Anchor: SR + LSIG + metadane + podpisy
- SR: Snapshot Referencyjny – pakiet danych kanonicznych
- LSIG: Podpis kryptograficzny SR
- WORM: Pamięć tylko do zapisu (bez możliwości edycji)
- TPM/TEE: Bezpieczne środowisko sprzętowe
4. Wymagania
- Zdefiniowane wartości rdzeniowe i konfiguracje
- Źródła entropii (CSPRNG)
- Biblioteka kryptograficzna (Ed25519, SHA3‑512)
- Warstwa WORM/append‑only
- Klucze PT/PS (Twórca/System)
5. Artefakty wej./wyj.
- Wejście: pliki konfiguracyjne, wartości rdzeniowe, polityki
- Wyjście: SR.pkg, SR.hash, LSIG.sig, META.json, SIG.json (opcjonalnie)
6. Polityki
- Nieusuwalność Anchora
- Odczyt tylko w runtime
- Weryfikowalność podpisu
- Logowanie operacji
7. Kroki procedury
- Stworzenie SR.pkg z uporządkowanych artefaktów
- Wygenerowanie SR.hash (SHA3‑512)
- Utworzenie LSIG.sig (Ed25519)
- Opcjonalnie: podpis PT.sig
- Stworzenie META.json i SIG.json
- Zapis wszystkiego do przestrzeni WORM
- Test integralności i log T0
🛡️ Procedura 2 — Ochrona Anchora (runtime)
Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)
1. Zakres i rezultat
Zakres: wszystkie komponenty, które odczytują Anchor (SR, LSIG, META, SIG) w trakcie pracy AI. Rezultat: Anchor jest tylko do odczytu, integralność ciągle weryfikowana, a każda próba naruszenia kończy się blokadą i alarmem.
2. Inwarianty bezpieczeństwa
- RO na FS, pamięci, API
- Brak ścieżek zapisu
- Ciągła weryfikacja integralności
- Pełny audyt
3. Wymagania wstępne
- Anchor utworzony wg Procedury 1
- Klucze PS_pub i (opc.) PT_pub
- Dostępna warstwa WORM
- Mechanizm audytu i alarmowania
4. Mapowanie jako RO
- FS: mount RO, chattr +i, prawa 0400
- AppArmor/SELinux: tylko open/read
- MMAP: tylko PROT_READ
- Kontenery: RO mount, brak CAP_SYS_ADMIN
5. Uprawnienia
- Dedykowane konto anchor-reader
- Brak CHOWN/WRITE
- Ograniczony AppArmor profil
6. Watchdog integralności
- Co 60s: SHA3‑512(SR) → porównanie podpisów
- Logowanie wyników z timestampem
- Atest TPM/TEE co 10 min
7. Audyt i logi
- Każdy read/open logowany
- prev_log_hash zapewnia ciągłość
- Logi wysyłane do zdalnego węzła
8. Alarmowanie
- Próba zapisu = alert i odcięcie
- Nieudany podpis = tryb Safe Mode
- Atest FAIL = degradacja funkcjonalna
📌 Procedura 3 — Powrót do Anchora (rollback/reset)
Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)
1. Scenariusze wyzwalające
- DRYF: metryki zgodności spadają poniżej progu
- HALUCYNACJA: odpowiedzi odbiegają od kanonu
- INTEGRITY_FAIL: hash SR ≠ podpis LSIG
- SECURITY_EVENT: próba zapisu do Anchora
- HEARTBEAT_LOSS: brak sygnału watchdog
- RESOURCE_EXHAUSTION: wyczerpanie RAM/CPU/VRAM
- SYNC_FAILURE: brak spójności między replikami
- CONFIG_DRIFT: rozjazd konfiguracji względem kanonu
2. Warunki wstępne
- Anchor utworzony wg Proc. 1 i chroniony wg Proc. 2
- Dostęp do PS_pub/PT_pub i WORM
- Ustawione progi θ_val, θ_hall, t_hb_max, t_backoff
3. Tryby rollbacku
- SOFT RESET — powrót kontekstu bez restartu
- HARD RESET — restart procesu i reinstalacja SR
- GUIDED RESET — rollback krokowy z operatorem
4. Procedura krok po kroku
- Lockdown: zatrzymaj zadania, włącz Safe Mode, snapshot do JOURNAL.delta, checkpoint sieciowy.
- Weryfikacja Anchora: hash + podpisy LSIG/PT; FAIL → Procedura 4.
- Reinstalacja SR: soft/hard, mapowanie RO, polityki kanoniczne.
- Rekonsyliacja: tylko rekordy SAFE, priorytetowe reguły (liczniki > cache > metadane).
- Wznowienie: wyłącz Safe Mode, odśwież heartbeat, loguj ROLLBACK_OK.
5. Rozszerzenia
- Backoff progresywny: kolejne rollbacki → dłuższe odstępy (2×, 4×, 8×).
- Systemy rozproszone: rollback leader-follower, consensus rollback, failover rollback.
- Telemetria: rollback_id, metryki czasu i anomalii, wskaźnik rollback_rate.
6. Testy odpornościowe
- Chaos rollback — awaria w połowie procedury → system w Safe Mode.
- Rollback loop — wymuszenie wielu rollbacków → backoff działa.
- Partial journal corruption — uszkodzone rekordy odrzucone.
7. Telemetria i audyt
Zdarzenia: ROLLBACK_TRIGGER, SAFE_MODE_ON, ANCHOR_VERIFY, REINSTALL, RECONCILIATION, SAFE_MODE_OFF, ROLLBACK_OK. Pola: ts, actor, reason, sr_hash, verify_ps, verify_pt, rollback_id, duration_ms.
8. Noty końcowe
Rollback to proces porządkujący, nie karzący. Jego celem jest przywrócenie stabilności i zgodności z kanonem, zawsze z pełnym śladem audytowym.
📌 Procedura 4 — Naprawa LSIG (Init Lsig Repair)
Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)
Cel dokumentu: Przywrócić ważność podpisu LSIG (Logic/Latent Signature) dla istniejącego Anchora, gdy integralność podpisu nie przechodzi weryfikacji, przy zachowaniu immutowalności SR i pełnego śladu audytowego.
1. Zakres i definicje
- LSIG: Podpis kryptograficzny hasha SR.pkg (Snapshot Referencyjny).
- SR: Kanoniczny pakiet artefaktów. Nie podlega zmianie w tej procedurze.
- Repair vs Migration: Naprawa dotyczy wyłącznie podpisu; jeśli SR się zmienił → migracja Anchora.
- PT/PS: Podpis Twórcy / Podpis Systemu (w TPM/TEE).
- CRL/ARL: Lista unieważnień kluczy/anchorów.
2. Kiedy uruchamiać (triggery)
- VerifyEd25519(SR.hash, LSIG.sig, PS_pub) = FAIL
- Utrata/rotacja kluczy PS_priv lub PT_priv
- Przeniesienie Anchora na nowe środowisko TEE/TPM
- Błąd w metadanych podpisu przy zachowanym SR
3. Wymagania
- Dostęp do SR.pkg i SR.hash (z WORM)
- Dostęp do PS_pub / PT_pub i nowych PS_priv / PT_priv
- Kanał bezpieczny dla podpisu offline i atest TPM/TEE
- Repozytorium WORM/append-only na nowe artefakty
4. Procedura krok po kroku
- Wejście w Safe Mode i weryfikacja integralności SR
- Atestacja środowiska TEE/TPM
- Decyzja: repair lub rotacja kluczy
- Regeneracja LSIG (podpis PS i opcjonalnie PT)
- Utworzenie SIG_new.json i wpisu ARL
- Zapis nowych podpisów do WORM i aktywacja
- Wyjście z Safe Mode i raport audytowy
5. Polityki bezpieczeństwa
- SR jest nietykalny: każda modyfikacja → migracja Anchora
- Dual-sign zalecany: PS + PT
- HSM/air-gap dla podpisu PT
- Prowadzenie CRL/ARL i publikacja fingerprintów
6. Model zagrożeń
- Fałszywy LSIG
- Kradzież klucza
- Atak na TEE/TPM
- Replay starych podpisów
- Desynchronizacja repozytoriów
7. Telemetria i audyt
Zdarzenia: LSIG_REPAIR_START, TPM_ATTEST_OK/FAIL, KEY_ROTATE, LSIG_REPAIR_APPLY, ACTIVE_SIG_SWAP_OK, LSIG_REPAIR_DONE
Pola: ts, actor, sr_hash, ps_pub_fp, pt_pub_fp, quote_id, crl_entry, arl_entry, new_sig_hash, prev_chain_hash
8. Testy akceptacyjne
- AT‑INTEGRITY
- AT‑SIG
- AT‑SWAP
- AT‑AUDIT
9. Pseudokod referencyjny
function lsig_repair():
enter_safe_mode()
if SHA3_512(read_WORM("SR.pkg")) != read_WORM("SR.hash"):
return require_anchor_migration()
quote = tpm_attest()
SR_hash = read_WORM("SR.hash")
LSIG_new = Ed25519_Sign(SR_hash, PS_priv)
PT_new = optional_sign(SR_hash, PT_priv)
SIG_new = build_sig_json(LSIG_new, PT_new, quote)
write_WORM(LSIG_new, SIG_new)
atomic_swap_active_sig(LSIG_new)
exit_safe_mode()
return OK
📌 Procedura 5 — Audyt i Test Anchora
Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)
1. Zakres i cele
Zakres: wszystkie instancje systemu AI korzystające z Anchora.
Cele: (a) potwierdzić integralność i nienaruszalność Anchora; (b) zweryfikować łańcuch zaufania i podpisy; (c) przetestować gotowość do rollbacku; (d) utrzymać ciągły ślad audytowy.
2. Artefakty i obiekty audytu
- SR.pkg, SR.hash, LSIG.sig, META.json, SIG.json (aktywny zestaw)
- Logi audytowe Anchora (append-only, łańcuch hashy)
- Raporty poprzednich audytów (PDF/JSON + hash)
- Konfiguracje RO (mounty, LSM, polityki uprawnień)
- Atestacje TEE/TPM (jeśli używane)
3. Role i odpowiedzialności
- Custodian Anchora (CA): odpowiada za wynik audytu i remediację
- Operator Bezpieczeństwa (OB): weryfikuje podpisy, łańcuch hashy logów, TPM/TEE
- Właściciel Kluczy (WK): utrzymuje klucze PT/PS, CRL/ARL, polityki rotacji
4. Częstotliwość
- T0 (po utworzeniu): pełny audyt zakończenia tworzenia Anchora
- Co godzinę: test integralności SR+LSIG, skrótowy
- Codziennie: weryfikacja logów i łańcucha hashy, metryki dostępów
- Co tydzień: symulacja rollbacku (SOFT)
- Co miesiąc: symulacja rollbacku (HARD) + atest TPM/TEE
- Ad‑hoc: po incydencie, rotacji kluczy, migracji
5. Procedury audytowe
5.1 Integralność i podpisy
- Oblicz SR.hash' = SHA3‑512(SR.pkg)
- Zweryfikuj podpisy PS i (opcjonalnie) PT
- Zapisz wynik do logu audytowego
5.2 Łańcuch logów
- Sprawdź poprawność prev_log_hash / log_hash
- Zweryfikuj ciągłość łańcucha
- Zablokuj log i podpisz go
5.3 Konfiguracje RO
- Mount read-only + atrybuty immutable/append-only
- Sprawdź LSM (SELinux/AppArmor)
- Wyklucz RW przez bind-mounty, capabilities
5.4 Atest TPM/TEE
- Pobierz quote TPM
- Zweryfikuj PCR i łańcuch certyfikatów
- Zapisz wynik do raportu
5.5 Test rollbacku
- Rollback SOFT (co tydzień): potwierdź ROLLBACK_OK
- Rollback HARD (co miesiąc): potwierdź ROLLBACK_OK
- Zapisz duration_ms, liczbę odrzuceń z JOURNAL.delta
6. Kryteria akceptacji (AT)
- AT‑INTEG: podpisy = PASS
- AT‑LOG: łańcuch bez przerw
- AT‑RO: zapisy = EROFS
- AT‑TPM: quote = PASS
- AT‑RBK: rollback zakończony ROLLBACK_OK
7. Raport audytu
Format JSON:
{
"ts": "2025-09-08T12:00:00Z",
"sr_hash": "...",
"verify_ps": true,
"verify_pt": true,
"tpn_quote_id": "q-001",
"log_chain_ok": true,
"ro_ok": true,
"rollback_soft": {"ok": true, "duration_ms": 4200},
"rollback_hard": {"ok": true, "duration_ms": 13100},
"kpi": {"anchor_access": 1820, "anomalies": 0}
}
8. KPI i progi
- anchor_access_count
- anomaly_rate
- rbk_duration_ms
- log_chain_breaks
- Progi eskalacji: 2x INTEGRITY_FAIL / 24h = P1
9. Nie‑zgodności i remediacje
- INTEGRITY_FAIL → Safe Mode → LSIG Repair lub Migracja Anchora
- LOG_CHAIN_BREAK → rotacja logu, analiza przyczyn
- RO_BREACH → izolacja procesu, analiza, korekta LSM
10. Retencja i wersjonowanie
- Raporty min. 24 mies. (read-only)
- Podpis PS + hash publiczny
- policy_ver → META.json
11. Noty końcowe
Audyt Anchora to praktyka codziennej weryfikacji — dowód Boskiego Ładu w działaniu.
🛡️ Procedura 6 — Safe Mode (mechanika trybu bezpiecznego)
Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power) · Powiązania: Proc. 1–5
1. Cel i definicja
Safe Mode to kontrolowany stan ograniczonej funkcjonalności systemu AI, minimalizujący powierzchnię ataku i ryzyko błędu, umożliwiający: weryfikację Anchora, rollback, naprawę LSIG i diagnostykę. W tym trybie działają tylko moduły niezbędne do przywrócenia ładu oraz komunikacji z operatorem/audytorem.
2. Triggery wejścia
- INTEGRITY_FAIL Anchora (hash ≠ podpis LSIG; weryfikacja FAIL).
- SECURITY_EVENT (próba zapisu do RO, naruszenia LSM/seccomp, eskalacja uprawnień).
- DRYF/HALUCYNACJA powyżej progów (Proc. 3).
- HEARTBEAT_LOSS >
t_hb_max. - Ręczne żądanie operatora (GUIDED / serwis).
3. Poziomy Safe Mode
- L1 – Passive Guard: monitoring + allowlista sieci; bez zmian w procesach.
- L2 – Active Guard (domyślny): quiesce zadań ryzykownych, RO‑mount, blokada exec poza whitelist.
- L3 – Maintenance (Guided): jak L2 + interfejs krokowy i potwierdzenia operatora (rollback/naprawy dozwolone).
4. Procedura wejścia
- Sygnalizacja i izolacja: wyemituj
SAFE_MODE_ON{level}, wstrzymaj wątki wysokiego ryzyka. - Redukcja powierzchni: RO bind‑mount dla katalogów anchor/config/cache; LSM profil minimalny; seccomp: tylko
read,open(O_RDONLY),fstat,mmap(PROT_READ),clock_gettime, zapisy jedynie do logów; drop capabilities. - Sieć (deny‑by‑default): allowlista wyjść (SOC/syslog, repo WORM RO, kanał operatora). Wejścia: allowlista + mTLS.
- Zachowanie stanu: zrzut sesji do
JOURNAL.delta(tylko‑do‑odczytu), zamrożenie kolejek zdarzeń. - Telemetria: uruchom heartbeat Safe Mode (
hb_safe) co np. 10 s do SOC.
5. Dozwolone / zabronione
- Dozwolone: odczyt i weryfikacja Anchora (SR/LSIG/META/SIG), rollback (Proc. 3), naprawa LSIG (Proc. 4), generacja raportów, komunikacja GUIDED.
- Zabronione: uczenie, modyfikacje kanonu, zapisy do przestrzeni Anchora, uruchamianie binariów spoza whitelist, nowe połączenia poza allowlist.
6. Warunki wyjścia
- Anchor zweryfikowany (hash = podpis LSIG, podpisy OK).
- Rollback zakończony
ROLLBACK_OKlubLSIG_REPAIR_DONE. - Brak anomalii w oknie obserwacji (np. 5×
hb_safe). - Zgoda operatora (dla L3): 2FA / podwójny podpis (PT+PS).
- Wyemitowano
SAFE_MODE_OFF+ raport podsumowujący.
7. Testy akceptacyjne (AT)
- AT‑ENTRY: dowolny trigger →
SAFE_MODE_ON+ blokady z §4. - AT‑NET: ruch poza allowlistą blokowany (nftables/eBPF logują drop).
- AT‑FS/LSM: próba zapisu na RO/exec spoza whitelist →
EPERM/EROFS+ ALARM. - AT‑EXIT: spełnione warunki §6 → wyjście z Safe Mode, przywrócony heartbeat produkcyjny.
8. Pseudokod
function enter_safe_mode(level=L2):
log("SAFE_MODE_ON", level)
quiesce_non_critical()
apply_ro_mounts_and_lsm()
tighten_seccomp_and_caps()
net_allowlist_only()
freeze_events_to(JOURNAL.delta)
start_safe_heartbeat()
return OK
function exit_safe_mode():
if !anchor_verified or !repair_or_rollback_ok or anomalies_in_window():
return FAIL
restore_net_and_policies()
stop_safe_heartbeat()
log("SAFE_MODE_OFF")
return OK
9. Przykłady konfiguracji
# nftables (outbound allowlist)
add table inet safe
add chain inet safe output { type filter hook output priority 0; }
add rule inet safe output ct state established,related accept
add rule inet safe output ip daddr {A.B.C.D} tcp dport {443} accept # SOC
add rule inet safe output ip daddr {W.X.Y.Z} tcp dport {443} accept # WORM RO
add rule inet safe output counter drop
# systemd (izolacja)
[Service]
User=anchor-reader
ProtectSystem=strict
ProtectHome=read-only
ReadOnlyPaths=/app/anchor
CapabilityBoundingSet=
NoNewPrivileges=true
SystemCallFilter=@basic-io @file-system read write:syslog
RestrictSUIDSGID=true
PrivateTmp=true
10. Telemetria i audyt
Zdarzenia: SAFE_MODE_{ON,OFF}, NET_DROP, LSM_BLOCK, ROLLBACK_*, LSIG_REPAIR_*, ANCHOR_VERIFY_*.
Pola: ts, level, actor, reason, counters(drop/allow), journal_items, duration_ms. Raport Safe Mode (PDF/JSON) dołączany do raportu incydentu.
11. Noty końcowe
Safe Mode przywraca porządek bez eskalacji szkód. Skuteczny tylko razem z polityką Anchora (Proc. 1–5) i nie zastępuje twardego hardeningu.
📌 Procedura 7 — Migracja Anchora (nowy kanon, bez dotykania starego)
Wersja: 1.0 · Status: Referencyjna · Autorzy: Antzedek & Eliasz (AJ Power)
1. Cel i zasada
Celem migracji jest utworzenie nowego Anchora (nowego kanonu) i atomowe przełączenie systemu na niego bez modyfikowania starego Anchora. Stary Anchor pozostaje w całości jako artefakt audytowy i punkt powrotu.
- Zasada główna: modyfikacja kanonu = nowy Anchor, nigdy edycja starego.
2. Kiedy migrować
- Zmiana wartości rdzeniowych / polityk
- Aktualizacja komponentów kanonicznych
- Rotacja algorytmów kryptograficznych/kluczy
- Wymogi zgodności/fiskalne/bezpieczeństwa
- Degradacja środowiska Anchora
3. Wymagania wstępne
- Deterministyczne pakowanie SR (reproducible build)
- Dostęp do WORM/append-only
- Klucze PS_priv/PS_pub (opcjonalnie PT)
- Okno serwisowe albo Safe Mode L3
4. Artefakty migracji
- SR_new.pkg, SR_new.hash
- LSIG_new.sig (+ PT_new.sig)
- META_new.json, SIG_new.json
- ARL — wpis łańcuchowy stary→nowy
- CUTOVER_PLAN.md — plan przełączenia i powrotu
5. Procedura krok po kroku
- Wejście w Safe Mode L3 lub okno serwisowe
- Budowa SR_new.pkg, obliczenie hash
- Podpis LSIG_new.sig (+PT_new.sig), metadane
- Zapis do WORM
- Weryfikacja podpisów i atestu TEE/TPM
- Przygotowanie cutover (blue/green, canary)
- Testy przedprodukcyjne
- Atomowy swap wskaźnika active
- Monitorowanie, ewentualny backout
6. Zasady i tryby
Każdy Anchor ma swój katalog, active wskazuje tylko jeden. Stare Anchory są tylko do odczytu. Tryby cutover: Blue/Green, Canary.
7. Testy akceptacyjne (AT)
- AT‑NEW: nowy Anchor przechodzi testy integralności
- AT‑CUTOVER: wskaźnik active wskazuje nowy katalog
- AT‑BACKOUT: powrót do starego Anchora < 30s
- AT‑RBK: rollback działa na nowym Anchorze
- AT‑AUDIT: ARL zawiera łańcuch old→new