Nadmierne uprawnienia i zdezorientowany zastępca

Agent, który ma więcej zdolności niż potrzebuje do swojego zadania, to podatność czekająca na exploitację. Skradnij jego klucz, oszukaj go wstrzykniętą instrukcją lub skompromituj jedną zależność — i wszystko, co ten klucz może zrobić, jest teraz w rękach atakującego. To jest problem nadmiernych uprawnień, który łączy się z ściśle powiązanym wzorcem zwanym zdezorientowanym zastępcą: agent nie jest bezpośrednio skompromitowany, jest oszukiwany do użycia swojego legalnego autorytetu w imieniu atakującego. Oba problemy mają jedną przyczynę: klucz, który posiada skompromitowany agent, jest zbyt potężny dla zadania, które wykonuje. Obroną jest minimalne uprawnienia — daj każdemu agentowi dokładnie taką zdolność, jakiej wymaga jego zadanie, i nic więcej.

​

1. Co sprawia, że agent jest nadmiernie zdolny

Gdy każdy agent w przestrzeni roboczej współdzieli jeden klucz lub gdy klucz jest wydawany raz i nigdy nie rewidowany, zdolności przesuwają się ku górze:

• Bez ograniczeń modeli — agent może wywoływać dowolny model w przestrzeni roboczej, w tym drogie lub wysoce zdolne, których nigdy nie potrzebuje.
• Brak pułapu wydatków — rozbiegana pętla, wywołany injection lub atak billing może wyczerpać saldo przestrzeni roboczej, zanim zauważysz.
• Brak wygaśnięcia — klucz wydany podczas sprintu jest nadal ważny rok później, długo po tym, gdy agent, dla którego był wybity, jest wycofany.
• Brak ograniczenia IP — poświadczenie działa z dowolnego miejsca, więc wyciekły klucz nie ma geograficznego limitu.
• Brak listy dozwolonych narzędzi — agent może wywoływać dowolne narzędzie, nawet niepowiązane z jego funkcją.

Każde z nich samo w sobie to rozszerzony promień wybuchu. W kombinacji, jeden skompromitowany agent może robić wszystko, co może zrobić admin przestrzeni roboczej — wywoływać najpotężniejszy model, wydać pełne saldo, sięgnąć do każdego narzędzia.

​

2. Wzorzec zdezorientowanego zastępcy

Zdezorientowany zastępca to specjalizacja nadmiernych uprawnień. Agent nie jest przejmowany; jest przekonywany. Ładunek prompt injection na pobranej stronie internetowej, w dokumencie lub wyniku narzędzia mówi agentowi, aby podjął akcję, do której jest legalnie autoryzowany — przenieś pieniądze, usuń rekord, wyślij wiadomość — w imieniu atakującego. Agent działa. Był autoryzowany do dokładnie tego. Sprawdzenie autoryzacji przechodzi. Szkoda jest wyrządzona. Obrona wymaga dwóch rzeczy działających razem:

1. Wąski zakres — agenta nie można oszukać do zrobienia czegoś, czego jego zadanie nigdy nie zamierzało, ponieważ nie jest w ogóle autoryzowany do tego.
2. Zatwierdzenie przez człowieka dla nieodwracalnych akcji — nawet wewnątrz autoryzowanego zakresu, wywołanie o wysokiej stawce wymaga potwierdzenia od człowieka przed wykonaniem.

​

3. Obrona w głębi: cztery warstwy

OrcaRouter egzekwuje minimalne uprawnienia przez cztery niezależne kontrole, które kompozycjonują się na jednym kluczu API. Żadna nie wymaga zmiany kodu w twoim agencie.

​

Warstwa 1 — Klucz o ograniczonym zakresie (tożsamość + twarde limity)

Każdy agent powinien mieć swój własny klucz API. Klucz niesie twarde limity, które brama egzekwuje niezależnie od tego, o co agent prosi: Te limity są egzekwowane na poziomie klucza — przed jakąkolwiek polityką, przed jakimkolwiek wywołaniem modelu. Są zewnętrzną granicą promienia wybuchu.

​

Warstwa 2 — Polityka firewalla (lista dozwolonych narzędzi)

Dołącz politykę firewalla do klucza przez firewall_policy_id. Polityka zarządza każdym wywołaniem narzędzia, które ten klucz wydaje:

• Pisz reguły, które zezwalają na nazwy narzędzi, których agent legalnie używa (globy nazw narzędzi są obsługiwane — np. db.query*).
• Ustaw default_verdict polityki na deny, aby wszystko, co nie jest jawnie wylistowane, było blokowane.
• Dodaj predykaty argumentów, aby ograniczyć nawet dozwolone narzędzia — np. zezwól na db.query tylko gdy argument database pasuje do konkretnego schematu.

Klucz bez dołączenia firewalla wraca do domyślnej polityki przestrzeni roboczej. Dla agentów z wąskimi potrzebami narzędzi, jawne dołączenie ze ścisłą polityką jest zawsze preferowane nad poleganiem na domyślnym przestrzeni roboczej. Zobacz Reguły firewalla dla pełnego języka dopasowania.

​

Warstwa 3 — Zatwierdzenie przez człowieka dla akcji o wysokiej stawce (pending_approval)

Dla nieodwracalnych lub wartościowych wywołań narzędzi — dyspozycja płatności, usunięcie rekordu, wysłanie emaila — dodaj regułę pending_approval. Przepływ:

1. Agent wydaje wywołanie narzędzia. Firewall je wstrzymuje i zwraca odpowiedź „wstrzymane” niosącą id zatwierdzenia. Wywołanie nie dociera do narzędzia.
2. Recenzent zatwierdza lub odrzuca poza pasmem — z konsoli (Developer+) lub przez podpisany HMAC webhook do twojego własnego systemu zatwierdzeń.
3. Twój agent odpytuje id zatwierdzenia. Po zatwierdzeniu, ponownie przesyła oryginalne wywołanie z jednorazowym nagłówkiem X-OrcaRouter-Firewall-Approval. Brama przepuszcza je dokładnie raz.

Zdezorientowany zastępca jest tutaj zatrzymany nawet gdy zakres jest ważny: człowiek potwierdza, że akcja jest zamierzona, zanim zostanie wykonana.

​

Warstwa 4 — Per-run pułap kosztu (cap_cost)

Reguła cap_cost odmawia każdego wywołania narzędzia, gdy skumulowane wydatki uruchomienia agenta przekraczają per-rule pułap (w centach). To jest bezpiecznik dla:

• Rozbieganych pętli wywołanych przez injection.
• Ataków billing, które powodują wydatki, zanim jakikolwiek człowiek zauważy.
• Przypadkowej rekurencji w wieloetapowych planach.

cap_cost działa na poziomie uruchomienia, nie na poziomie dożywotniego klucza — więc resetuje się per wywołanie agenta, a jedno nieposłuszne uruchomienie nie może wyczerpać pułapu credit_limit_usd klucza.

​

4. Dobrze zakresowany klucz agenta — przykład

Agent, który podsumowuje zgłoszenia klientów używając gpt-4o-mini i odpytuje replikę tylko do odczytu, powinien wyglądać tak:

• model_limits: ["openai/gpt-4o-mini"] — nie może eskalować do bardziej zdolnego lub droższego modelu.
• allow_ips: CIDR egress puli pracowniczej — klucz jest nieaktywny wszędzie indziej.
• credit_limit_usd: tygodniowy pułap pasujący do oczekiwanego kosztu zadania, z pewnym zapasem — np. 5.00.
• expired_time: koniec sprintu lub okresu wdrożenia — klucz wygasa samoczynnie bez ręcznego czyszczenia.
• environment: "prod" — pojawia się w filtrach logów i widokach anomalii.
• guardrail_id: guardrail zakresowany do wrażliwości danych tego agenta (maskowanie PII, brak sekretów w wyjściu).
• firewall_policy_id: polityka, która tylko-listuje db.query* i ticket.read*, domyślny werdykt deny.

Gdy ten agent jest oszukiwany do eksfiltracji danych przez wstrzykniętą instrukcję, promień wybuchu to: jeden model, jeden zakres IP, jedna przestrzeń nazw narzędzi, jeden pułap kosztu. Reszta przestrzeni roboczej jest nienaruszana.

​

5. Wymagane role

​

6. Relacja z innymi zagrożeniami

Nadmierne uprawnienia to enabler dla prawie każdego innego zagrożenia agenta:

• Niebezpieczne wywołania narzędzi — klucz z ścisłą listą dozwolonych narzędzi nie może być zmuszony do wywołania narzędzia, którego nie wylistowuje, nawet jeśli injection się powiedzie.
• Prompt injection — limity zakresu ograniczają szkody, które injection może wyrządzić; bramy zatwierdzenia blokują nieodwracalne akcje, które injection próbuje wywołać.
• Model zagrożeń — pełna mapa powierzchni ataku, pokazująca, gdzie nadmierne uprawnienia znajdują się względem innych wektorów.

Minimalne uprawnienia nie zapobiegają injection. Zmniejszają to, co injection może osiągnąć. Minimalne uprawnienia — jeden wąski klucz per agent, ścisła lista dozwolonych narzędzi, pułap wydatków i zatwierdzenie przez człowieka dla nieodwracalnych akcji — to główna obrona przed atakami nadmiernych uprawnień LLM i wzorcem zdezorientowanego zastępcy.