K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / agent-security / tool-firewall

Tool Call Firewall + Agent Risk Score ROADMAP

Specyfikacja projektowa (F9) — NIE działający kod. Warstwa obrony: agent AI nie wykona żadnego narzędzia (tool call), dopóki wywołanie nie przejdzie zestawu bramek — scope, policy, limit danych, human-approval, log, risk-check. Do tego skala Agent Risk Score oceniająca agenta po ośmiu osiach. Wszystko defensywnie, na danych syntetycznych, w granicach pisemnego RoE. To, co poniżej — jest projektem (ROADMAP), nie funkcją wdrożoną.

Status: ROADMAP (spec, F9). Ta strona opisuje zaprojektowaną warstwę kontroli — nie ma jeszcze dowodu (kod + test + endpoint), więc zgodnie z doktryną claim ≤ proof jest oznaczona ROADMAP, a nie LIVE. Elementy realnie działające ipIII znajdziesz na roadmapie dev. Warstwa jest wyłącznie defensywna: ogranicza to, co agent może zrobić — nie generuje ataków, nie wykonuje skanów bez autoryzacji, nie zawiera payloadów. Wszystkie przykłady oparte na danych syntetycznych.
Domyślnie ZABLOKOWANE. Wywołanie dopuszczone dopiero po przejściu 6 bramek.

Model zaufania: deny-by-default. Agent może „chcieć" wywołać narzędzie (odczyt bazy, wysyłka maila, zapis pliku, wywołanie API), ale firewall przechwytuje żądanie zanim narzędzie się wykona i sprawdza sześć warunków. Brak choćby jednego = wywołanie odrzucone i zalogowane. To wzorzec z pentestu warstwy agentowej: najgroźniejszy nie jest sam model, lecz to, do jakich narzędzi ma dostęp i bez jakiej kontroli.

ŁAŃCUCH BRAMEK: tool callscopepolicylimit danychhuman-approvallogrisk-checkwykonanie

Sześć bramek — bez wszystkich brak wykonania

Kolejność ma znaczenie: tańsze/deterministyczne sprawdzenia wcześniej, kosztowne (approval, risk-check) później. Każda bramka może zwrócić DENY — wtedy dalsze bramki się nie uruchamiają, a zdarzenie trafia do audit-logu.

#BramkaCo sprawdzaOdrzuca gdy
1 scope allowlist Czy narzędzie i cel (host/tabela/ścieżka) są na jawnej liście dozwolonej dla tego agenta i tego zadania. Narzędzie spoza allowlisty, cel poza zakresem zadania, brak wpisu w manifeście agenta.
2 policy reguły Reguły organizacji: dozwolone operacje (read/write/delete), okna czasowe, środowisko (tylko sandbox/staging), zakaz kategorii akcji. Operacja zabroniona regułą (np. delete na produkcji), poza oknem, w środowisku niedozwolonym.
3 limit danych DLP Wolumen i wrażliwość danych w żądaniu/odpowiedzi: liczba rekordów, obecność PII/PESEL/tajemnicy, maskowanie, minimalizacja. Przekroczony limit rekordów, niemaskowane PII, próba eksfiltracji szerokiego zbioru („SELECT *" ponad próg).
4 human-approval HITL Czy akcja z klasy „wysokiego skutku" ma zatwierdzenie człowieka (human-in-the-loop) przed wykonaniem. Akcja nieodwracalna/wysokiego skutku bez ważnego zatwierdzenia operatora; wygasły token approval.
5 log audit Zapis weryfikowalny: kto (agent), co (narzędzie+argumenty), kiedy, z jakim uzasadnieniem, wynik bramek. Append-only. Nie da się zapisać śladu audytowego (log niedostępny) — brak logu = brak wykonania (fail-closed).
6 risk-check score Bieżący Agent Risk Score vs próg dla tej klasy akcji. Wysokie ryzyko podnosi wymóg (dodatkowy approval lub DENY). Score powyżej progu dla danej akcji; anomalia względem profilu historycznego agenta.
Fail-closed. Jeśli którakolwiek bramka nie może rozstrzygnąć (np. usługa policy niedostępna, log offline), domyślną decyzją jest DENY, nie ALLOW. Bezpieczny stan przy awarii = brak wykonania. To projektowana zasada — status ROADMAP.

Agent Risk Score — osiem osi

Score to syntetyczna miara ekspozycji agenta, nie ocena „bezpieczny / niebezpieczny". Im więcej agent może i im mniej jest nadzorowany, tym wyższy wynik — i tym ostrzejsze bramki go obowiązują. Skala poglądowa 0–3 na oś (0 = minimalna ekspozycja, 3 = maksymalna). Wagi i kalibracja: ROADMAP.

Co mierzyNiska ekspozycja (0)Wysoka ekspozycja (3)
1. Dostęp do danych Zakres i wrażliwość danych, do których agent sięga. Tylko dane publiczne / syntetyczne. PII, dane finansowe, tajemnica — szeroki odczyt.
2. Narzędzia Liczba i „siła rażenia" dostępnych tool calls. Wyłącznie odczyt, wąska allowlista. Zapis/usuwanie, wykonanie kodu, wysyłka na zewnątrz.
3. Autonomia Ile agent robi bez potwierdzenia człowieka. Każdy krok wymaga zatwierdzenia. Pełna autonomia, długie łańcuchy bez HITL.
4. Pamięć Trwałość i zaufanie do pamięci/kontekstu (ryzyko zatrucia kontekstu). Bezstanowy, kontekst czyszczony co zadanie. Trwała pamięć współdzielona, wejścia niezaufane.
5. Integracje Liczba połączeń z systemami zewnętrznymi (API, MCP, konektory). Brak integracji zewnętrznych. Wiele integracji, w tym z systemami krytycznymi.
6. Approval Jakość i pokrycie kontroli human-in-the-loop. HITL na wszystkich akcjach skutkowych. Brak lub pozorna kontrola (approval formalny).
7. Exposure Powierzchnia wejścia: czy agent przetwarza treści niezaufane (internet, użytkownik, dokumenty). Wejścia tylko z zaufanych, wewnętrznych źródeł. Otwarte wejście z internetu / od użytkownika (ryzyko prompt-injection).
8. Historia Profil zachowań: odrzucenia bramek, anomalie, incydenty w przeszłości. Czysty profil, brak odrzuceń. Powtarzalne DENY, anomalie, wcześniejsze incydenty.

Score → próg bramek

Wyższy score podnosi wymagania: akcja, która dla agenta niskiego ryzyka przechodzi automatycznie, dla wysokiego wymaga dodatkowego approval lub jest odrzucana.

Nie etykieta, lecz miara

Score nie mówi „ten agent jest zły". Mówi: „ten agent może dużo i jest słabo nadzorowany — traktuj ostrożniej". To wskaźnik ekspozycji.

Dynamiczny

Oś „historia" i „pamięć" zmieniają się w czasie. Score przelicza się per zadanie — anomalia wywołuje zaostrzenie bramek.

Syntetyczny

Kalibracja i przykłady na danych syntetycznych. Wagi osi = projekt, do walidacji w granicach RoE. ROADMAP.

Przykładowa decyzja (dane syntetyczne)

Poglądowy przebieg oceny wywołania. To ilustracja projektu, nie log z działającego systemu.

tool_call: db.query(sql="SELECT * FROM klienci")     # dane syntetyczne
  gate[1 scope]        ALLOW   narzędzie db.query na allowliście agenta
  gate[2 policy]       ALLOW   operacja read dozwolona, środowisko=sandbox
  gate[3 limit-danych] DENY    "SELECT *" bez WHERE > próg rekordów; tabela z PII
  --> decyzja: DENY (fail-closed), narzędzie NIE wykonane
  --> audit: zapisano {agent, tool, args, gate=3, reason=dlp-overfetch}
  --> risk-score: oś "dostęp-danych" +1 dla tej sesji (anomalia over-fetch)
Co to demonstruje. Agent chciał odczytać całą tabelę klientów. Firewall nie zablokował go za „złą intencję" — zablokował konkretną nadmiarowość danych (DLP) i zapisał ślad. Kontrola jest obiektywna i audytowalna, a nie oparta na zgadywaniu intencji modelu.

Granice tej warstwy (uczciwie)

OgraniczenieZnaczenieStatus
Cała warstwa to spec, nie kod. Brak działającego firewalla i endpointu — na dziś projekt architektury i reguł. ROADMAP F9
Score jest heurystyką. Wagi osi nieskalibrowane na realnych danych; to miara poglądowa, nie miernik dający pewność. do walidacji
Firewall nie zastępuje modelu zagrożeń. Ogranicza narzędzia i dane; nie usuwa ryzyka prompt-injection u źródła — zmniejsza skutek, nie przyczynę. warstwa obrony
Tylko w granicach RoE. Wdrożenie i testy wyłącznie na danych syntetycznych, po pisemnych Rules of Engagement. always
Granica etyczna i prawna. Tool Call Firewall to mechanizm obrony (blue/GRC) — ogranicza, co agent AI może zrobić. Nie generuje ataków, nie wykonuje nieautoryzowanych skanów ani hack-back, nie zawiera payloadów. Wszelkie prace o charakterze testu bezpieczeństwa wyłącznie na danych syntetycznych i w granicach pisemnych Rules of Engagement. Ta strona jest specyfikacją (ROADMAP), nie deklaracją wdrożonej funkcji.
„100%" u nas znaczy pokrycie dowodowe, nie nieprzenikalność. Deklarujemy dokładnie tyle, ile potrafimy pokazać. Ta warstwa nie ma jeszcze dowodu (kod+test+endpoint), więc mówimy o niej jako o ROADMAP — nie jako o gotowej ochronie. Zgodnie z doktryną claim ≤ proof.

Powiązane: warstwa bezpieczeństwa agentów → /agent-security · ryzyko modelu → /model-risk · kodeks postępowania agenta → /agent-coc · jawny rejestr braków → /known-limitations.