Niebezpieczne i nieautoryzowane wywołania narzędzi

Agent, który został zahackowany przez prompt injection, błędnie skonfigurowany lub po prostu obdarzony zbyt dużą swobodą, może wywoływać narzędzia, których nigdy nie miał dotykać — lub wywoływać legalne narzędzie z niebezpiecznymi argumentami: shell.exec z rm -rf /, payment API z nadmierną kwotą przelewu, narzędzie bazy danych celujące w replikę produkcyjną. To jest nadużycie narzędzi agenta i jest to jedno z najbardziej konsekwentnych ryzyk w systemach agentów, ponieważ wywołania narzędzi mają rzeczywiste skutki uboczne, które są często nieodwracalne. Agent Firewall ma trzy warstwowe obrony. Możesz je wdrażać niezależnie lub w kombinacji.

1. Lista dozwolonych: odmów wszystkiego, czego jawnie nie zezwalasz

Najsilniejszą kontrolą jest lista dozwolonych. Zamiast próbować wyliczyć każde niebezpieczne narzędzie, wyliczasz narzędzia, których ten agent legalnie potrzebuje — i odmawiasz wszystkiego innego. To bazowa linia zero trust. Polityka z default_verdict: deny i jawnymi regułami allow dla każdego zatwierdzonego narzędzia to osiąga. Przykład: agent, który powinien tylko odczytywać z CRM:

[
  {
    "priority": 10,
    "label": "allow crm reads",
    "tool_name_glob": "crm.get*",
    "verdict": "allow"
  },
  {
    "priority": 20,
    "label": "allow crm search",
    "tool_name_glob": "crm.search",
    "verdict": "allow"
  },
  {
    "priority": 9999,
    "label": "deny everything else",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]

Każde wywołanie shell.exec, db.delete, payment.transfer — czy wydane celowo, czy wywołane przez wstrzykniętą instrukcję — trafia na catch-all * i zwraca błąd HTTP 400 firewall_blocked. Agent widzi strukturalny błąd narzędzia i nie może ponowić (blokada jest oznaczona skip-retry), więc nie może okrążyć odmowy.

Ustaw default_verdict swojej polityki na deny dla pełnego egzekwowania listy dozwolonych. Przy domyślnym werdykcie audit, nieobsługiwane wywołania są dozwolone i logowane, ale nie blokowane — przydatne podczas wdrożenia, ale nie sama w sobie kontrola bezpieczeństwa.

Wzorce glob pozwalają zezwolić na całe rodziny narzędzi jedną regułą. Typowe wzorce:

Wzorzec	Co obejmuje
`crm.*`	Wszystkie narzędzia w przestrzeni nazw `crm`
`*.read`	Dowolne narzędzie z czasownikiem read we wszystkich serwerach
`db.query`	Dokładnie to jedno narzędzie
`*`	Wszystko (używaj dla catch-all deny)

Dopasowanie narzędzi działa na zasadzie pierwszego pasującego w rosnącej kolejności priorytetu. Umieszczaj swoje konkretne reguły allow przy niskich numerach priorytetów i catch-all deny przy wysokim.

2. Walidacja argumentów: zezwól na narzędzie, blokuj niebezpieczne wywołanie

Lista dozwolonych nazw narzędzi jest zgrubna — blokuje shell.exec całkowicie. Czasami chcesz zezwolić na narzędzie, ale ograniczyć to, jak może być wywoływane. Klauzule argumentów pozwalają dopasować konkretne pola wewnątrz argumentów wywołania narzędzia, używając JSONPath i zestawu operatorów. Przykład: zezwól na shell.exec, ale blokuj rm -rf

{
  "priority": 10,
  "label": "block destructive rm",
  "tool_name_glob": "shell.exec",
  "args_match": {
    "clauses": [
      {
        "path": "$.command",
        "op": "regex",
        "value": "rm\\s+-[^\\s]*r[^\\s]*f|mkfs|dd\\s+if=|:\\(\\)\\{.*\\}"
      }
    ]
  },
  "verdict": "deny"
}

Ta reguła odpala tylko gdy shell.exec jest wywoływane i argument $.command pasuje do regex destrukcyjnego polecenia. Normalne wywołanie shell.exec z bezpiecznym poleceniem przechodzi do następnej reguły (lub domyślnego werdyktu). Umieść tę regułę przy niższym numerze priorytetu niż jakakolwiek ogólna reguła allow shell.exec, aby odpaliła pierwsza. Pełny zestaw operatorów argumentów:

Operator	Użyj gdy
`eq`	Dokładne dopasowanie na wartości skalarnej (łańcuch lub liczba)
`contains`	Dopasowanie podłańcucha — np. `$.query` `contains` `DROP TABLE`
`regex`	Dopasowanie wzorca RE2 — bezpieczne na gorącej ścieżce, bez backtrackingu
`in`	Wartość musi być w danej tablicy — np. zezwól tylko na konkretne środowiska
`cidr_match`	Adres IP w bloku CIDR — przydatne do sprawdzania miejsca docelowego egress
`gt` / `lt`	Porównanie numeryczne — np. `$.amount` `gt` `10000` dla pułapów płatności

Wszystkie klauzule w bloku args_match są AND-owane. Jeśli ścieżka nie istnieje w argumentach wywołania, klauzula ewaluuje false i reguła nie odpala — wywołanie przechodzi do następnej reguły lub domyślnego. Przykład ochrony płatności — odmów każdemu wywołaniu narzędzia płatności z kwotą przekraczającą próg:

{
  "priority": 5,
  "label": "cap payment amount",
  "tool_name_glob": "payment.*",
  "args_match": {
    "clauses": [
      { "path": "$.amount_cents", "op": "gt", "value": 100000 }
    ]
  },
  "verdict": "deny"
}

3. Zatwierdzenie przez człowieka: wstrzymaj wysoce ryzykowne wywołania do zatwierdzenia

Dla narzędzi, które są naprawdę konieczne, ale wysoce ryzykowne — wywołanie wdrożenia, zatwierdzenie zwrotu, wysłanie masowego emaila — możesz wymagać podpisania przez człowieka przed kontynuowaniem wywołania. Werdykt pending_approval wstrzymuje wywołanie i zwraca odpowiedź firewall_approval_pending do agenta:

{
  "priority": 20,
  "label": "hold deployment calls for review",
  "tool_name_glob": "deploy.*",
  "verdict": "pending_approval"
}

Agent (lub twój framework) odpytuje id zatwierdzenia. Recenzent zatwierdza lub odrzuca z konsoli lub przez callback webhook. Po zatwierdzeniu agent ponownie przesyła oryginalne wywołanie z jednorazowym tokenem zatwierdzenia, a brama przepuszcza je raz. pending_approval jest kompatybilne z klauzulami argumentów — możesz wstrzymać tylko wywołania, które przekraczają próg, i przepuszczać rutynowe:

[
  {
    "priority": 10,
    "label": "hold large deploys",
    "tool_name_glob": "deploy.release",
    "args_match": {
      "clauses": [
        { "path": "$.environment", "op": "eq", "value": "production" }
      ]
    },
    "verdict": "pending_approval"
  },
  {
    "priority": 20,
    "label": "allow staging deploys",
    "tool_name_glob": "deploy.*",
    "verdict": "allow"
  }
]

4. Jak wygląda zablokowane wywołanie

Odmówione wywołanie na powierzchni inbound (narzędzie ogłoszone w żądaniu) zwraca HTTP 400 z kodem błędu firewall_blocked. Odpowiedź zawiera strukturalne metadata — etykietę dopasowanej reguły, kod powodu i czynniki ryzyka — i jest oznaczona skip-retry, więc pętla nie może uderzać w to samo odmówione wywołanie. Wywołanie zablokowane na powierzchni response (model już wyemitował tool_calls) zwraca błąd narzędzia widoczny dla modelu, dając mu szansę reakcji — wybrania innego narzędzia, zapytania użytkownika lub zatrzymania się — zamiast crashu.

5. Kolejność pierwszego pasującego

Kolejność priorytetów ma znaczenie. Silnik przechodzi reguły w rosnącej kolejności priorytetów i zatrzymuje się przy pierwszym dopasowaniu. Typowy wzorzec:

Priorytet	Reguła	Werdykt
5	`shell.exec` + destrukcyjny regex	`deny`
10	`shell.*` (ogólny)	`allow`
20	`crm.*`	`allow`
9999	`*` (catch-all)	`deny`

Priorytet 5 odpala przed priorytetem 10 — więc shell.exec z destrukcyjnym poleceniem jest odmówiony, nawet jeśli jest ogólny allow dla shell.*. Bez deny o niskim priorytecie, reguła allow shell.* wygrałaby pierwsza.

6. Bezpieczne wdrożenie z trybem cienia

Przed przełączeniem nowej polityki do egzekwowania, włącz tryb cienia. Polityka ewaluuje każde wywołanie narzędzia i loguje werdykt dokładnie tak, jak robiłaby to na produkcji, ale każdy egzekwujący werdykt (deny, pending_approval, sanitize) jest degradowany do audit — nic nie jest blokowane. Powód w logu zdarzeń jest poprzedzony [shadow] would deny, więc możesz zmierzyć wpływ w widokach Events i Runs. Gdy potwierdzisz, że polityka odpala na tym, czego oczekujesz — i nic, czego nie zamierzałeś — wyłącz tryb cienia. Następne wywołanie jest egzekwowane.

Poziom autonomii tight automatycznie stosuje preset block_destructive_shell. Jeśli potrzebujesz szybkiej postawy bez pisania reguł, zastosuj tight z konsoli i dostarcza on politykę deny dla destrukcyjnych wywołań shella w jednym kroku. Możesz potem warstwować swoje własne reguły listy dozwolonych na wierzchu. Zobacz Poziomy autonomii.

7. Powiązane zagrożenia

Nadużycie narzędzi agenta rzadko przybywa w izolacji. Nieautoryzowane wywołanie narzędzia jest często konsekwencją innego wektora ataku:

Prompt injection — atakujący osadza instrukcje w pobranej treści, które kierują agenta ku narzędziom, których nie miał wywoływać.
Nadmierne uprawnienia — agentowi przyznano więcej dostępu do narzędzi niż wymaga jego zadanie, co sprawia, że każdy injection lub błędna konfiguracja jest natychmiast niebezpieczna.
Model zagrożeń — jak nadużycie narzędzi mieści się w pełnej powierzchni ataku dla systemów agentów.

Agent Firewall jest warstwą egzekwowania; zasada najmniejszych uprawnień (wąskie listy dozwolonych narzędzi, klucze o ograniczonym zakresie) to postawa projektowa, która czyni ją skuteczną.

Referencja reguł firewalla

Kompletny język dopasowania — globy narzędzi, klauzule argumentów, wszystkie operatory, werdykty i API.

Przegląd firewalla

Polityki, powierzchnie, poziomy autonomii, zatwierdzenie HITL i obserwowalność.

​1. Lista dozwolonych: odmów wszystkiego, czego jawnie nie zezwalasz

​2. Walidacja argumentów: zezwól na narzędzie, blokuj niebezpieczne wywołanie

​3. Zatwierdzenie przez człowieka: wstrzymaj wysoce ryzykowne wywołania do zatwierdzenia

​4. Jak wygląda zablokowane wywołanie

​5. Kolejność pierwszego pasującego

​6. Bezpieczne wdrożenie z trybem cienia

​7. Powiązane zagrożenia

Referencja reguł firewalla

Przegląd firewalla

1. Lista dozwolonych: odmów wszystkiego, czego jawnie nie zezwalasz

2. Walidacja argumentów: zezwól na narzędzie, blokuj niebezpieczne wywołanie

3. Zatwierdzenie przez człowieka: wstrzymaj wysoce ryzykowne wywołania do zatwierdzenia

4. Jak wygląda zablokowane wywołanie

5. Kolejność pierwszego pasującego

6. Bezpieczne wdrożenie z trybem cienia

7. Powiązane zagrożenia