Lista kontrolna 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ć rzeczywistych danych uwierzytelniających, wywołać narzędzie i zmienić dane produkcyjne.

Domyślna zasada jest prosta: nie przyznawaj agentowi możliwości, których nie potrzebuje. Zacznij od wąsko zdefiniowanych narzędzi, kontroli polityk przed każdym wywołaniem narzędzia, izolowanych sandboxów, ograniczonych danych uwierzytelniających, akceptacji człowieka i śladów audytowych. Dodaj także guardrails i filtry danych wyjściowych, ale nie traktuj ich jako głównej granicy bezpieczeństwa.

Model zagrożeń i data przeglądu: 2026-09-08. 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; działania o większym wpływie wymagają ściślejszej izolacji i akceptacji.

Ranking wzorców

WzorzecPriorytetChroni przedUwagi dotyczące implementacji
Narzędzia zgodne z zasadą najmniejszych uprawnieńP0Nadmierną autonomiąStosuj się do wytycznych OWASP MCP: nie udostępniaj narzędzi, których agent nigdy nie powinien używać.
Kontrole polityk przed narzędziemP0Niebezpiecznymi działaniamiSprawdzaj konkretne działanie bezpośrednio przed wykonaniem.
SandboksyP0Uszkodzeniem plików, powłoki, przeglądarki i sieciIzoluj kod oraz niezaufane treści; domyślnie blokuj ruch wychodzący do sieci.
Akceptacje człowiekaP0Nieodwracalnymi lub regulowanymi działaniamiWymagaj akceptacji dla zapisów, wdrożeń, płatności, wysyłki zewnętrznej i uprzywilejowanych zmian.
Zakresowe dane uwierzytelniająceP0Nadmiernym użyciem danych uwierzytelniających i awariami typu confused deputyUżywaj wąskich zakresów osobno dla każdego serwera i narzędzia.
Izolacja serwerów MCPP1Zatruwaniem narzędzi, przesłanianiem narzędzi i atakami między serweramiNie łącz niezaufanych serwerów z potężnymi narzędziami w jednym kontekście bez przeglądu.
Ślady audytoweP1Brakiem wiedzy o historii incydentówRejestruj tożsamość użytkownika, działanie, zasób docelowy, decyzję polityki, osobę akceptującą i wynik. Przed zapisaniem maskuj poufne dane wejściowe.
GuardrailsP1Niebezpiecznymi danymi wejściowymi, wyjściowymi lub wywołaniami narzędziUruchamiaj kontrole polityk narzędzi przed wykonaniem; same filtry tekstowe nie mogą autoryzować działań.
Ewaluacje red-teamoweP1Znanymi ścieżkami atakuTestuj 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 przyznawaj mu tokenu z uprawnieniami zapisu. Jeśli potrzebuje wyłącznie 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. Analizuj nazwę narzędzia, argumenty, zasób docelowy, użytkownika, środowisko i skutek uboczny. Pozornie nieszkodliwa prośba nadal może wygenerować niebezpieczne polecenie powłoki.

Dodaj sandboksy dla wykonywania kodu, automatyzacji przeglądarki, dostępu do plików i przetwarzania niezaufanych dokumentów. Sandbox nie gwarantuje poprawności działania, ale ogranicza szkody wynikające z przejętego wyniku narzędzia lub błędnie działającego modelu.

Kontroluj zarówno przepływ danych, jak i wykonywanie. Ogranicz docelowe adresy ruchu wychodzącego, maskuj sekrety w wynikach narzędzi, oddzielaj niezaufane treści od danych uwierzytelniających i rejestruj próby wysyłania danych na zewnątrz. Sandbox systemu plików, który nadal zezwala na dowolny dostęp do sieci, pozostawia bezpośrednią ścieżkę eksfiltracji.

Stosuj akceptację człowieka dla działań nieodwracalnych. Nie akceptuj każdego kroku. Akceptuj konkretne działania o dużym wpływie: 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 i wyniki narzędzi stają się częścią kontekstu decyzyjnego modelu.

W przypadku MCP podczas przeglądu kodu stosowałbym następujące zasady:

  • przeglądaj opisy i schematy narzędzi przed akceptacją
  • preferuj wąskie dane uwierzytelniające osobno dla każdego serwera
  • 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 tożsamości serwerów i narzędzi, decyzje polityk oraz wyniki; przed zapisaniem minimalizuj i maskuj argumenty oraz wyniki

Guardrails to za mało

Guardrails mogą sprawdzać tekst i wywołania narzędzi. W OpenAI Agents SDK input tool guardrails mogą zablokować chronioną funkcję narzędzia, zanim zostanie uruchomiona. Hosted tools i wbudowane narzędzia wykonawcze nie korzystają z tego samego potoku, dlatego sprawdzaj zakres ochrony dla każdego udostępnianego narzędzia. Kontrole danych wyjściowych odbywają się po wykonaniu i nie mogą cofnąć skutku ubocznego.

Wymuszaj uprawnienia przed wykonaniem, równolegle z kontrolami guardrails. Utrzymuj wąskie dane uwierzytelniające i izoluj narzędzia, nawet gdy ich dane wejściowe przejdą walidację.

Stosuj się do wytycznych OWASP dotyczących logowania: wykluczaj sekrety i zbędne dane osobowe ze śladów. Ogranicz, kto może odczytywać logi, i ustaw okres retencji. Ślad audytowy powinien umożliwiać odtworzenie działania bez kopiowania każdego prywatnego ładunku danych.

Dalsza lektura

Materiały referencyjne