Checklista bezpieczeństwa agenta AI: uprawnienia i sandboksy
Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.
Bezpieczeństwo agenta polega na kontrolowaniu jego działań. Chatbot może zwrócić błędną odpowiedź. Agent może użyć prawdziwych poświadczeń, wywołać narzędzie i zmienić dane produkcyjne.
Podstawowa zasada jest prosta: nie dawaj agentowi możliwości, których nie potrzebuje. Zacznij od wąskiego zestawu narzędzi, kontroli polityk przed każdym wywołaniem narzędzia, izolowanych sandboxów, ograniczonych poświadczeń, bramek wymagających zatwierdzenia przez człowieka oraz śladów audytowych. Dodaj również guardrails i filtry danych wyjściowych, ale nie traktuj ich jako głównej granicy bezpieczeństwa.
Model zagrożeń i data przeglądu: 2026-08-10. Te priorytety zakładają, że agent korzystający z narzędzi może przetwarzać dane wejściowe kontrolowane przez atakującego oraz odczytywać dane lub powodować zewnętrzne skutki uboczne. Asystenci o mniejszych możliwościach wymagają mniej kontroli, natomiast działania o większym wpływie wymagają ściślejszej izolacji i zatwierdzania.
Ranking wzorców
| Wzorzec | Priorytet | Chroni przed | Uwagi implementacyjne |
|---|---|---|---|
| Narzędzia zgodne z zasadą najmniejszych uprawnień | P0 | Nadmierną autonomią | Postępuj zgodnie z wytycznymi OWASP MCP: nie udostępniaj narzędzi, których agent nigdy nie powinien używać. |
| Kontrole polityk przed narzędziem | P0 | Niebezpiecznymi działaniami | Sprawdzaj konkretne działanie bezpośrednio przed wykonaniem. |
| Sandboksy | P0 | Uszkodzeniem plików, powłoki, przeglądarki i sieci | Izoluj kod oraz niezaufane treści; domyślnie blokuj ruch wychodzący z sieci. |
| Zatwierdzenia przez człowieka | P0 | Nieodwracalnymi lub regulowanymi działaniami | Wymagaj zatwierdzenia dla zapisów, wdrożeń, płatności, wysyłki zewnętrznej i uprzywilejowanych zmian. |
| Ograniczone poświadczenia | P0 | Nadmiernym zakresem poświadczeń i awariami typu confused deputy | Używaj wąskich zakresów osobno dla każdego serwera i narzędzia. |
| Izolacja serwerów MCP | P1 | Zatruwaniem narzędzi, shadowingiem narzędzi i atakami między serwerami | Nie łącz niezaufanych serwerów z potężnymi narzędziami w jednym kontekście bez przeglądu. |
| Ślady audytowe | P1 | Brakiem wiedzy o historii incydentu | Utrwalaj żądanie użytkownika, wywołanie narzędzia, argumenty, wynik, decyzję polityki i osobę zatwierdzającą. |
| Guardrails | P1 | Niebezpiecznym tekstem wejściowym i wyjściowym | Przydatne, ale niewystarczające do kontroli uprawnień narzędzi. |
| Ewaluacje red-team | P1 | Znanymi ścieżkami ataku | Testuj prompt injection, zatruwanie narzędzi, eksfiltrację danych i obchodzenie uprawnień. |
Co wdrożyć w pierwszej kolejności
Najpierw usuń zbędne możliwości. Jeśli agent nie musi zapisywać danych w GitHub, nie dawaj mu tokenu z uprawnieniami do zapisu. Jeśli potrzebuje tylko dostępności w kalendarzu, nie przyznawaj mu pełnego dostępu do skrzynki pocztowej. Wąskie uprawnienie jest bezpieczniejsze niż stanowczy prompt.
Następnie sprawdzaj politykę przed każdym wywołaniem narzędzia. Kontroluj nazwę narzędzia, argumenty, docelowy zasób, użytkownika, środowisko i skutek uboczny. Pozornie nieszkodliwe żądanie nadal może wygenerować niebezpieczne polecenie powłoki.
Dodaj sandboksy do wykonywania kodu, automatyzacji przeglądarki, dostępu do plików i przetwarzania niezaufanych dokumentów. Sandbox nie sprawia, że działanie staje się poprawne, ale ogranicza szkody wynikające z przejętego wyniku narzędzia lub błędnego rozumowania modelu.
Kontroluj przepływ danych równie dokładnie jak wykonywanie działań. Ogranicz docelowe adresy ruchu wychodzącego, usuwaj sekrety z wyników narzędzi, oddzielaj niezaufane treści od poświadczeń i rejestruj próby wysyłania danych na zewnątrz. Sandbox systemu plików, który nadal pozwala na dowolny dostęp do sieci, pozostawia bezpośrednią ścieżkę eksfiltracji.
W przypadku nieodwracalnych działań wymagaj zatwierdzenia przez człowieka. Nie zatwierdzaj każdego kroku. Zatwierdzaj granice: wdrożenia produkcyjne, usuwanie danych, wysyłkę wiadomości e-mail, transfer pieniędzy, zmiany uprawnień i decyzje regulowane.
Ryzyka specyficzne dla MCP
MCP jest użyteczny, ponieważ standaryzuje dostęp do narzędzi. Jest ryzykowny, ponieważ opisy narzędzi, schematy, tożsamości serwerów, zakresy OAuth oraz wyniki narzędzi stają się częścią kontekstu decyzyjnego modelu.
W przypadku MCP te zasady powinny być stałym elementem przeglądu kodu:
- przeglądaj opisy narzędzi i schematy przed zatwierdzeniem
- preferuj wąskie poświadczenia przypisane do poszczególnych serwerów
- izoluj niezaufane serwery MCP od wrażliwych narzędzi
- monitoruj zmiany definicji narzędzi po instalacji
- traktuj wynik narzędzia jako niezaufane dane wejściowe
- rejestruj każdy serwer, narzędzie, argument i wynik
Guardrails to za mało
Guardrails mogą walidować dane wejściowe i wyjściowe. Nie rozwiązują problemów najmniejszych uprawnień, zakresu poświadczeń, sandboxingu, zatruwania narzędzi ani polityki zatwierdzania. Zachowaj je, ale umieść je za projektem uprawnień i przed danymi wyjściowymi widocznymi dla użytkownika.
Lektura uzupełniająca
- AI Agent Security to pełny przewodnik po architekturze.
- AI Agent Tool Use wyjaśnia MCP, narzędzia, CLI, skills i wykonywanie kodu.
- Long-Running AI Agent Runtime omawia granice środowiska uruchomieniowego dla agentów działających długotrwale.