Gdy agent AI posiada własne dane uwierzytelniające i bezpośrednio łączy się z zewnętrznymi usługami, zachowuje się mniej jak oprogramowanie pracownicze, a bardziej jak kontrahent z kartą korporacyjną i bez nadzoru. Nie widzisz, czego dotknął, kto zatwierdził dostęp lub dlaczego jedna rozmowa kosztowała dziesięć razy więcej niż inna. Logi są rozproszone w kilkunastu usługach. Pytań przybywa.
Którego narzędzia agent faktycznie użył? Kto udzielił mu uprawnień do dotknięcia tej bazy danych? Dlaczego wtorkowe uruchomienie zużyło czterdzieści tysięcy tokenów, podczas gdy poniedziałkowe wykorzystało tylko pięć? Ile naprawdę wydaliśmy?
Bez centralnej warstwy kontrolnej umieszczonej między użytkownikami, modelami a usługami, pytania te pozostają bez odpowiedzi. Potrzebujesz pojedynczej płaszczyzny, która raz rejestruje każde połączenie, udostępnia tylko wąski zestaw funkcji, których agent naprawdę potrzebuje, i w pełni rejestruje każde wykonanie. Ten artykuł przeprowadzi Cię przez zaawansowane laboratorium z wykorzystaniem deco Studio jako lokalnej płaszczyzny kontrolnej. Skonfigurujesz ją, połączysz bezpieczny serwer Model Context Protocol, udostępnisz dokładnie jedną dozwoloną funkcję i zobaczysz, co się stanie, gdy agent spróbuje wyjść poza swoje granice.
Problem z rozproszonymi danymi uwierzytelniającymi
Wyobraź sobie typową konfigurację zespołu. Jeden programista łączy agenta z API wyszukiwania, używając osobistego klucza. Inny podłącza tego samego agenta do bazy produkcyjnej, ponieważ demo wyglądało nieszkodliwie. Trzeci dodaje narzędzie do sprawdzania płatności, aby agent mógł „pomagać w fakturach”. Każde połączenie jest niewidoczne dla pozostałych. Agent ma teraz bezpośredni dostęp do wyszukiwania, danych produkcyjnych i dokumentacji finansowej, ale zespół nie posiada jednolitej listy aktywnych połączeń.
Gdy dane uwierzytelniające znajdują się wewnątrz agenta, zarządzanie (governance) przestaje działać. Nie możesz cofnąć dostępu centralnie, ponieważ klucz znajduje się w pamięci agenta lub w jego lokalnym pliku środowiskowym. Nie możesz kontrolować użycia, ponieważ zewnętrzna usługa widzi jedynie wywołanie API z anonimowego, zautomatyzowanego klienta. Niespodziewane koszty pojawiają się kilka dni później na rachunku za chmurę, a do tego czasu nikt nie pamięta, który prompt spowodował nagły wzrost.
Budowanie własnej płaszczyzny kontrolnej w deco Studio
deco Studio rozwiązuje ten problem, działając jako lokalne centrum (hub). Uruchamiasz je na własnej maszynie, a staje się ono jedynym miejscem, w którym przechowywane są konfiguracje. Zamiast rozpraszać klucze API i definicje narzędzi między agentami, rejestrujesz połączenie raz wewnątrz Studio. Następnie decydujesz dokładnie, jakie funkcje może widzieć każdy agent.
Pomyśl o tym jak o instalacji centrali telefonicznej. Wszystkie kable biegną do jednego pomieszczenia. Wybierasz, które linie łączą się z którymi działami, i prowadzisz rejestr każdej rozmowy.
Zacznij od uruchomienia deco Studio lokalnie. Gdy już będzie działać, scentralizuj konfigurację. Każdy agent, który chce użyć narzędzia, musi teraz zapytać o to płaszczyznę kontrolną, a nie bezpośrednio zewnętrzną usługę. Tworzy to natychmiastowy punkt kontrolny (chokepoint), w którym możesz obserwować, filtrować i logować działania.
Łączenie bezpiecznego serwera MCP
W tym laboratorium połączysz serwer Model Context Protocol. MCP to otwarty standard umożliwiający modelom interakcję z zewnętrznymi narzędziami, ale standardy nie gwarantują bezpieczeństwa. Kluczowym krokiem jest tutaj selektywność. Nie udostępniasz ślepo każdego punktu końcowego (endpoint), który oferuje serwer. Rejestrujesz serwer w deco Studio, a następnie udostępniasz tylko jedną dozwoloną funkcję swojemu testowemu agentowi.
Na przykład Twój serwer MCP może oferować dziesięć funkcji: odczyt pliku, zapis pliku, zapytanie do bazy danych, pobieranie danych z sieci i inne. Wybierasz jedną nieszkodliwą operację, być może piaskownicowy (sandboxed) kalkulator lub odczyt tylko do odczytu z danych syntetycznych, i udostępniasz tylko ją. Pozostałe dziewięć staje się niewidocznych dla agenta. Jeśli agent o nie poprosi, płaszczyzna kontrolna zwróci kategoryczną odmowę.
To zasada najmniejszych uprawnień (principle of least privilege) zrealizowana w sposób mechaniczny. Agent otrzymuje możliwości nie poprzez uprzejmą instrukcję, lecz poprzez barierę programową.
Testowanie granic
Utwórz testowego agenta i skieruj go na swoją płaszczyznę kontrolną deco Studio. Przydziel mu zadanie wymagające tej jedynej dozwolonej funkcji. Obserwuj, jak odnosi sukces. Logi wewnątrz Studio pokażą zapytanie modelu, trasowanie wywołania narzędzia przez płaszczyznę kontrolną, wykonanie funkcji oraz wynik wracający do modelu. Możesz przeczytać całą ścieżkę w jednym ciągłym śladzie (trace).
Teraz daj agentowi drugie zadanie, które wymaga funkcji, którą celowo wykluczyłeś. Agent może próbować obejść to ograniczenie za pomocą rozumowania lub może ulec halucynacji, że dane narzędzie istnieje. W każdym z tych przypadków wywołanie trafi do control plane, lista zezwoleń (allowlist) je odrzuci, a wykonanie zakończy się niepowodzeniem. To niepowodzenie jest dowodem na to, że granica jest wymuszana programowo, a nie tylko teoretycznie.
Najpierw zrób to za pomocą zadań syntetycznych. Zbuduj fałszywą bazę danych wypełnioną wygenerowanymi profilami użytkowników. Pozwól agentowi ją przeszukiwać. Zweryfikuj działanie allowlisty oraz odrzucanie żądań. Dopiero gdy będziesz ufać tej granicy, powinieneś rozważyć skierowanie agenta do systemów produkcyjnych. Pośpiech w przejściu do rzeczywistych danych przed zweryfikowaniem „ściany” to najprostsza droga do wycieku tajemnic.
Przeglądanie pełnej ścieżki wykonania
deco Studio pozwala na inspekcję każdej warstwy wykonania. Widzisz surowe zapytanie modelu: prompt, okno kontekstowe i formatowanie. Widzisz wywołanie narzędzia, na które zdecydował się model. Widzisz, jak control plane kieruje to wywołanie, jak funkcja jest wykonywana i jak zwracany jest payload. Na koniec widzisz, jak model wykorzystuje ten wynik do sformułowania odpowiedzi.
Ta widoczność pozwala odpowiedzieć na podstawowe pytania audytowe. Wiesz, które narzędzie zostało uruchomione, ponieważ zostało to odnotowane przez control plane. Wiesz, kto przyznał dostęp, ponieważ zapisy konfiguracji znajdują się w jednym lokalnym rejestrze. Wiesz, dlaczego wykonanie było kosztowne, ponieważ możesz policzyć tokeny.
Liczenie tego, co istotne
Dla każdego wykonania śledź cztery konkretne metryki. Po pierwsze, tokeny wejściowe i wyjściowe. To one generują większość kosztów modelu, a Ty potrzebujesz dokładnych wartości, a nie przybliżonych szacunków. Po drugie, oddziel opóźnienie modelu od opóźnienia narzędzia. Czas między Twoim promptem a odpowiedzią modelu różni się od czasu, jaki zewnętrzna usługa potrzebuje na odpowiedź na wywołanie narzędzia. Pomylenie tych dwóch wartości prowadzi do błędnej diagnozy spowolnień. Po trzecie, obliczaj koszty na podstawie zweryfikowanych stawek dostawców. Nie zgaduj. Sprawdź cennik swojego dostawcy i dopasuj go do zmierzonych tokenów. Po czwarte, porównaj udane wywołania z odrzuconymi wywołaniami nieautoryzowanymi. Wysoka liczba odrzuceń oznacza, że Twój agent testuje granice lub Twoja allowlista nie jest zgodna z rzeczywistymi potrzebami.
Te liczby zmieniają operacje agentów z subskrypcji typu „black-box” w obserwowalny system. Możesz planować budżet, optymalizować i wyjaśniać koszty.
Różnica między lokalną kontrolą a lokalnym wykonaniem
Oto lekcja, na której wykładają się nawet uważni twórcy. Uruchomienie deco Studio na własnej maszynie daje Ci lokalną kontrolę nad konfiguracją, ale nie gwarantuje lokalnego wykonania samego modelu. Jeśli skonfigurujesz agenta tak, aby wywoływał zewnętrznego dostawcę, takiego jak OpenAI, Anthropic czy jakiekolwiek hostowane API, Twoje prompty opuszczą Twoją maszynę. Studio zarządza bramką, ale dane i tak przesyłane są przez sieć.
Zawsze śledź te granice. Wiedź, które części potoku (pipeline) pozostają na localhost, a które elementy trafiają na serwer kogoś innego. Jeśli Twoje dane są wrażliwe, lokalna kontrola nad warstwą narzędzi to za mało. Musisz również wiedzieć, gdzie odbywa się wnioskowanie modelu (inference). Nie myl wygody lokalnego pulpitu nawigacyjnego z rzeczywistością zdalnego modelu.
Instrukcje to nie autoryzacja
Jednym z niebezpiecznych skrótów jest próba zabezpieczenia agenta za pomocą promptingu. Powiedzenie modelowi: „Nigdy nie wywołuj funkcji delete”, nie jest mechanizmem kontroli bezpieczeństwa. To jedynie sugestia. Modele mogą błędnie interpretować instrukcje, ulegać jailbreakingowi promptów lub po prostu popełniać błędy w rozumowaniu. Prawdziwe bezpieczeństwo istnieje na granicy oprogramowania.
Używaj allowlist wewnątrz deco Studio, aby dokładnie zdefiniować, które funkcje można wywołać. Wymuszaj te ograniczenia za pomocą kontroli po stronie serwera wewnątrz control plane. Agent powinien odkrywać swoje możliwości w taki sam sposób, w jaki użytkownik odkrywa uprawnienia do plików: poprzez napotkanie twardego limitu, a nie poprzez czytanie uprzejmej notatki. Bezpieczeństwo należy do architektury, a nie do języka naturalnego.
Zacznij od małych kroków, zachowaj sceptycyzm
Buduj swoją warstwę kontrolną krok po kroku. Jeden serwer MCP. Jedna udostępniona funkcja. Jedno syntetyczne zadanie. Zweryfikuj, czy agent odnosi sukces tam, gdzie powinien, i ponosi porażkę tam, gdzie musi. Przeczytaj ślad (trace). Potwierdź liczbę tokenów. Następnie dodaj kolejne narzędzie.
Kontrola to nie przełącznik, który po prostu włączasz. To nawyk sprawdzania granic, zanim zaczniesz im ufać. deco Studio daje Ci lokalną przestrzeń do ćwiczenia tego nawyku. Wykorzystaj ją, aby przekształcić rój autonomicznych agentów w zarządzany, obserwowalny i ograniczony system.
Źródło: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
Opcjonalna społeczność edukacyjna: GyaanSetu AI na Telegramie