Narzędzia są tym, co odróżnia demonstrację od systemu produkcyjnego. W produkcji liczą się granice zaufania: model nie widzi sekretów, a decyzje o wykonaniu podejmuje warstwa polityk i bramek.
W skrócie
sekrety poza LLM (Vault/Broker), tokeny krótkotrwałe i zakresowe
bramki przed wykonaniem: Schema, RBAC, DLP, idempotency, rate limits
rotacja, revocation i kill‑switch jako element procesu, nie „opcjonalny dodatek”
Jeśli to ma wejść do procesu, proszę traktować ten rozdział jako standard operacyjny.
Zasada nadrzędna: model językowy nie jest miejscem na sekrety. Sekrety żyją w warstwie narzędziowej (Tool Gateway / Vault),
a model dostaje wyłącznie to, co musi — w postaci danych wejściowych i wyniku działania narzędzia.
1. Cel i model zagrożeń
„Narzędzia” w chatbotach (API, bazy, systemy CRM, wyszukiwarki, płatności, wewnętrzne workflow) są siłą — i jednocześnie ryzykiem.
Ten rozdział opisuje minimalny, produkcyjny standard: jak wydawać dostęp i sekrety tak, aby:
model nie miał bezpośredniego dostępu do kluczy,
uprawnienia były najmniejsze konieczne (least privilege),
każde wykonanie było audytowalne (trace_id + policy_version),
incydent dało się zatrzymać jednym ruchem (revocation / kill‑switch).
2. Zasady, które się nie starzeją
Zasada
Co to znaczy w praktyce
Najczęstszy błąd
Brak sekretów w promptach
Model nie widzi kluczy API, tokenów, haseł ani connection stringów.
„Tylko na chwilę” wklejony token do kontekstu debug.
Tokeny krótkotrwałe (TTL)
Broker wydaje tokeny czasowe i zakresowe (scope), najlepiej per‑request.
Długowieczne tokeny w konfiguracji aplikacji.
Uprawnienia per‑użytkownik / per‑rola
Tożsamość użytkownika jest propagowana do warstwy narzędziowej (impersonation / delegated auth).
„Service account” z uprawnieniami admin dla wszystkiego.
Bramki przed wykonaniem
Schema, RBAC, DLP, rate‑limit, idempotency — zanim pójdzie request do narzędzia.
Walidacja po fakcie, już po stronie narzędzia.
Audyt i ślad decyzji
Logujesz nie tylko wynik, ale decyzje: polityka, wersja, odmowa, wyjątek.
Log „success/fail” bez kontekstu.
3. Architektura: Tool Gateway + Broker sekretów
W dojrzałym wdrożeniu model nie „dzwoni” bezpośrednio do API. On prosi o wywołanie narzędzia, a decyzję podejmuje
warstwa pośrednia.
Praktyczny wzorzec:Tool Gateway to miejsce na polityki, a Vault/Broker to miejsce na sekrety.
Model dostaje wynik narzędzia, nigdy sekret.
4. Polityki: scope, RBAC i tryby akceptacji
Najszybciej psuje się system, w którym „jakoś to będzie”. Dlatego warto mieć trzy tryby wykonania:
AUTO‑EXECUTE — tylko dla operacji bezpiecznych i odwracalnych (read‑only, niskie ryzyko),
REQUIRE APPROVAL — człowiek zatwierdza (np. akcje w systemie, wysyłka, modyfikacje),
BLOCK — operacja nie jest dostępna przez chat w ogóle.
Minimalny kontrakt polityki (czytelny i audytowalny):