Uprawnienia agenta AI powinny określać, **kto wywołuje narzędzie, z jakiego połączenia korzysta, do jakiego zasobu ma dostęp, co zmienia jego działanie i kto ostatecznie zatwierdza zmianę**. Katalog narzędzi pokazuje agentowi dostępne polecenia. Serwer nadal musi rozstrzygnąć, czy ten wywołujący może teraz wykonać dane polecenie na konkretnym obiekcie. Odpowiedź musi zaś mówić, co rzeczywiście się stało.

To rozróżnienie nabiera znaczenia, gdy jeden interfejs pozwala znaleźć tysiące operacji. 28 września Cloudflare udostępnił [CLI `cf` przeznaczone również dla agentów](https://blog.cloudflare.com/cloudflare-cf-cli-launch/) do obsługi swojego API. Łatwiejsze wyszukiwanie poleceń nie oznacza prawa do ich wykonania. [Dyskusja na Hacker News](https://news.ycombinator.com/item?id=49879577) pokazuje, dlaczego premiera zainteresowała administratorów, ale komentarze są pytaniami i opiniami, a nie oceną bezpieczeństwa CLI.

W produkcie SaaS warto opisać zasady każdej istotnej operacji. Narzędzia Kit do rekrutacji, obsługi zgłoszeń podatności i zarządzania zespołem dają konkretne przykłady: podobnie brzmiące czynności mają różne skutki. Odpowiedź do kandydata można przygotować bez wysyłania. Można zaproponować nagrodę bez jej przyznania. Inne dozwolone wywołania od razu zmieniają stan systemu. To decyzje projektowe, które można sprawdzić w kodzie i testach.

## Co zmieniła premiera `cf` od Cloudflare?

Według Cloudflare CLI `cf`, dostępne w otwartej becie, udostępnia polecenia wyprowadzone z API obejmującego **ponad 3000 operacji**. Dla porównania Wrangler ma około 280 ścieżek poleceń. `cf` domyślnie zwraca JSON i oferuje `cf cli search`, więc agent może znaleźć właściwe polecenie na podstawie opisu w języku naturalnym, bez trzymania całego katalogu w kontekście. To zmiany w **sposobie wyszukiwania poleceń i konstrukcji interfejsu**, opisane we [wpisie Cloudflare o premierze](https://blog.cloudflare.com/cloudflare-cf-cli-launch/) i w [repozytorium `cf`](https://github.com/cloudflare/cf).

Cloudflare podaje też, że w tygodniu przed ogłoszeniem agenci odpowiadali za 48% użycia Wranglera, wobec 25% w marcu 2026 r. To własny pomiar Cloudflare dotyczący Wranglera; we wpisie nie ujawniono ani mianownika, ani metody pomiaru. Nie jest to wskaźnik korzystania z produktu przez klientów.

W tym samym interfejsie agent może wyszukać odczyt danych, deploy, zmianę reguły WAF lub zakup domeny. Nie znaczy to, że ma uprawnienia do wszystkich tych działań. [Dokumentacja tokenów API Cloudflare](https://developers.cloudflare.com/fundamentals/api/how-to/create-via-api/) opisuje zasady dostępu według zasobów i grup uprawnień, a [wykaz uprawnień](https://developers.cloudflare.com/fundamentals/api/reference/permissions/) rozdziela odczyt i zapis dla użytkowników, kont oraz stref. Dokumenty wyjaśniają dostępne mechanizmy kontroli API. Samo ogłoszenie nie określa jednak, jak w każdym wywołaniu `cf` działają uwierzytelnianie i zatwierdzanie operacji.

Dla każdego, kto udostępnia duży katalog narzędzi, wniosek jest prosty: **możliwość znalezienia polecenia nie daje prawa do jego wykonania**. Opis polecenia podpowiada agentowi, jak złożyć żądanie. Tylko system obsługujący żądanie może zdecydować, czy obecny wywołujący ma prawo działać na danym obiekcie w jego aktualnym stanie. Im łatwiej znaleźć polecenia, tym ważniej opisać tę decyzję dla każdego z nich.

## Co trzeba określić w uprawnieniach agenta AI?

Skuteczne uprawnienie agenta AI opisuje **zasób i działanie**. Sama etykieta „odczyt” lub „zapis” nie wystarczy. Zanim udostępnisz narzędzie, zapisz, jakie uprawnienia ma połączenie, kto obecnie działa, jak wyszukiwany jest obiekt, jaki stan dopuszcza operację, jaki będzie jej skutek, kto ostatecznie zatwierdza zmianę, kto zobaczy jej efekt, co widać w odpowiedzi i co dzieje się po odmowie.

Wyobraź sobie prośbę: „Wyślij odpowiedź do tej osoby, która aplikowała”. Połączenie może mieć zakres `hiring_write` dla całego modułu, ale członek zespołu może być przypisany tylko do jednego ogłoszenia. Aplikacja może dotyczyć innego ogłoszenia, możliwość odpowiedzi mogła już wygasnąć, a narzędzie może tworzyć wyłącznie szkic. Od każdej z tych kwestii zależy, czy agent może wykonać zadanie. Szeroki zakres dostępu jest tu konieczny, ale niewystarczający.

Zacznij od sześciu pytań:

1. **Kto działa?** Ustal, jaka osoba lub tożsamość usługi jest powiązana z połączeniem. Sprawdź jej obecne członkostwo na koncie i rolę, a nie tylko rolę z chwili utworzenia połączenia.
2. **Co przekazano agentowi?** Nazwij zakres połączenia oraz konto lub moduł, którego dotyczy. Token z prawem zapisu w jednym module nie powinien po cichu sięgać do innego.
3. **Którego obiektu dotyczy żądanie?** Wyszukaj ID wśród obiektów widocznych dla tej osoby. Zapytanie obejmujące całe konto może być zbyt szerokie przy dostępie ograniczonym do wybranego ogłoszenia lub prywatnego zgłoszenia podatności.
4. **Jaki stan pozwala działać?** Osoba uprawniona do aktualizacji rekordu kandydata może już nie mieć prawa odpowiedzieć po zamknięciu procesu. Sprawdź stan procesu podczas wykonania operacji.
5. **Co zostanie zapisane lub wysłane?** Odróżnij sugestię, wewnętrzny szkic, bezpośrednią zmianę w bazie, wiadomość do innej osoby i płatność. Sama nazwa narzędzia tego nie wyjaśnia.
6. **Co wywołujący zobaczy później?** Odpowiedź może ujawnić prywatne liczby, nazwiska lub rekordy nawet wtedy, gdy zapis był dozwolony. Wynik musi respektować uprawnienia tej osoby do odczytu.

Dzięki tym pytaniom wymóg „zatwierdzenia przez człowieka” można przetestować: kto zatwierdza, w jakim kanale i który endpoint to egzekwuje?

## Dlaczego zakres połączenia to dopiero pierwszy sprawdzian?

Zakres połączenia ogranicza operacje, o które klient może poprosić. Nie rozstrzyga, czy członek zespołu może pracować na **tym konkretnym rekordzie**. Serwer musi uwzględnić jednocześnie uprawnienia połączenia, aktualne członkostwo, konto, widoczność rekordu, reguły dostępu i stan procesu.

Zewnętrzne połączenie MCP w Kit używa zakresów OAuth takich jak `hiring_read`, `hiring_write`, `csirt_read`, `csirt_write` i `team_write`. Podczas wyrażania zgody można przyznać tylko zakresy dostępne dla obecnego członka konta. Sam podstawowy zakres `mcp` nie daje dostępu do żadnego modułu produktu. Przy wywołaniu narzędzia Kit ponownie sprawdza zakres tokena oraz aktualny dostęp do modułu. Ukrycie narzędzia na liście służy jedynie wygodzie: klient nadal może podać nazwę narzędzia, którego nie widział. Przebieg połączenia opisuje [poradnik Kit dotyczący podłączania asystentów AI](/docs/connecting-ai-assistants).

W przypadku aplikacji Kit szuka jej w ogłoszeniach o pracę widocznych dla danego członka zespołu, a następnie stosuje reguły dostępu do aplikacji. Aplikacja z ogłoszenia o ograniczonym dostępie jest traktowana jak nieznaleziona, jeśli ten członek zespołu nie ma do niego dostępu. W przypadku widocznego rekordu reguły dostępu mogą z kolei odmówić wykonania żądanego działania. Podobnie wyszukiwane są zgłoszenia podatności widoczne dla członka zespołu, choć poszczególne działania podlegają różnym kontrolom roli i uprawnień. Kontekst konta ogranicza dostęp do właściwego klienta, a sposób wyszukania obiektu — do właściwego celu.

Można to sprawdzić testem odmowy. Połącz się jako członek zespołu bez uprawnień administratora, używając połączenia z zakresem `hiring_write` dla całego modułu. Poproś narzędzie o aktualizację aplikacji z ogłoszenia o ograniczonym dostępie, do którego ta osoba nie ma dostępu. Oczekiwany wynik to „nie znaleziono”, bez zdradzenia, czy aplikacja istnieje. Następnie obniż tej osobie dostęp do modułu i ponów żądanie przez istniejące połączenie. Kit sprawdza dostęp przy każdym wywołaniu, więc kolejne żądanie uwzględni obecną rolę. Nie usunie to jednak informacji, które klient już dostał, ani nie cofnie wcześniej zapisanej zmiany.

[Ograniczenia tokenów API Cloudflare](https://developers.cloudflare.com/fundamentals/api/how-to/restrict-tokens/) pokazują inną warstwę ochrony: tokeny można ograniczyć czasowo i według adresu IP klienta. Skraca to okres lub zawęża miejsce użycia poświadczenia. Nie zastępuje reguł dostępu do konkretnych zasobów w produkcie SaaS, do którego prowadzi wywołanie narzędzia.

## Co się dzieje, gdy agent przygotowuje odpowiedź do kandydata?

Nazwa narzędzia Kit `hiring_send_message` sugeruje wysłanie wiadomości na zewnątrz. W rzeczywistości dozwolone wywołanie **przygotowuje odpowiedź oczekującą na wysłanie**. Członek zespołu przegląda ją i wysyła z wątku mailowego aplikacji. Mówi o tym odpowiedź narzędzia. Granicę wyznacza stan szkicu na serwerze, a nie instrukcja prosząca model o potwierdzenie treści.

Wywołanie wymaga powiązania z członkiem konta posiadającym `hiring_write`. Kit wyszukuje aplikację w ogłoszeniach widocznych dla tej osoby, sprawdza prawo do jej aktualizacji oraz to, czy obecny stan wątku pozwala przygotować odpowiedź. Sukces oznacza utworzenie wewnętrznego szkicu i zwrócenie linku do wątku. Mail do kandydata wychodzi dopiero po zatwierdzeniu w interfejsie webowym.

Taki szkic też ma znaczenie. Może zawierać wrażliwe lub mylące sformułowania i wpłynąć na osobę, która później naciśnie „Wyślij”. Bezpośredni skutek to jednak **„szkic czeka”, a nie „kandydat dostał wiadomość”**. Odpowiedź narzędzia ograniczona do „Gotowe” ukrywałaby najważniejszy fakt o tej operacji.

Opisz to jako dwa działania: *przygotowanie odpowiedzi* i *wysłanie odpowiedzi*. Przy pierwszym agent może zapisać szkic po pomyślnym sprawdzeniu rekordu; treść pozostaje wewnątrz zespołu. Przy drugim ostateczną decyzję podejmuje członek zespołu w interfejsie webowym, a odbiorcą staje się kandydat. Jeśli projektujesz to inaczej, nazwij swoją decyzję równie wyraźnie. Sam zakres połączenia nie powie czytelnikowi, które działanie nastąpiło.

Ta sama różnica dotyczy narzędzia CRM o nazwie `send_quote`: może zapisać ofertę do review, dodać mail do kolejki albo wysłać go od razu. Zanim opiszesz skutek, sprawdź, co zostało zapisane i co dotarło do odbiorcy.

## Czym propozycja nagrody różni się od jej przyznania?

Narzędzia Kit do obsługi zgłoszeń podatności pokazują, dlaczego „zapis” jest zbyt ogólną kategorią. `csirt_propose_bounty` tworzy **wewnętrzną propozycję kwoty** przy zgłoszeniu widocznym dla członka zespołu. Nie przyznaje nagrody, nie tworzy wpisu w księdze finansowej, nie powiadamia badacza i nie uruchamia płatności. Późniejsza propozycja może zastąpić otwartą propozycję, przez co wcześniejsze głosy tracą ważność. To rzeczywisty zapis, lecz jego odbiorcy i skutki są ograniczone.

Członkowie zespołu mogą przez `csirt_vote_bounty_proposal` oddać głos doradczy. Gdy głosowanie odbywa się w ciemno, odpowiedź nie może zdradzić zakrytego wyniku w opisie, nawet jeśli ukrywa go w danych strukturalnych. Dlatego obok uprawnienia do zapisu trzeba sprawdzić **widoczność odpowiedzi**: prawo do głosowania nie daje automatycznie prawa do poznania głosów wszystkich innych osób.

`csirt_approve_bounty` wymaga uprawnień administratora modułu CSiRT i połączenia z zakresem `csirt_write`. Dozwolone wywołanie bezpośrednio zapisuje w Kit decyzję o przyznaniu nagrody, zgodnie z regułami obowiązującymi dla zgłoszenia. Opis narzędzia prosi asystenta o potwierdzenie kwoty i rodzaju nagrody z użytkownikiem, ale jest to wskazówka dla klienta, a nie dodatkowy warunek egzekwowany przez serwer. Zatwierdzenie **nie przekazuje pieniędzy**; wypłata odbywa się poza Kit.

Dlatego wymóg udziału człowieka trzeba doprecyzować. W przypadku propozycji decyzja człowieka dopiero zapadnie. Przy narzędziu zatwierdzającym ostateczny zapis w Kit następuje po wywołaniu przez uprawnionego administratora. Jeśli twoje zasady wymagają drugiego zatwierdzenia nagrody, dodaj osobną zmianę stanu egzekwowaną po stronie serwera. Zapis rozmowy z odpowiedzią „tak” jej nie zastąpi.

Porównaj skutek opisany przy narzędziu z rzeczywistym wynikiem. „Nagroda zatwierdzona w Kit” nie oznacza, że została wypłacona. Odpowiedź dotycząca propozycji nie powinna sugerować, że badaczowi obiecano pieniądze.

## Kiedy zmianę dostępu do zespołu trzeba przenieść poza chat?

Zmiana uprawnień współpracownika wykracza poza jeden proces. Kit obsługuje ją inaczej w zależności od kanału. W **chacie AI wewnątrz produktu** adapter blokuje zaproszenia do zespołu, zmiany dostępu, edycję i cofanie zaproszeń oraz usuwanie członków. Zamiast tego odsyła do ustawień wymagających uwierzytelnienia. Widoczna dla modelu odpowiedź „tak, zatwierdzam” nie czyni chatu zaufanym miejscem do przyznawania dostępu, zwłaszcza gdy model mógł wcześniej przeczytać dokumenty kontrolowane przez kandydatów.

**Zewnętrzne połączenie OAuth MCP działa według innych zasad**. Administrator konta może otrzymać `team_write` i użyć `team_update_member_access` do bezpośredniej zmiany roli lub poziomu dostępu członka zespołu do modułów. Narzędzie wyszukuje tę osobę w obrębie konta i chroni właściciela konta przed zmianą roli lub obniżeniem uprawnień. `team_invite_member` może wysłać zaproszenie albo przypisać istniejącego użytkownika do rekrutacji, zależnie od danych wejściowych, po sprawdzeniu uprawnień administratora i konta. To bezpośrednie działania, a nie przekierowania do ustawień.

Ta różnica powinna być widoczna w każdym przeglądzie uprawnień. Zdanie „Chat Kit nie może zmieniać dostępu do zespołu” jest prawdziwe dla adaptera wewnątrz produktu. Stwierdzenie „Żaden agent nie może zmieniać dostępu do zespołu” już nie. Zewnętrzny klient z odpowiednim uprawnieniem może wywołać inną ścieżkę, która bezpośrednio zapisuje zmianę. Jeśli twój produkt ma asystenta webowego, API i zdalny serwer narzędzi, opisz osobno każdy kanał zdolny wykonać tak samo nazwane działanie.

Ważniejsze od obietnicy modelu, że najpierw zapyta, jest miejsce egzekwowania reguły. Przekierowanie do ustawień wyznacza granicę kanału. Zewnętrzne narzędzie administratora sprawdza rolę przez zakres połączenia i uprawnienia administratora. Obie sytuacje wymagają dokładniejszego opisu niż samo „zatwierdzenie”.

## Co powinna zawierać lista kontrolna zasobów i działań?

Utwórz osobny wiersz dla **każdego rzeczywistego skutku**, nawet gdy produkt ujmuje kilka skutków pod jedną prostą nazwą. Wypełnij go na podstawie kodu i testów, a potem sprawdź przez dozwolone i odrzucone wywołanie. Oto skrócona lista dla sześciu działań w Kit:

| Działanie | Uprawnienie i wywołujący | Ograniczenia zasobu i stanu | Skutek i ostateczna decyzja | Granica, którą trzeba nazwać |
| --- | --- | --- | --- | --- |
| Odczyt podsumowania aplikacji | `hiring_read`; powiązany członek zespołu | Aplikacja pod widocznym ogłoszeniem | Zwraca dane kandydata i notatki; niczego nie zapisuje | Wynik zawiera wrażliwe dane rekrutacyjne. |
| Przygotowanie odpowiedzi do kandydata | `hiring_write`; powiązany członek zespołu uprawniony do aktualizacji aplikacji | Aplikacja pod widocznym ogłoszeniem; stan procesu pozwala przygotować odpowiedź | Wewnętrzny szkic oczekuje; członek zespołu wysyła go w interfejsie webowym | Kandydat nie dostał jeszcze maila. |
| Przeniesienie aplikacji do kolejnego etapu | `hiring_write`; członek zespołu uprawniony do zmiany etapu | Widoczna aplikacja; prawidłowy następny lub wybrany etap | Etap zmienia się od razu; powiadomienia obsługuje proces | Narzędzie nie ma osobnego kroku zatwierdzenia. |
| Propozycja nagrody | `csirt_write`; członek zespołu z dostępem do CSiRT | Zgłoszenie widoczne dla członka zespołu; reguły programu i kwoty | Narzędzie zapisuje wewnętrzną propozycję | Bez przyznania nagrody, powiadomienia i płatności. |
| Zatwierdzenie nagrody | `csirt_write`; administrator modułu CSiRT | Zgłoszenie w programie konta; reguły przyznawania nagrody | Dozwolone wywołanie zapisuje w Kit przyznanie nagrody | Bez przelewu; prośba modelu o potwierdzenie nie jest dodatkową kontrolą serwera. |
| Zmiana dostępu do zespołu | `team_write`; administrator konta korzystający z zewnętrznego MCP | Członek konta; ochrona właściciela | Zewnętrzne MCP bezpośrednio zmienia dostęp członka zespołu | Chat wewnątrz produktu odsyła zamiast tego do ustawień. |

Do każdego wiersza we własnym systemie dodaj trzy kolumny, które mogą nie mieścić się w zwięzłym opisie produktu: **odbiorca poza systemem**, **widoczność wyniku** i **dowód podjęcia decyzji**. Mail ma odbiorcę. Podsumowanie prywatnego zgłoszenia podatności ma określonych odbiorców. Po nieudanym wywołaniu trzeba podać powód odmowy pomocny uprawnionej osobie, lecz bez ujawniania niedostępnego rekordu. Te szczegóły często pokazują ograniczenie niewidoczne w tabeli zakresów.

Następnie wykonaj cztery testy implementacji:

1. **Pomiń katalog narzędzi.** Wywołaj narzędzie bezpośrednio po nazwie, nawet jeśli nie pojawiło się na liście. Serwer nadal musi sprawdzić zakres połączenia i rolę.
2. **Sprawdź granicę dostępu do obiektu.** Użyj wiarygodnie wyglądającego ID z innego konta albo z obiektu o ograniczonym dostępie na tym samym koncie. Oba żądania powinny zakończyć się odmową bez ujawnienia istnienia lub treści prywatnego obiektu.
3. **Zmień dostęp w trakcie trwania połączenia.** Obniż rolę członka zespołu i ponów wywołanie. Następne żądanie powinno uwzględniać bieżące uprawnienia. Wcześniej pobrane dane, wyniki w cache i podpisane adresy URL wymagają osobnego rozważenia przy odbieraniu dostępu.
4. **Odczytaj odpowiedź dosłownie.** Sprawdź, czy „szkic”, „propozycja”, „przyznanie”, „wysłano” i „wypłacono” odpowiadają zapisowi w systemie oraz skutkom poza nim. Ludzie mogą działać na podstawie podsumowania wyniku, więc ono również podlega zasadom bezpieczeństwa.

Równie dokładnie trzeba opisać, jakie ślady pozostawia działanie. Kit oznacza niektóre narzędzia dla klientów MCP jako destrukcyjne lub powodujące skutek poza systemem i emituje zdarzenia strukturalne dla **wywołań narzędzi open-world**. Oznaczenia wpływają na prezentację w kliencie; nie dodają zatwierdzania po stronie serwera. Zdarzenia nie stanowią niezmiennego rejestru audytowego wszystkich wywołań narzędzi. Kit wlicza też zewnętrzne wywołania MCP do limitu konta, również wewnątrz wywołań zbiorczych. Ogranicza to użycie, ale nie przyznaje dostępu do obiektu. Określ własne wymagania dotyczące audytu i sprawdź, czy endpoint zapisujący zmianę gromadzi wystarczające dowody.

Odebranie dostępu ma podobne granice. Sprawdzenie bieżącej roli może zatrzymać przyszłe wywołanie przez istniejące połączenie. Nie cofnie wysłanego maila ani zapisanej zmiany dostępu, nie odbierze danych skopiowanych już do kontekstu agenta i nie unieważni automatycznie wydanego podpisanego adresu URL. Jeśli twój proces tworzy takie artefakty, wypisz je i określ czas ich ważności lub sposób unieważnienia.

## Jak Kit stosuje te zasady w praktyce?

W Kit **obiekt i ostateczny skutek** są określone wprost. Zakres przekazany połączeniu MCP otwiera dostęp do modułu, aktualne członkostwo i konto ograniczają uprawnienia wywołującego, a sposób wyszukania rekordu przez narzędzie ogranicza dostęp do celu operacji. Następnie działanie może utworzyć szkic, zapisać propozycję, odesłać do ustawień albo bezpośrednio zapisać zmianę. Przebieg połączenia opisuje [poradnik Kit dotyczący asystentów AI](/docs/connecting-ai-assistants), a szersze zastosowanie w rekrutacji — [MCP w rekrutacji](/blog/mcp-for-hiring).

Wybierz jedno narzędzie o istotnych skutkach, wypełnij listę kontrolną i przetestuj odmowę dostępu do obiektu, zmianę roli oraz końcową odpowiedź. Jeśli podłączasz asystenta do Kit, sprawdź procesy, których potrzebuje twój zespół, zanim przyznasz zakresy z prawem zapisu. Agent powinien umieć powiedzieć, co zmienił, z czyjego upoważnienia i co nadal wymaga działania człowieka.