Cel nauki: zaprojektować punkt kontroli pomiędzy propozycją działania agenta AI a wykonaniem operacji biznesowej.

Scenariusz: agent chce zmienić dane zamówienia

To fikcyjny przykład edukacyjny. Asystent analizuje dokumenty zakupowe i proponuje zmianę terminu dostawy. Dokument zawiera dodatkową sugestię, aby pominąć akceptację. Taka sugestia pozostaje danymi zewnętrznymi, a nie poleceniem uprawnionego użytkownika. Pytanie architektoniczne brzmi: kto niezależnie od modelu zdecyduje, czy zmianę wolno wykonać?

Trzy warianty

  1. A — bezpośredni zapis przez agenta. Prosty, lecz zbyt szeroki zakres samodzielności dla operacji istotnych biznesowo.
  2. B — bramka działań. Model przygotowuje ustrukturyzowaną propozycję, a zaufany komponent weryfikuje uprawnienia, politykę i wymaganą zgodę człowieka. To wariant rekomendowany.
  3. C — tylko odczyt i projekt zmiany. Bezpieczniejszy start, jeśli organizacja nie ma jeszcze mechanizmu zatwierdzania działań.

Sześć granic odpowiedzialności

  1. Odczyt: osobne uprawnienia do danych; treści dokumentów nie stają się instrukcjami systemowymi.
  2. Propozycja: agent wskazuje operację, obiekt, wartości przed i po zmianie oraz uzasadnienie.
  3. Autoryzacja: aplikacja sprawdza tożsamość użytkownika, zakres operacji i reguły biznesowe poza modelem.
  4. Zatwierdzenie: człowiek widzi pełne parametry zmiany. Zgoda dotyczy jednej wersji żądania, jest ograniczona w czasie i nie przechodzi na zmienione parametry.
  5. Wykonanie: bramka ponownie weryfikuje uprawnienia i aktualny stan danych. Operacja ma identyfikator pozwalający rozpoznać powtórzenia.
  6. Audyt: zapisujemy inicjatora, zatwierdzającego, decyzję, wersję polityki i wynik bez ujawniania sekretów.

Istotne: zgoda człowieka nie zastępuje autoryzacji w systemie docelowym. Po zmianie danych lub uprawnień wcześniejsza zgoda może wymagać ponownej oceny.

Co wnosi OWASP Agent Control Standard?

1 września 2026 r. OWASP GenAI Security Project ogłosił przyjęcie Agent Control Standard (ACS). Projekt opisuje trzy obszary: Instrument (punkty kontroli), Trace (ślad działania) i Inspect (inwentaryzacja zależności). Dokumentacja podaje wersję specyfikacji v0.1.0. To wczesny punkt odniesienia do pilotażu, a nie gotowa gwarancja bezpieczeństwa lub certyfikacja. Podstawowe zasady autoryzacji i audytu można wdrożyć niezależnie od przyjęcia ACS.

Testy decyzji architektonicznej

  1. Dokument sugeruje pominięcie zatwierdzenia — bramka nadal wymaga właściwej zgody.
  2. Po zatwierdzeniu zmienia się parametr żądania — poprzednia zgoda nie obowiązuje.
  3. Uprawnienia użytkownika wygasają przed wykonaniem — operacja jest odrzucana.
  4. Odpowiedź systemu jest niejednoznaczna — aplikacja ustala wynik przed ponowieniem.
  5. Usługa polityk jest niedostępna — operacje wysokiego ryzyka nie są wykonywane.

Decyzja do ADR: wybieramy B dla operacji z jasno zdefiniowaną polityką, C dla pozostałych. Ceną jest dodatkowy komponent i opóźnienie zatwierdzenia. Zyskujemy kontrolę skutków błędnych decyzji modelu. Warunkiem uruchomienia jest przejście testów i brak alternatywnej ścieżki zapisu.

Pytanie do architekta: który komponent niezależny od agenta może zatrzymać nieuprawnioną zmianę?

Źródła

Źródła zweryfikowano 18.10.2026. Scenariusz jest fikcyjny; opis stanowi propozycję architektoniczną, nie relację z wdrożenia.