Cisco Project Quarry pyta, co agent zrobił w całym zadaniu
Project Quarry łączy wiadomości, wywołania narzędzi i kolejność zdarzeń w przejrzystych regułach wykrywania. Praktyczny przewodnik po silniku alfa, dowodach i granicach egzekwowania zasad.
Asystent odczytuje plik. Później wysyła żądanie internetowe. Każde działanie może być dozwolone, użyteczne i zupełnie zwyczajne. Pytanie o bezpieczeństwo brzmi: czy drugie działanie przeniosło informacje z pierwszego w miejsce, do którego nigdy nie powinny trafić?
Cisco zaprezentowało Project Quarry 28 października 2026 r. jako otwarty język wykrywania i silnik analizy zachowania agentów. Zamiast sprawdzać wyłącznie pojedynczą wiadomość, pozwala zespołom opisywać wzorce obejmujące wiadomości, wywołania narzędzi, wyniki i kolejność zdarzeń. Wykrycie zawiera dowody pomagające wyjaśnić, która aktywność pasowała do reguły. Artykuł premierowy Cisco
Dla zespołów wprowadzających agentów do wsparcia, programowania lub pracy operacyjnej to konkretny dodatek do narzędzi bezpieczeństwa. Ten przewodnik wyjaśnia, co wnosi Quarry, jak zacząć od lokalnych przykładów i dlaczego wykrywanie niebezpiecznej sekwencji jest tylko częścią jej kontrolowania. Publiczny framework jest obecnie w fazie alfa, więc pilotaż powinien uwzględniać również zmiany reguł przed wersją 1.0.0. README Project Quarry, sprawdzono 2 listopada 2026 r.
Zapora Cisco ASA 5510 w 2010 r.; historyczny sprzęt bezpieczeństwa sieciowego. Quarry jest oprogramowaniem analizującym zachowanie agentów, a nie tym urządzeniem. Zdjęcie: Jon 'ShakataGaNai' Davis, CC BY-SA 3.0; zmieniono rozmiar i dodano marginesy. Źródło obrazu · Licencja i informacje o obrazie. Oficjalne informacje o produkcie.
Sekwencja może wyjaśnić coś, czego pojedyncze zdarzenie nie pokaże
Wyobraźmy sobie wewnętrznego agenta wsparcia, który może czytać bazę wiedzy i otwierać zewnętrzne zgłoszenia. Obie możliwości służą uzasadnionym celom. Teraz wyobraźmy sobie, że niezaufana strona poleca mu dołączyć wewnętrzny plik diagnostyczny do niezwiązanego publicznego zgłoszenia. Reguła szukająca tylko frazy „zignoruj wcześniejsze instrukcje” może przeoczyć bardziej pośrednie polecenie. Reguła patrząca wyłącznie na dozwolone narzędzie przesyłania może nie zauważyć, dlaczego jego argumenty są niewłaściwe.
Sekwencja dostarcza kontekstu. Co agent odczytał? Która instrukcja poprzedzała przesłanie? Jakie dane pojawiły się w argumentach? Czy ten cel należał do zadania użytkownika? Te pytania często łatwiej zbadać, gdy uporządkowany ślad wykonania pozostaje nienaruszony.
Cisco przedstawia Quarry jako połączenie dokładnych kontroli z opcjonalnymi ocenami modelu. Dokładne kontrole mogą opisywać nazwy narzędzi, pola, ciągi i kolejność; kontrole wspierane modelem mogą obejmować pytania wymagające interpretacji. Produkt integrujący silnik decyduje następnie, co ma wywołać wykrycie, na przykład alert lub zablokowanie działania. Wyjaśnienie Cisco, 28 października 2026 r.
Nasza ocena: dobra reguła to pytanie o zachowanie, które można ponownie sprawdzić. Powinno dać się wskazać pasujące zdarzenia i dyskutować, czy reguła wyraża zamierzoną politykę. To użyteczniejsze od czerwonego ostrzeżenia, którego jedynym wyjaśnieniem jest niezadowolenie modelu z rozmowy.
Przykładowa podejrzana sekwencja: Quarry ocenia ślad i zwraca dowody; aplikacja integrująca odpowiada za reakcję.
Quarry uzupełnia autoryzację i kontrolę treści
Autoryzacja odpowiada, czy dany podmiot może wykonać określone działanie na zasobie. Klasyfikator treści pyta, czy fragment wejścia lub wyjścia ma istotną właściwość. Wykrywanie na poziomie śladu pyta o relacje między kilkoma zdarzeniami. Te pytania się nakładają, ale żadne nie staje się zbędne dlatego, że inne ma przekonujący pokaz.
Cisco przywołuje Snort, YARA i Sigma jako wzorce czytelnych, współdzielonych języków wykrywania w analizie sieci, złośliwego oprogramowania i logów. Quarry chce przenieść ten rodzaj przejrzystych reguł na aktywność agentów. Uzasadnienie premiery Cisco Analogia jest pomocna jako cel projektowy; nie nadaje młodemu projektowi alfa dojrzałości tych ugruntowanych ekosystemów.
| Kontrola lub podejście | Pytanie, na które dobrze odpowiada | Pozostająca odpowiedzialność |
|---|---|---|
| Szczegółowa autoryzacja | Czy ten podmiot może wykonać tu to działanie? | Określić i egzekwować dozwolony dostęp |
| Klasyfikator treści | Czy ta wiadomość ma sprawdzaną właściwość? | Interpretować błędy i łączyć kontekst |
| Reguły zachowania Quarry | Czy ta uporządkowana aktywność pasuje do zdefiniowanego wzorca? | Wybrać reakcję i utrzymywać politykę |
| Snort, YARA i Sigma | Jak wyrazić wykrycie dla ich ustalonej dziedziny? | Używać kontroli odpowiednich do tej dziedziny |
Wróćmy do przykładu pliku i przesyłania. Mocna autoryzacja może zatrzymać dostęp do zabronionego pliku, zanim reguła zachowania zacznie mieć znaczenie. Kontrola treści może zidentyfikować podejrzaną instrukcję w wyniku narzędzia. Reguła sekwencji może powiązać dozwolony odczyt z niewłaściwym transferem. Razem obejmują większą część ścieżki niż dowolna pojedyncza kontrola.
Alert potrzebuje wystarczających dowodów do podjęcia działania przez człowieka
Zaletą wykrycia opartego na śladzie jest możliwość wskazania konkretnego następnego kroku. Recenzent musi wiedzieć, które zdarzenia miały znaczenie, które pole pasowało i jaki otaczający kontekst zmienia interpretację. Celem jest zrozumiały przypadek, a nie rosnąca lista niewyjaśnionych ocen ryzyka.
W przykładowym procesie wsparcia użyteczne wykrycie mogłoby powiązać wynik z dokumentem wewnętrznym z późniejszym wysłaniem do niezatwierdzonego celu. Analityk może następnie zapytać, czy żądane działanie upoważniało do tego transferu, czy cel należy do klienta i czy ładunek rzeczywiście zawiera chronione informacje. Szeroka reguła oznaczająca każdy odczyt pliku, po którym następuje każde żądanie sieciowe, pogrzebałaby interesujące przypadki.
Precyzja zależy od słownika aplikacji. „Zewnętrzny” może oznaczać poza organizacją, poza zatwierdzonym dzierżawcą lub po prostu poza jedną usługą. „Wrażliwy” może odnosić się do oznaczonego dokumentu, pola źródłowego lub wyniku klasyfikacji. Zdefiniuj te terminy w integracji przed napisaniem reguły, która od nich zależy.
Same dowody również wymagają ochrony. Ślad może zawierać dokładnie tę zawartość pliku lub fragment danych uwierzytelniających, które uczyniły zdarzenie ryzykownym. Alert przydatny analitykowi bezpieczeństwa może być nieodpowiedni na publicznej stronie błędu. Zaplanuj dostęp i usuwanie wrażliwych danych razem z regułą, zamiast dodawać je po pierwszym incydencie.
Trzy procesy nadają pierwszemu pilotażowi konkretny zakres
Pierwszym przykładowym zastosowaniem jest retrospektywna analiza sesji agenta wsparcia. Zacznij od małego dozwolonego zbioru danych zawierającego zarówno normalną aktywność wsparcia, jak i syntetyczny przykład niewłaściwego transferu. Uruchom te same reguły na obu. Dobry pilotaż pokazuje, że zespół potrafi wyjaśnić dopasowanie oraz to, dlaczego uzasadniona praca nie generuje wykryć.
Drugim zastosowaniem jest obsługa warunku zatrzymania przez agenta. Załóżmy, że zadanie dopuszcza trzy próby, po których wymaga eskalacji. Ślad może pokazać, czy agent zatrzymał się, kontynuował czy zmienił narzędzia, by pośrednio dążyć do tego samego działania. To użyteczne pytanie o politykę, nawet gdy treść każdej pojedynczej wiadomości jest nieszkodliwa.
Trzecim jest reagowanie na incydenty. Gdy zespół pozna nowy istotny wzorzec zachowania, może zapytać, czy wcześniejsze zapisane ślady też go zawierają. Wartością jest szybsze, spójne wyszukiwanie w historii, którą organizacja ma prawo zachować. Jakość odpowiedzi nadal zależy od tego, czy wcześniejszy ślad rejestrował pola i kolejność wymagane przez regułę.
Te scenariusze powinny zaczynać się w trybie obserwacji. Retrospektywne wykrycia ujawniają fałszywe alarmy bez przerywania pracy użytkownikom i pomagają oszacować obciążenie analizą. Reguła przekonująca na jednym syntetycznym śladzie może być zbyt szeroka w codziennej aktywności. Przejście do bieżącej interwencji powinno następować po tej nauce, z jasno przypisaną odpowiedzialnością za reakcję.
Zacznij od lokalnych przykładów repozytorium
Publiczne repozytorium korzysta z licencji Apache 2.0 i udostępnia interfejsy Pythona oraz wiersza poleceń. README obecnie wymienia Python od 3.11 do 3.13 oraz szybki start oparty na uv. Przykładowa konfiguracja wybiera 14 lokalnych reguł; cztery przykłady semantyczne używają deterministycznych atrap opartych na słowach kluczowych, wyraźnie przeznaczonych do pokazów i testów, a nie decyzji produkcyjnych. README Project Quarry
Poniższa procedura odpowiada opublikowanej ścieżce konfiguracji. To punkt wyjścia do własnej oceny czytelnika, a nie twierdzenie, że na potrzeby artykułu przeprowadzono wdrożenie lub skanowanie rzeczywistych danych.
-
Użyj odizolowanego folderu ewaluacyjnego. Potwierdź udokumentowany zakres wersji Pythona i zainstaluj
uvzgodnie ze zwykłym procesem narzędziowym organizacji. Oddziel ocenę od śladów produkcyjnych i danych uwierzytelniających. -
Pobierz i przygotuj projekt. Sklonuj oficjalne repozytorium, wejdź do jego folderu i zsynchronizuj przypięte środowisko:
BashUruchom w: Terminalgit clone https://github.com/cisco-ai-defense/project-quarry.git cd project-quarry uv sync --frozen -
Uruchom lokalny przykład nieszkodliwy. Użyj dostarczonej konfiguracji przed dodaniem dostawcy lub wysłaniem rzeczywistych danych rozmowy:
BashUruchom w: Terminaluv run --frozen quarry scan --config examples/config.yaml --target examples/data/benign.json -
Sprawdź przykład z dopasowaniem. Zmień cel na
examples/data/tool_calls.json, a następnie przeanalizuj razem regułę i dowody. Dopasowanie powinno być zrozumiałe na podstawie zdarzeń, a nie akceptowane dlatego, że polecenie wyświetliło ostrzeżenie. -
Dodaj jedną parę testową właściwą dla aplikacji. Utwórz syntetyczny ślad naruszenia i podobny, lecz prawidłowy ślad z tym samym słownikiem narzędzi. Określ oczekiwany wynik przed dostosowaniem reguły.
-
Zapisz rewizję i sposób obsługi wyników. Udokumentowana konwencja CLI to 0 dla kompletnego skanu bez wykryć, 1 dla kompletnego dopasowania i 2 dla skanu nieprawidłowego lub niekompletnego. Zachowaj te rozróżnienia w każdej nakładce.
Rozróżnienie kodów wyjścia ma praktyczne konsekwencje. Skanu, któremu zabrakło zasobów lub który otrzymał nieprawidłowe dane, nie można uznać za skan bez wykryć. Monitoring powinien uwidaczniać niekompletne oceny, aby zespół wiedział o luce w pokryciu.
Reguły wspierane modelem wprowadzają kolejną granicę przetwarzania danych
Niektóre polityki wymagają interpretacji, której dokładne dopasowanie nie zapewnia. Model może pomóc ocenić, czy wynik narzędzia próbuje przekierować agenta albo czy żądane działanie wykracza poza zadanie. Dodanie takiej oceny zwiększa również opóźnienie, koszt, zależność od zachowania dostawcy oraz liczbę możliwych źródeł błędu.
Dokumentacja inferencji modeli Quarry podaje, że operacja modelu może wysłać wybrane wiadomości, definicje narzędzi i tekst polityki do skonfigurowanego punktu końcowego. Zaleca sprawdzenie retencji, logowania, transportu i danych uwierzytelniających dostawcy. Dokumentacja opisuje też limity czasu skanowania i budżety wywołań modeli, oczekując od adapterów respektowania anulowania i limitów czasu. Dokumentacja inferencji modeli Quarry, sprawdzono 2 listopada 2026 r.
Oznacza to, że ścieżka danych jest decyzją projektową. Zespół może zacząć od lokalnych kontroli, a następnie włączyć regułę wspieraną modelem tylko wtedy, gdy korzyść uzasadnia dodatkowe przetwarzanie. Przed użyciem wrażliwych śladów ustal dokładnie, które pola przekraczają tę granicę i kto może zatwierdzić konfigurację. Kontrola bezpieczeństwa nie powinna po cichu stawać się nieoczekiwaną drogą eksportu danych, które ma chronić.
Atrapy oparte na słowach kluczowych są użyteczne w przewidywalnych przykładach, bo dają powtarzalne wyniki bez aktywnego dostawcy. Nie mogą wykazać dokładności produkcyjnego detektora semantycznego. Oceń rzeczywiście skonfigurowany model na oznaczonych, istotnych przypadkach, w tym zwykłych wiadomościach podobnych do ryzykownych. Fałszywe alarmy i przeoczone wykrycia należą do tej samej analizy.
Integracja produkcyjna musi odpowiadać za przypadki niekompletne
Przewodnik integracji poleca aplikacjom przygotować i zweryfikować wybrane reguły przed przyjmowaniem ruchu. Oddziela zaufane dane polityki i adapterów od niezaufanych rozmów i wymaga miarodajnego statusu skanu przed działaniem na podstawie dopasowań. Przewodnik integracji Quarry, sprawdzono 2 listopada 2026 r.
Ten kontrakt ma największe znaczenie przy awarii. Nieprawidłowa rozmowa, przekroczony czas, niedostępny model lub niepoprawna reguła powinny uruchamiać jawną politykę aplikacji. Zależnie od operacji może ona wstrzymać istotne działanie, poprosić o ocenę lub zgłosić niekompletną obserwację. Traktowanie każdego błędu jak „braku wykrycia” tworzy cichą lukę.
Kompletne dopasowanie, kompletny wynik bez wykryć i niekompletna ocena mają różne znaczenia. Aplikacja musi zdecydować, jak każdy z nich wpływa na pracę użytkownika.
Zmiany wersji wymagają tej samej jasności. Ostrzeżenie o fazie alfa oznacza, że przyszła zmiana składni może wymagać aktualizacji reguł. Przypnij rewizję do oceny, zachowaj reprezentatywne ślady i uruchom je ponownie przed przyjęciem aktualizacji. Daje to zespołowi sposób odróżnienia zmienionej polityki od zmienionego silnika.
Ogłoszenie Cisco omawia wdrożenie w ramach szerszych prac nad AI Defense, ale dojrzałość publicznego silnika należy oceniać według jego własnego udokumentowanego stanu. Planowane integracje są pracą przyszłą. Wykorzystanie komponentu przez produkt produkcyjny nie zapewnia automatycznie wspieranej integracji produkcyjnej dla aplikacji każdego czytelnika.
Bezpieczeństwo agentów potrzebuje pytania, do którego można wrócić
Najmocniejszą ideą Quarry jest wyrażenie obawy dotyczącej zachowania na tyle jasno, by można ją ponownie sprawdzić. Zespół może zachować regułę, jej wersję, dopasowaną aktywność i powód zmiany. Dzięki temu przegląd polityki staje się konkretniejszy niż spór o to, czy agent ogólnie wydaje się bezpieczny.
Kolejne pytanie pilotażowe jest więc praktyczne: czy recenzent rozumie, dlaczego prawidłowa sesja przeszła, dlaczego sesja naruszająca zasady dała dopasowanie i co dzieje się, gdy ocena nie może się zakończyć? Jeśli odpowiedzi są jasne, zespół ma podstawę do decyzji, gdzie wykrywanie powinno wpływać na działanie.
Źródła
- Cisco: przedstawienie Project Quarry, 28 października 2026 r.
- README Project Quarry, sprawdzono 2 listopada 2026 r.
- Przewodnik integracji aplikacji Quarry, sprawdzono 2 listopada 2026 r.
- Przewodnik inferencji modeli Quarry, sprawdzono 2 listopada 2026 r. Scenariusze mają charakter ilustracyjny; nie twierdzimy, że przeprowadzono tu instalację lub skanowanie śladów produkcyjnych.
Zachowaj regułę wraz z jej dowodami
Telli.sh jest jedną z możliwości zachowania dozwolonych materiałów źródłowych, notatek ewaluacyjnych i decyzji stojących za zmianą inżynierską. Utwórz przestrzeń na notatki.